On 12/22/2025 5:25 PM, Karl Denninger wrote:
When I asked if patching the userland code was enough, you said no.
From what I understand having ACCEPT_RTADV on an interface means the
kernel is processing rtadv packets. The advisory mentions that, but
it seems thats not sufficient to trigger the bug, as rtsold is the
one that processes the unchecked DNS info. i.e. you need both
ACCEPT_RTADV enabled and rtsold enabled, no ? If just having
ACCEPT_RTADV enabled would lead to an exploit, that implies a kernel
bug no ?
I just want to confirm if *not* running rtsold is enough to avoid
this bug or just having the mere presence of IPv6 can lead to
exploit. If the latter, how is that actually working.
---Mike
Unless I am missing something serious you are correct.
Without rtsold if you have an interface that goes down and comes back
up you likely will not get routes (including default) until the
gateway performs its next timed transmission (typically 10 minutes.)
With it enabled but no options specified it comes up on my machines as
"-a -i" which is "seek the interfaces to solicit upon and do so
immediately on start."
The problem is that the resolvconf(8) script is run by default (unless
you specify something else with the -R switch) if rtsold is running
and a DNS configuration option (RDNSS or DNSSL) advertisement is
received. If rtsold is not running then it should not result in a
problem per-se however you get the possibility of not having routes
when the box comes up until the gateway performs its next timed
transmission.
Thanks for the hints. I spent a bit of time figuring out more details
on how this might and might not work
TL;DR, on RELENG_14 at least, I can get an IPV6 addr and default route
without /sbin/rtsol which is what *is* being fired at bootup time by
/etc/rc. It does not fire after that it seems ever. So any unpatched box
that has inet6 accept_rtadv enabled in /etc/rc.conf on an interface, or
ipv6_activate_all_interfaces="YES" is indeed vulnerable at bootup time
since /sbin/rtsol -i is called then. After that, without a reboot,
/sbin/rtsol does not seem to be called. If rtsold is not running, info
being passed from the router to the client being what "passive SLAAC"
does (address and route) does not seem to be processed.
My test router thats handing out ip6 addrs is set to
mininterval=120
em0::addr="2607:f3e0:xx:xx::":prefixlen#64:"
:rdnss="2001:4860:4860::8888,2001:4860:4860::8844":\
:mininterval#120:\
:dnssl="sentex.net":
On my test box I added an anon dtrace probe to fire when /sbin/rtsol is
called.
dtrace -A -n 'syscall::execve:entry /strstr(copyinstr(arg0), "rtsol") !=
NULL/ { printf("\n--- CAUGHT RTSOL ---\nCaller Name: %s\nCaller Args:
%s\nParent PID: %d\n", execname, curpsinfo->pr_psargs, ppid); }'
Sure enough over serial I see even with the physical interface down
/sbin/rtsol getting called.
# dtrace -a
CPU ID FUNCTION:NAME
3 82297 execve:entry
--- CAUGHT RTSOL ---
Caller Name: sh
Caller Args: /bin/sh -o verify /etc/rc autoboot
Parent PID: 221
so the bootup process does indeed call the userland /sbin/rtsol to
configure the ipv6 address.
I then renamed /sbin/rtsol to be just a shell script that exits out and
as expected, no ipv6 address when I have
ifconfig_igc0="DHCP"
ifconfig_igc0_ipv6="inet6 accept_rtadv"
in /etc/rc.conf
Box booted up with igc0 disconnected and I am in via serial
# ifconfig igc0
igc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4e427bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether 60:be:b4:29:19:b2
inet6 fe80::62be:b4ff:fe29:19b2%igc0 prefixlen 64 scopeid 0x1
media: Ethernet autoselect
status: no carrier
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
I startup dtrace to watch, and it seems just the one call at bootup time
(in /etc/network.subr)
dtrace -a
CPU ID FUNCTION:NAME
2 82297 execve:entry
--- CAUGHT RTSOL ---
Caller Name: sh
Caller Args: /bin/sh -o verify /etc/rc autoboot
Parent PID: 223
I physically connect the NIC, but no ipv6 address of course. A few min
later, later I get an advertisement and response solicitation and I get
an IP and default route. Even though DNS and domain info are pushed in
the packet (confirmed via pcap), they dont get processed since rtsol
does not get called in this format and rtsold is not running.
This sort of seems to make sense based on what I have found about
"passive SLAAC" on FreeBSD.
ifconfig igc0 | grep RT
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
If I do a service rtsold enable it looks different, but expected. My
anon dtrace prob sees the same rtsol call from the bootup script and
then rtsold is also started.
dtrace -a
CPU ID FUNCTION:NAME
0 82297 execve:entry
--- CAUGHT RTSOL ---
Caller Name: sh
Caller Args: /bin/sh -o verify /etc/rc autoboot
Parent PID: 221
0 82297 execve:entry
--- CAUGHT RTSOL ---
Caller Name: limits
Caller Args: limits -C daemon /usr/sbin/rtsold -a -i
Parent PID: 592
I reboot with the interface up, I still see /sbin/rtsol being called and
rtsold properly processes the full response to update my /etc/resolv.conf
However, if I startup the box with the physical ethernet down, I still
have to wait for the router to do its periodic advertisement. devd on
the physical interface coming up does not call /sbin/rtsol in my case so
I have to wait for the periodic advertisement from the upstream router.
