From nobody Mon Dec 22 20:17:49 2025 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dZqFg1bZPz6LXV4 for ; Mon, 22 Dec 2025 20:17:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smarthost1.sentex.ca", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dZqFd5xlCz3wxf for ; Mon, 22 Dec 2025 20:17:57 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.18.1/8.18.1) with ESMTPS id 5BMKHoAY027619 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL) for ; Mon, 22 Dec 2025 15:17:50 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:8878:3fe3:dbff:f34f] ([IPv6:2607:f3e0:0:4:8878:3fe3:dbff:f34f]) by pyroxene2a.sentex.ca (8.18.1/8.15.2) with ESMTPS id 5BMKHn2w089045 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Mon, 22 Dec 2025 15:17:49 -0500 (EST) (envelope-from mike@sentex.net) Content-Type: multipart/alternative; boundary="------------h0WKsurm8gHXlns8Xz2U3oos" Message-ID: Date: Mon, 22 Dec 2025 15:17:49 -0500 List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "freebsd-security@freebsd.org" From: mike tancsa Subject: FreeBSD-SA-25:12.rtsold.asc clarification needed Autocrypt: addr=mike@sentex.net; keydata= xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg== X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.41 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_LONG(-0.99)[-0.995]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; RCVD_IN_DNSWL_LOW(-0.20)[2607:f3e0:0:1::12:from,199.212.134.19:received]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.08)[0.082]; DMARC_NA(0.00)[sentex.net]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~] X-Rspamd-Queue-Id: 4dZqFd5xlCz3wxf This is a multi-part message in MIME format. --------------h0WKsurm8gHXlns8Xz2U3oos Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Just trying to better understand this issue as it says no work around is available yet if ipv6 is disabled, this seems like a work around ? No workaround is available. Users not using IPv6, and IPv6 users that do not configure the system to accept router advertisement messages, are not affected. A network interface listed by ifconfig(8) accepts router advertisement messages if the string "ACCEPT_RTADV" is present in the nd6 option list. The issue seems to be in userland with the patch being --- usr.sbin/rtsold/rtsol.c.orig +++ usr.sbin/rtsold/rtsol.c And more specifically, to be vulnerable, does rtsold need to be actually running ? Or does the program get called by the kernel somehow. ie. I need rtsold_enable="YES" in /etc/rc.conf and seeing ACCEPT_RTADV in ifconfig is not actually sufficient to be vulnerable to this ? Is patching the userland daemon enough ? It seems to be "Restart the applicable daemons, or reboot the system."     ---Mike --------------h0WKsurm8gHXlns8Xz2U3oos Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Just trying to better understand this issue as it says no work around is available yet if ipv6 is disabled, this seems like a work around ? 

No workaround is available.  Users not using IPv6, and IPv6 users that do not
configure the system to accept router advertisement messages, are not affected.
A network interface listed by ifconfig(8) accepts router advertisement messages
if the string "ACCEPT_RTADV" is present in the nd6 option list.


The issue seems to be in userland with the patch being
--- usr.sbin/rtsold/rtsol.c.orig
+++ usr.sbin/rtsold/rtsol.c

And more specifically, to be vulnerable, does rtsold need to be actually running ? Or does the program get called by the kernel somehow. ie. I need 
rtsold_enable="YES" in /etc/rc.conf
and seeing 
ACCEPT_RTADV
in ifconfig is not actually sufficient to be vulnerable to this ?

Is patching the userland daemon enough ? It seems to be

"Restart the applicable daemons, or reboot the system."


    ---Mike

--------------h0WKsurm8gHXlns8Xz2U3oos-- From nobody Mon Dec 22 21:03:08 2025 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dZrG85c0bz6Lc5q for ; Mon, 22 Dec 2025 21:03:28 +0000 (UTC) (envelope-from polarian@polarian.dev) Received: from mail.polarian.dev (0.e.1.e.8.3.e.f.f.f.e.3.6.1.2.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:57a:2385:216:3eff:fe38:e1e0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dZrG7661Fz43gx for ; Mon, 22 Dec 2025 21:03:27 +0000 (UTC) (envelope-from polarian@polarian.dev) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=polarian.dev header.s=polarian header.b=aLyyoBUM; dmarc=pass (policy=reject) header.from=polarian.dev; spf=softfail (mx1.freebsd.org: 2001:8b0:57a:2385:216:3eff:fe38:e1e0 is neither permitted nor denied by domain of polarian@polarian.dev) smtp.mailfrom=polarian@polarian.dev DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=polarian.dev; s=polarian; t=1766437389; bh=aNmfZF7j/nFNbGqfqq08Qr+00EzAAEraEQncjcgQmFk=; h=Date:From:To:Subject:In-Reply-To:References; b=aLyyoBUMbeBTdY7mW+3cN0+1O9QOMiF4J4K9QszzivYxXf0agES6f6E3MwIjOzSWR md6Oj4liYmZfPfhWJtPOE98PEhR5mWmRTAM1b/fjo/PpxKQJVsJizVmsuhG/prQwW2 fcnYWd/eIqyyRPbInc28AaEvBDbuEhK/iMdAixPs= Date: Mon, 22 Dec 2025 21:03:08 +0000 From: Polarian To: freebsd-security@freebsd.org Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed Message-ID: <20251222210308.4352ee6f@Hydrogen> In-Reply-To: References: X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: / X-Spamd-Result: default: False [0.41 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.893]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; R_DKIM_ALLOW(-0.20)[polarian.dev:s=polarian]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DMARC_POLICY_ALLOW(0.00)[polarian.dev,reject]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; DKIM_TRACE(0.00)[polarian.dev:+] X-Rspamd-Queue-Id: 4dZrG7661Fz43gx Hey, I discussed this within #freebsd on libera.chat. > Just trying to better understand this issue as it says no work around > is available yet if ipv6 is disabled, this seems like a work around ? So is unplugging the ethernet cable and burying the device in a lead box surrounded in 3 metres of concrete. > And more specifically, to be vulnerable, does rtsold need to be > actually running ? Or does the program get called by the kernel > somehow. ie. I need rtsold_enable="YES" in /etc/rc.conf and seeing > ACCEPT_RTADV > in ifconfig is not actually sufficient to be vulnerable to this ? This was a misconception which was explained within #freebsd. rtsol actually is poorly named, as rtsol actually handles rtadv. If you have ACCEPT_RTADV option on your interface, router advertisement packets received is passed to rtsol. So if ACCEPT_RTADV AND OR rtsold is in use, you are vulnerable to the RCE. On your home network this is not a big deal, but if you use your device on public wifi it would be quite the concern. > Is patching the userland daemon enough ? It seems to be No. Hope this helps, and I hope I properly relayed the solution from IRC. Take care, -- Polarian Jabber/XMPP: polarian@icebound.dev From nobody Mon Dec 22 21:08:02 2025 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dZrMY3v02z6LcjR for ; Mon, 22 Dec 2025 21:08:09 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smarthost1.sentex.ca", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dZrMY1RT8z45Dm for ; Mon, 22 Dec 2025 21:08:09 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; none Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.18.1/8.18.1) with ESMTPS id 5BML83we043536 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Mon, 22 Dec 2025 16:08:03 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:8878:3fe3:dbff:f34f] ([IPv6:2607:f3e0:0:4:8878:3fe3:dbff:f34f]) by pyroxene2a.sentex.ca (8.18.1/8.15.2) with ESMTPS id 5BML82Rs002547 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 22 Dec 2025 16:08:02 -0500 (EST) (envelope-from mike@sentex.net) Content-Type: multipart/alternative; boundary="------------VPFjZ4UcYHbuHL09s1JbKbmS" Message-ID: <479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net> Date: Mon, 22 Dec 2025 16:08:02 -0500 List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed To: Polarian , freebsd-security@freebsd.org References: <20251222210308.4352ee6f@Hydrogen> Content-Language: en-US From: mike tancsa Autocrypt: addr=mike@sentex.net; keydata= xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg== In-Reply-To: <20251222210308.4352ee6f@Hydrogen> X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dZrMY1RT8z45Dm This is a multi-part message in MIME format. --------------VPFjZ4UcYHbuHL09s1JbKbmS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/22/2025 4:03 PM, Polarian wrote: >> Is patching the userland daemon enough ? It seems to be > No. > In https://security.FreeBSD.org/patches/SA-25:12/rtsold.patch I only see a code change for the userland daemon. Is that code somehow being pulled into the the kernel during buildworld ? ---Mike --------------VPFjZ4UcYHbuHL09s1JbKbmS Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 12/22/2025 4:03 PM, Polarian wrote:

      

        
Is patching the userland daemon enough ? It seems to be


      

      
No.



    

    
In

    
https://security.FreeBSD.org/patches/SA-25:12/rtsold.patch

I only see a code change for the userland daemon. Is that code somehow being pulled into the the kernel during buildworld ?

	---Mike

    


    

    


    

    

      

    

  


--------------VPFjZ4UcYHbuHL09s1JbKbmS--

From nobody Mon Dec 22 21:11:00 2025
X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dZrQw3wm3z6Ld7G
	for ; Mon, 22 Dec 2025 21:11:04 +0000 (UTC)
	(envelope-from polarian@polarian.dev)
Received: from mail.polarian.dev (0.e.1.e.8.3.e.f.f.f.e.3.6.1.2.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:57a:2385:216:3eff:fe38:e1e0])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4dZrQv558hz469F
	for ; Mon, 22 Dec 2025 21:11:03 +0000 (UTC)
	(envelope-from polarian@polarian.dev)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=polarian.dev header.s=polarian header.b=WRegrgCE;
	dmarc=pass (policy=reject) header.from=polarian.dev;
	spf=softfail (mx1.freebsd.org: 2001:8b0:57a:2385:216:3eff:fe38:e1e0 is neither permitted nor denied by domain of polarian@polarian.dev) smtp.mailfrom=polarian@polarian.dev
DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=polarian.dev;
	s=polarian; t=1766437861;
	bh=YJ7GgoIDquq/4ex1bkECAUMAgY9a/rGbwKzj0vgToME=;
	h=Date:From:To:Subject:In-Reply-To:References;
	b=WRegrgCE8atqxOUKmXpLDnDSDF6X6gkMi/ajjZz8/W8jB4bH6kdxbX0sPOKt8iE/W
	 DlyaBbhPFMciMBqDqFdd5ksalmnq0v0Jf471IsMX1QFXwjZIBwE9T08Q2rw7tLB9Ww
	 smbG3l6ZsvSvL+yM+VOIi0rXIZC3/Wbj9dfAgYlg=
Date: Mon, 22 Dec 2025 21:11:00 +0000
From: Polarian 
To: freebsd-security@freebsd.org
Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed
Message-ID: <20251222211100.3f245825@Hydrogen>
In-Reply-To: <479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net>
References: 
	<20251222210308.4352ee6f@Hydrogen>
	<479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net>
X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0)
List-Id: Security issues 
List-Archive: https://lists.freebsd.org/archives/freebsd-security
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
X-BeenThere: freebsd-security@freebsd.org
Sender: owner-freebsd-security@FreeBSD.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spamd-Bar: /
X-Spamd-Result: default: False [0.65 / 15.00];
	VIOLATED_DIRECT_SPF(3.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.65)[-0.649];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[];
	R_DKIM_ALLOW(-0.20)[polarian.dev:s=polarian];
	ONCE_RECEIVED(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:20712, ipnet:2001:8b0::/34, country:GB];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	DMARC_POLICY_ALLOW(0.00)[polarian.dev,reject];
	MLMMJ_DEST(0.00)[freebsd-security@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_ZERO(0.00)[0];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_NONE(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	DKIM_TRACE(0.00)[polarian.dev:+]
X-Rspamd-Queue-Id: 4dZrQv558hz469F

Hey,

> I only see a code change for the userland daemon. Is that code
> somehow being pulled into the the kernel during buildworld ?

Both rtsold and rtsol afaik are userland. I have not inspected the
build, but someone else from #freebsd did and stated both of them are
compiled together.

-- 
Polarian
Jabber/XMPP: polarian@icebound.dev

From nobody Mon Dec 22 21:25:44 2025
X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dZrm42LDSz6LfSL
	for ; Mon, 22 Dec 2025 21:25:56 +0000 (UTC)
	(envelope-from mike@sentex.net)
Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smarthost1.sentex.ca", Issuer "R13" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4dZrm41nQvz48xP
	for ; Mon, 22 Dec 2025 21:25:56 +0000 (UTC)
	(envelope-from mike@sentex.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19])
	by smarthost1.sentex.ca (8.18.1/8.18.1) with ESMTPS id 5BMLPj7a048636
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL);
	Mon, 22 Dec 2025 16:25:45 -0500 (EST)
	(envelope-from mike@sentex.net)
Received: from [IPV6:2607:f3e0:0:4:8878:3fe3:dbff:f34f] ([IPv6:2607:f3e0:0:4:8878:3fe3:dbff:f34f])
	by pyroxene2a.sentex.ca (8.18.1/8.15.2) with ESMTPS id 5BMLPivQ007886
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
	Mon, 22 Dec 2025 16:25:44 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-ID: 
Date: Mon, 22 Dec 2025 16:25:44 -0500
List-Id: Security issues 
List-Archive: https://lists.freebsd.org/archives/freebsd-security
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
X-BeenThere: freebsd-security@freebsd.org
Sender: owner-freebsd-security@FreeBSD.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed
To: Polarian , freebsd-security@freebsd.org
References: 
 <20251222210308.4352ee6f@Hydrogen>
 <479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net>
 <20251222211100.3f245825@Hydrogen>
Content-Language: en-US
From: mike tancsa 
Autocrypt: addr=mike@sentex.net; keydata=
 xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP
 xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s
 +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW
 yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH
 VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB
 AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs
 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W
 rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS
 j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ
 cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R
 yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw
 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk
 AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1
 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt
 RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO
 l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7
 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB
 CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8
 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM
 aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X
 rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB
 Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0
 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg==
In-Reply-To: <20251222211100.3f245825@Hydrogen>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.86
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4dZrm41nQvz48xP

On 12/22/2025 4:11 PM, Polarian wrote:
> Hey,
>
>> I only see a code change for the userland daemon. Is that code
>> somehow being pulled into the the kernel during buildworld ?
> Both rtsold and rtsol afaik are userland. I have not inspected the
> build, but someone else from #freebsd did and stated both of them are
> compiled together.

I am trying to understand if rtsold is not running and not enabled, what 
from the kernel would spin that up to expose the code path that is 
patched in the advisory?

There is only one file (userland) touched in the patch (its below). 
rtsol is based on /usr/src/usr.sbin/rtsold so the one patch seems to 
cover both of those userland files.  I dont see any archive of the irc 
chat. Do you have the text from that explaining how this code path gets 
called ? I have never heard of userland src files in FreeBSD being 
included in the kernel. Your friend is certain of this ?


--- usr.sbin/rtsold/rtsol.c.orig
+++ usr.sbin/rtsold/rtsol.c
@@ -776,6 +776,41 @@
                     argv[0], status);
  }

+#define        PERIOD 0x2e
+#define        hyphenchar(c) ((c) == 0x2d)
+#define        periodchar(c) ((c) == PERIOD)
+#define        alphachar(c) (((c) >= 0x41 && (c) <= 0x5a) || \
+           ((c) >= 0x61 && (c) <= 0x7a))
+#define        digitchar(c) ((c) >= 0x30 && (c) <= 0x39)
+
+#define        borderchar(c) (alphachar(c) || digitchar(c))
+#define        middlechar(c) (borderchar(c) || hyphenchar(c))
+
+static int
+res_hnok(const char *dn)
+{
+       int pch = PERIOD, ch = *dn++;
+
+       while (ch != '\0') {
+               int nch = *dn++;
+
+               if (periodchar(ch)) {
+                       ;
+               } else if (periodchar(pch)) {
+                       if (!borderchar(ch))
+                               return (0);
+               } else if (periodchar(nch) || nch == '\0') {
+                       if (!borderchar(ch))
+                               return (0);
+               } else {
+                       if (!middlechar(ch))
+                               return (0);
+               }
+               pch = ch, ch = nch;
+       }
+       return (1);
+}
+
  /* Decode domain name label encoding in RFC 1035 Section 3.1 */
  static size_t
  dname_labeldec(char *dst, size_t dlen, const char *src)
@@ -804,12 +839,11 @@
         }
         *dst = '\0';

-       /*
-        * XXX validate that domain name only contains valid characters
-        * for two reasons: 1) correctness, 2) we do not want to pass
-        * possible malicious, unescaped characters like `` to a script
-        * or program that could be exploited that way.
-        */
+       if (!res_hnok(dst_origin)) {
+               warnmsg(LOG_INFO, __func__,
+                   "invalid domain name '%s' was ignored", dst_origin);
+               return (0);
+       }

         return (src - src_origin);
  }


     ---Mike



From nobody Mon Dec 22 21:51:28 2025
X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dZsKq0zpSz6LhY6
	for ; Mon, 22 Dec 2025 21:51:43 +0000 (UTC)
	(envelope-from polarian@polarian.dev)
Received: from mail.polarian.dev (0.e.1.e.8.3.e.f.f.f.e.3.6.1.2.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:57a:2385:216:3eff:fe38:e1e0])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4dZsKp07Bcz3Frx
	for ; Mon, 22 Dec 2025 21:51:41 +0000 (UTC)
	(envelope-from polarian@polarian.dev)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=polarian.dev header.s=polarian header.b=jb3dRer2;
	dmarc=pass (policy=reject) header.from=polarian.dev;
	spf=softfail (mx1.freebsd.org: 2001:8b0:57a:2385:216:3eff:fe38:e1e0 is neither permitted nor denied by domain of polarian@polarian.dev) smtp.mailfrom=polarian@polarian.dev
DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=polarian.dev;
	s=polarian; t=1766440294;
	bh=V2V4d74dduIVgmt3hHlJ2Zs/KgzfigtwqLo4nr3NKVU=;
	h=Date:From:To:Subject:In-Reply-To:References;
	b=jb3dRer2xnxxTJTuuKcvMSxzRVo1wsLdAKUn8coDIkf1QVcJSdAWC/x0WddoNuLJc
	 4Z+UCV2yHpJAsBPJRYZnLic0wYC++XrWgV/sJchLUBgAHZVAp8W0UiPVnHQsI3JzGt
	 SB/m+yAlevKQbfvce0Yvi0F/VLxbH8n61nRPToKs=
Date: Mon, 22 Dec 2025 21:51:28 +0000
From: Polarian 
To: freebsd-security@freebsd.org
Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed
Message-ID: <20251222215128.212a1040@Hydrogen>
In-Reply-To: 
References: 
	<20251222210308.4352ee6f@Hydrogen>
	<479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net>
	<20251222211100.3f245825@Hydrogen>
	
X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0)
List-Id: Security issues 
List-Archive: https://lists.freebsd.org/archives/freebsd-security
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
X-BeenThere: freebsd-security@freebsd.org
Sender: owner-freebsd-security@FreeBSD.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spamd-Bar: /
X-Spamd-Result: default: False [0.48 / 15.00];
	VIOLATED_DIRECT_SPF(3.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_SHORT(-0.82)[-0.819];
	MID_RHS_NOT_FQDN(0.50)[];
	DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[];
	R_DKIM_ALLOW(-0.20)[polarian.dev:s=polarian];
	ONCE_RECEIVED(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:20712, ipnet:2001:8b0::/34, country:GB];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	DMARC_POLICY_ALLOW(0.00)[polarian.dev,reject];
	MLMMJ_DEST(0.00)[freebsd-security@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_ZERO(0.00)[0];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_NONE(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	DKIM_TRACE(0.00)[polarian.dev:+]
X-Rspamd-Queue-Id: 4dZsKp07Bcz3Frx

Hey,

> I am trying to understand if rtsold is not running and not enabled,
> what from the kernel would spin that up to expose the code path that
> is patched in the advisory?

I don't get where you are getting a kernel vulnerability from.

The advisory already explains that the RCE comes from a lack of input
validation on the domain search field. This is a userspace
vulnerability.

This passed to resolvconf which does not validate its input, which
therefore allows for an RCE.

So why we talking about code paths within the kernel? Its not within
the networking stack, it is a vulnerability within the userspace
utilities.

-- 
Polarian
Jabber/XMPP: polarian@icebound.dev

From nobody Mon Dec 22 22:05:06 2025
X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dZsdP5WJYz6LjdW
	for ; Mon, 22 Dec 2025 22:05:13 +0000 (UTC)
	(envelope-from mike@sentex.net)
Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smarthost1.sentex.ca", Issuer "R13" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4dZsdP2jT8z3HY5
	for ; Mon, 22 Dec 2025 22:05:13 +0000 (UTC)
	(envelope-from mike@sentex.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19])
	by smarthost1.sentex.ca (8.18.1/8.18.1) with ESMTPS id 5BMM57uN061976
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL);
	Mon, 22 Dec 2025 17:05:07 -0500 (EST)
	(envelope-from mike@sentex.net)
Received: from [IPV6:2607:f3e0:0:4:8878:3fe3:dbff:f34f] ([IPv6:2607:f3e0:0:4:8878:3fe3:dbff:f34f])
	by pyroxene2a.sentex.ca (8.18.1/8.15.2) with ESMTPS id 5BMM55VR018608
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
	Mon, 22 Dec 2025 17:05:06 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-ID: 
Date: Mon, 22 Dec 2025 17:05:06 -0500
List-Id: Security issues 
List-Archive: https://lists.freebsd.org/archives/freebsd-security
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
X-BeenThere: freebsd-security@freebsd.org
Sender: owner-freebsd-security@FreeBSD.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed
To: Polarian , freebsd-security@freebsd.org
References: 
 <20251222210308.4352ee6f@Hydrogen>
 <479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net>
 <20251222211100.3f245825@Hydrogen>
 
 <20251222215128.212a1040@Hydrogen>
Content-Language: en-US
From: mike tancsa 
Autocrypt: addr=mike@sentex.net; keydata=
 xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP
 xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s
 +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW
 yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH
 VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB
 AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs
 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W
 rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS
 j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ
 cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R
 yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw
 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk
 AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1
 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt
 RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO
 l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7
 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB
 CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8
 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM
 aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X
 rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB
 Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0
 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg==
In-Reply-To: <20251222215128.212a1040@Hydrogen>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.86
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4dZsdP2jT8z3HY5

On 12/22/2025 4:51 PM, Polarian wrote:
> Hey,
>
>> I am trying to understand if rtsold is not running and not enabled,
>> what from the kernel would spin that up to expose the code path that
>> is patched in the advisory?
> I don't get where you are getting a kernel vulnerability from.
>
> The advisory already explains that the RCE comes from a lack of input
> validation on the domain search field. This is a userspace
> vulnerability.
>
> This passed to resolvconf which does not validate its input, which
> therefore allows for an RCE.
>
> So why we talking about code paths within the kernel? Its not within
> the networking stack, it is a vulnerability within the userspace
> utilities.

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


From nobody Mon Dec 22 22:25:45 2025
X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dZt5H56HRz6Ll8n
	for ; Mon, 22 Dec 2025 22:25:55 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4dZt5F3cZgz3Kw9
	for ; Mon, 22 Dec 2025 22:25:53 +0000 (UTC)
	(envelope-from karl@denninger.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
Received: from denninger.net (unknown [162.81.137.111])
	by colo1.denninger.net (Postfix) with ESMTP id 3E9324E602
	for ; Mon, 22 Dec 2025 17:25:47 -0500 (EST)
Received: by denninger.net (Postfix, from userid 58)
	id 10C9E4AFE5C; Mon, 22 Dec 2025 17:25:47 -0500 (EST)
X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on NewFS.denninger.net
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=3.0 tests=ALL_TRUSTED,BAYES_00,
	HTML_FONT_SIZE_HUGE,HTML_MESSAGE autolearn=no autolearn_force=no
	version=4.0.2
X-Spam-Report: 
	* -3.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	* -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
	*      [score: 0.0000]
	*  0.0 HTML_MESSAGE BODY: HTML included in message
	*  0.0 HTML_FONT_SIZE_HUGE BODY: HTML font size is huge
Received: from [192.168.10.16] (D6.Denninger.Net [192.168.10.16])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id BC84B4C022C
	for ; Mon, 22 Dec 2025 17:25:46 -0500 (EST)
Message-ID: <9db9807a-a05e-4bcf-85b5-8e921db91f5b@denninger.net>
Date: Mon, 22 Dec 2025 17:25:45 -0500
List-Id: Security issues 
List-Archive: https://lists.freebsd.org/archives/freebsd-security
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
X-BeenThere: freebsd-security@freebsd.org
Sender: owner-freebsd-security@FreeBSD.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed
To: freebsd-security@freebsd.org
References: 
 <20251222210308.4352ee6f@Hydrogen>
 <479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net>
 <20251222211100.3f245825@Hydrogen>
 
 <20251222215128.212a1040@Hydrogen>
 
From: Karl Denninger 
Content-Language: en-US
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000907020802080609020905"
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.27 / 15.00];
	SIGNED_SMIME(-2.00)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_SPAM_MEDIUM(1.00)[0.998];
	DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	NEURAL_HAM_SHORT(-0.47)[-0.466];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	MIME_BASE64_TEXT(0.10)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	FREEFALL_USER(0.00)[karl];
	RCVD_COUNT_THREE(0.00)[3];
	MLMMJ_DEST(0.00)[freebsd-security@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	HAS_ATTACHMENT(0.00)[]
X-Rspamd-Queue-Id: 4dZt5F3cZgz3Kw9

This is a cryptographically signed message in MIME format.

--------------ms000907020802080609020905
Content-Type: multipart/alternative;
 boundary="------------k5fHmPzZKkQmktE2ZRi8Uxxu"

--------------k5fHmPzZKkQmktE2ZRi8Uxxu
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

DQpPbiAxMi8yMi8yMDI1IDE3OjA1LCBtaWtlIHRhbmNzYSB3cm90ZToNCj4gT24gMTIvMjIv
MjAyNSA0OjUxIFBNLCBQb2xhcmlhbiB3cm90ZToNCj4+IEhleSwNCj4+DQo+Pj4gSSBhbSB0
cnlpbmcgdG8gdW5kZXJzdGFuZCBpZiBydHNvbGQgaXMgbm90IHJ1bm5pbmcgYW5kIG5vdCBl
bmFibGVkLA0KPj4+IHdoYXQgZnJvbSB0aGUga2VybmVsIHdvdWxkIHNwaW4gdGhhdCB1cCB0
byBleHBvc2UgdGhlIGNvZGUgcGF0aCB0aGF0DQo+Pj4gaXMgcGF0Y2hlZCBpbiB0aGUgYWR2
aXNvcnk/DQo+PiBJIGRvbid0IGdldCB3aGVyZSB5b3UgYXJlIGdldHRpbmcgYSBrZXJuZWwg
dnVsbmVyYWJpbGl0eSBmcm9tLg0KPj4NCj4+IFRoZSBhZHZpc29yeSBhbHJlYWR5IGV4cGxh
aW5zIHRoYXQgdGhlIFJDRSBjb21lcyBmcm9tIGEgbGFjayBvZiBpbnB1dA0KPj4gdmFsaWRh
dGlvbiBvbiB0aGUgZG9tYWluIHNlYXJjaCBmaWVsZC4gVGhpcyBpcyBhIHVzZXJzcGFjZQ0K
Pj4gdnVsbmVyYWJpbGl0eS4NCj4+DQo+PiBUaGlzIHBhc3NlZCB0byByZXNvbHZjb25mIHdo
aWNoIGRvZXMgbm90IHZhbGlkYXRlIGl0cyBpbnB1dCwgd2hpY2gNCj4+IHRoZXJlZm9yZSBh
bGxvd3MgZm9yIGFuIFJDRS4NCj4+DQo+PiBTbyB3aHkgd2UgdGFsa2luZyBhYm91dCBjb2Rl
IHBhdGhzIHdpdGhpbiB0aGUga2VybmVsPyBJdHMgbm90IHdpdGhpbg0KPj4gdGhlIG5ldHdv
cmtpbmcgc3RhY2ssIGl0IGlzIGEgdnVsbmVyYWJpbGl0eSB3aXRoaW4gdGhlIHVzZXJzcGFj
ZQ0KPj4gdXRpbGl0aWVzLg0KPg0KPiBXaGVuIEkgYXNrZWQgaWYgcGF0Y2hpbmcgdGhlIHVz
ZXJsYW5kIGNvZGUgd2FzIGVub3VnaCwgeW91IHNhaWQgbm8uDQo+DQo+IEZyb20gd2hhdCBJ
IHVuZGVyc3RhbmQgaGF2aW5nIEFDQ0VQVF9SVEFEViBvbiBhbiBpbnRlcmZhY2UgbWVhbnMg
dGhlIA0KPiBrZXJuZWwgaXMgcHJvY2Vzc2luZyBydGFkdiBwYWNrZXRzLsKgIFRoZSBhZHZp
c29yeSBtZW50aW9ucyB0aGF0LCBidXQgDQo+IGl0IHNlZW1zIHRoYXRzIG5vdCBzdWZmaWNp
ZW50IHRvIHRyaWdnZXIgdGhlIGJ1ZywgYXMgcnRzb2xkIGlzIHRoZSBvbmUgDQo+IHRoYXQg
cHJvY2Vzc2VzIHRoZSB1bmNoZWNrZWQgRE5TIGluZm8uwqAgaS5lLiB5b3UgbmVlZCBib3Ro
IA0KPiBBQ0NFUFRfUlRBRFYgZW5hYmxlZCBhbmQgcnRzb2xkIGVuYWJsZWQsIG5vID8gSWYg
anVzdCBoYXZpbmcgDQo+IEFDQ0VQVF9SVEFEViBlbmFibGVkIHdvdWxkIGxlYWQgdG8gYW4g
ZXhwbG9pdCwgdGhhdCBpbXBsaWVzIGEga2VybmVsIA0KPiBidWcgbm8gPw0KPg0KPiBJIGp1
c3Qgd2FudCB0byBjb25maXJtIGlmICpub3QqIHJ1bm5pbmcgcnRzb2xkIGlzIGVub3VnaCB0
byBhdm9pZCB0aGlzIA0KPiBidWcgb3IganVzdCBoYXZpbmcgdGhlIG1lcmUgcHJlc2VuY2Ug
b2YgSVB2NiBjYW4gbGVhZCB0byBleHBsb2l0LiBJZiANCj4gdGhlIGxhdHRlciwgaG93IGlz
IHRoYXQgYWN0dWFsbHkgd29ya2luZy4NCj4NCj4gwqAgwqAgLS0tTWlrZQ0KPg0KVW5sZXNz
IEkgYW0gbWlzc2luZyBzb21ldGhpbmcgc2VyaW91cyB5b3UgYXJlIGNvcnJlY3QuDQoNCldp
dGhvdXQgcnRzb2xkIGlmIHlvdSBoYXZlIGFuIGludGVyZmFjZSB0aGF0IGdvZXMgZG93biBh
bmQgY29tZXMgYmFjayB1cCANCnlvdSBsaWtlbHkgd2lsbCBub3QgZ2V0IHJvdXRlcyAoaW5j
bHVkaW5nIGRlZmF1bHQpIHVudGlsIHRoZSBnYXRld2F5IA0KcGVyZm9ybXMgaXRzIG5leHQg
dGltZWQgdHJhbnNtaXNzaW9uICh0eXBpY2FsbHkgMTAgbWludXRlcy4pDQoNCldpdGggaXQg
ZW5hYmxlZCBidXQgbm8gb3B0aW9ucyBzcGVjaWZpZWQgaXQgY29tZXMgdXAgb24gbXkgbWFj
aGluZXMgYXMgDQoiLWEgLWkiIHdoaWNoIGlzICJzZWVrIHRoZSBpbnRlcmZhY2VzIHRvIHNv
bGljaXQgdXBvbiBhbmQgZG8gc28gDQppbW1lZGlhdGVseSBvbiBzdGFydC4iDQoNClRoZSBw
cm9ibGVtIGlzIHRoYXQgdGhlIHJlc29sdmNvbmYoOCkgc2NyaXB0IGlzIHJ1biBieSBkZWZh
dWx0ICh1bmxlc3MgDQp5b3Ugc3BlY2lmeSBzb21ldGhpbmcgZWxzZSB3aXRoIHRoZSAtUiBz
d2l0Y2gpIGlmIHJ0c29sZCBpcyBydW5uaW5nIGFuZCANCmEgRE5TIGNvbmZpZ3VyYXRpb24g
b3B0aW9uIChSRE5TUyBvciBETlNTTCkgYWR2ZXJ0aXNlbWVudCBpcyByZWNlaXZlZC7CoCAN
CklmIHJ0c29sZCBpcyBub3QgcnVubmluZyB0aGVuIGl0IHNob3VsZCBub3QgcmVzdWx0IGlu
IGEgcHJvYmxlbSBwZXItc2UgDQpob3dldmVyIHlvdSBnZXQgdGhlIHBvc3NpYmlsaXR5IG9m
IG5vdCBoYXZpbmcgcm91dGVzIHdoZW4gdGhlIGJveCBjb21lcyANCnVwIHVudGlsIHRoZSBn
YXRld2F5IHBlcmZvcm1zIGl0cyBuZXh0IHRpbWVkIHRyYW5zbWlzc2lvbi4NCg0KLS0gDQpL
YXJsIERlbm5pbmdlcg0Ka2FybEBkZW5uaW5nZXIubmV0DQovVGhlIE1hcmtldCBUaWNrZXIv
DQovW1MvTUlNRSBlbmNyeXB0ZWQgZW1haWwgcHJlZmVycmVkXS8NCg==
--------------k5fHmPzZKkQmktE2ZRi8Uxxu
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



  
    
  
  
    


    

    
On 12/22/2025 17:05, mike tancsa wrote=
:

    

    
On
      12/22/2025 4:51 PM, Polarian wrote:
      

      
Hey,
        

        

        
I am trying to understand if rtsold is
          not running and not enabled,
          

          what from the kernel would spin that up to expose the code
          path that
          

          is patched in the advisory?
          

        

        I don't get where you are getting a kernel vulnerability from.
        

        

        The advisory already explains that the RCE comes from a lack of
        input
        

        validation on the domain search field. This is a userspace
        

        vulnerability.
        

        

        This passed to resolvconf which does not validate its input,
        which
        

        therefore allows for an RCE.
        

        

        So why we talking about code paths within the kernel? Its not
        within
        

        the networking stack, it is a vulnerability within the userspace
        

        utilities.
        

      

      

      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.=C2=A0 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.=C2=A0 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.
      

      

      =C2=A0 =C2=A0 ---Mike=C2=A0

      

    

    
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.=C2=A0 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.

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]<=
/div>
  


--------------k5fHmPzZKkQmktE2ZRi8Uxxu--

--------------ms000907020802080609020905
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
C4owggWZMIIDgaADAgECAhRZU8dKdMneRI1Vq5kv0k54Q5rQuDANBgkqhkiG9w0BAQsFADB2
MQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRYwFAYDVQQKDA1EZW5uaW5nZXIu
TmV0MRcwFQYDVQQDDA5EZW5uaW5nZXIgUm9vdDEiMCAGCSqGSIb3DQEJARYTYWRtaW5AZGVu
bmluZ2VyLm5ldDAeFw0yNDA1MDkyMTA4MDNaFw00NDA1MDQyMTA4MDNaMF0xCzAJBgNVBAYT
AlVTMRIwEAYDVQQIDAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNV
BAMMGURlbm5pbmdlci5OZXQgU2lnbmluZyBJbnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDbR0tSiuLG5HPfo+cWtdeYQ8jc8Bjfuo0GTcNRT0glHnH1apUtInIktUknEZDH
ohahInN+mMBdKg54FCHOiYZrJbyxBIo9FwX7hRmOc+spxmSYWnOd2E/YcGInMK4ZpjPzldzB
Yt1n3zygkhx2bssxTJS3x4nv1qAXfLSZd1VwqoQufifEoPyTtymkkvHLv86vLgqAqooM/cXc
4LSIQ5u2uM308n42r8RkKtp7X1v9fJW8oRZN2XnFZtiUPH44YY2rHqyN2Hea9Y3+TXbldXjo
xhPHTA+JYVFq8KTmbQBqU7YcMhlIG0cSxPeFLMxnP6pqPcIVTAlK+a6YGRFppfjZAgMBAAGj
ggE2MIIBMjAdBgNVHQ4EFgQUH+VuxXhBxaJAQrvDekwkH91hBi4wgbMGA1UdIwSBqzCBqIAU
RFYC4p6L6KITnEvrpx2cyt+PcMmheqR4MHYxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlUZW5u
ZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5OZXQxFzAVBgNVBAMMDkRlbm5pbmdlciBSb290
MSIwIAYJKoZIhvcNAQkBFhNhZG1pbkBkZW5uaW5nZXIubmV0ghQZE7NBItWtQsCouuwU6jZ+
HPPwnjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+gLaAr
hilodHRwOi8vd3d3LmRlbm5pbmdlci5uZXQvcm9vdC1yZXZva2VkLmNybDANBgkqhkiG9w0B
AQsFAAOCAgEAfFbhPc82AfhyUqONs7IccYD36w+OP4nQgwfC4IWf3y/aQAZ2Zk6IITzYqwf7
PFM0bJRT3zi7xyetolqHDhfMJvnOQWpITZiyM/FSKwIvuBsy/uJUqPuqui4XQMYoSbAA1qmI
MW/z7VZZHwaRFoeWE40UirYcf0fNcooBZ72bmd+iBaVyjtZvky0Vgcz0eC6e6LR5kNb23yC6
TkyQIlGyQkK5/afXUYFzk49rOHVbVyxW3oXRfq8Ow6HCrpDGAS8p84S04MFwBVAUfbe4aXs3
bampaI2LzKgkVywyFP14LSvvdjCfLYfnLy1Z9hm2EHMqNHA2tCGdRhWp2d7aZC1MYFqng0ZS
fjPJjqHrI1qPU0p6k9A1GxAtrQlL2v/IUzUnMZkiawFV3qlxMGZf/kTYTUOcJhx1KU4zSLHu
80qO7ldRpp5gHssCAGFbeTu2gp6LxfmaFhLPDBJ1VGfdPx9lUrU/9OcoHczcl5x2Rb8IUZyX
9elzP5WdAU8p5R/DLlOAq24VcabhFtYBCA2dOESLupSfWKNQuJCN/1gz7ysSc+mjnnPV77IO
mpszJfkFFJEDNJlGIVKX1vwwygtC/9Ulox8frgbZlRAYAgDc/YbOBFxticVVre0Y3Ujx6Kzb
tkgZRlgfdZWbT1W5smncqJxg5qAL8e/yTb3fCe2nJ0jhiP4wggXpMIIE0aADAgECAhMAmNFt
CiCF3j+FwQLYtBTmGjzkMA0GCSqGSIb3DQEBCwUAMF0xCzAJBgNVBAYTAlVTMRIwEAYDVQQI
DAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNVBAMMGURlbm5pbmdl
ci5OZXQgU2lnbmluZyBJbnQwHhcNMjQwNTEwMTkyNjU5WhcNMjkwNTA5MTkyNjU5WjBXMQsw
CQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRcwFQYDVQQKDA5LYXJsIERlbm5pbmdl
cjEbMBkGA1UEAwwSa2FybEBkZW5uaW5nZXIubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8A
MIICCgKCAgEAvh1UssVbSYctzobPjwBkbjv/w4WvQNepeRTwE6+sLnXvc41+X9pa5EclPL4Q
l02Vu1m71mSqXGfK9HbWZoivbhefBHOoYb35MSc24PelhwcORbpneWoWc7giQ7QgFlvEe/yj
fs8M0H9fgdzFS5m2lwBQbis8kioSjHB2yt/8I1GE4Mvt1Cur9kga6ML5FAQvo8TYN1stdhrE
13FEv/BWCF4FVT4H2Wa2ySW+R1jkKb74SC6Twg98bGCRTShD5bVylh0+0LXNhzaopIDcI/KK
jm/j3mRjIlmqbGrSpvJsbjjhjhAYQKE1U8FB5TDU4OkFAibblhQit/KjgspPR2o/vOpVFPER
uhZEV1oDGzUJtZlkREIcN2sYBi0p7Y4585ya+b7L10mEenPlyi3eSkGXEuiy/BR2DY6lShwW
DPoQ5602TKmttCSwBdWGoLrQ4jEVEVNt4lku2wPbTHF3KpHJU0g7RbcWoUYn10SOxKathkir
hF3v9U32+QhPELGwqRrH0sL9rWf0qalRtPDHUYl8TebZmYkFqNeSMlqHijl5f4SsQPSj7gx5
4F19Ntm9ZcvuWTmW8QQGWTKHeMuG+BYkVIUSPe6/ZQsbD/xDx7rkyGfNgWIa4W7Wm/B7kaNq
H53tk3wFmNgZQOxMTPF0oTHfW0T2azU6JD0D1AlgoAnSAE0CAwEAAaOCAaYwggGiMDoGCCsG
AQUFBwEBBC4wLDAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AuZGVubmluZ2VyLm5ldDo3Nzc3
MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgQ2xpZW50IENlcnRp
ZmljYXRlMB0GA1UdDgQWBBSxJZjVnlYLAT3uzvDYgc4742J6UTCBswYDVR0jBIGrMIGogBQf
5W7FeEHFokBCu8N6TCQf3WEGLqF6pHgwdjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5l
c3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLk5ldDEXMBUGA1UEAwwORGVubmluZ2VyIFJvb3Qx
IjAgBgkqhkiG9w0BCQEWE2FkbWluQGRlbm5pbmdlci5uZXSCFFlTx0p0yd5EjVWrmS/STnhD
mtC4MB0GA1UdEQQWMBSBEmthcmxAZGVubmluZ2VyLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEA
TrQ45/tBN3SiuqItFv/V+CF3h7Hxe0YLsL+A/P+q9ZhxIscaNjaclgQhPA+rUr+l8DGoXJ/w
yAl1E0SSBK+9phIc/9xFOBg3rCy4ngubzP+lHS1t03nMCBSUNsu5qPzqLBPiKaPabUu3Gr9o
koRezSszgM3/zNJfr8cMO93csCK/fBccsMx5q+3nxB5XeT7UciicjfEzUA4m2mQxBmGk9SSU
147Gy8UmdSq57Tw82KqUrQ1pJ6IOzVPLREpwlqGbHykSU3MwtPYPtfQeFVjvO/XcWvoFQjbV
UyhzAqMMYFudxoVLlJQiAgU38OScTLDgKxCO41h7VOjb2mss0zHndzGCBZUwggWRAgEBMHQw
XTELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2Vy
Lm5ldDEiMCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC
2LQU5ho85DANBglghkgBZQMEAgMFAKCCAvIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc
BgkqhkiG9w0BCQUxDxcNMjUxMjIyMjIyNTQ2WjBPBgkqhkiG9w0BCQQxQgRAklQQDf0qrvji
S2kecmt3GhHgi3J0bc5ZmeCqYVcgNr1EJEIWSgSVME10GZVAQW2W1PZ+ccoXjAx3fxNGV3Ln
MTCBgwYJKwYBBAGCNxAEMXYwdDBdMQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2Vl
MRYwFAYDVQQKDA1EZW5uaW5nZXIubmV0MSIwIAYDVQQDDBlEZW5uaW5nZXIuTmV0IFNpZ25p
bmcgSW50AhMAmNFtCiCF3j+FwQLYtBTmGjzkMIGFBgsqhkiG9w0BCRACCzF2oHQwXTELMAkG
A1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLm5ldDEi
MCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC2LQU5ho8
5DCCAVcGCSqGSIb3DQEJDzGCAUgwggFEMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI
KoZIhvcNAwcwDQYIKoZIhvcNAwICAQUwDQYIKoZIhvcNAwICAQUwBwYFKw4DAgcwDQYIKoZI
hvcNAwICAQUwBwYFKw4DAhowCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAjALBglghkgBZQME
AgMwCwYJYIZIAWUDBAIEMAsGCWCGSAFlAwQCBzALBglghkgBZQMEAggwCwYJYIZIAWUDBAIJ
MAsGCWCGSAFlAwQCCjALBgkqhkiG9w0BAQEwCwYJK4EFEIZIPwACMAgGBiuBBAELADAIBgYr
gQQBCwEwCAYGK4EEAQsCMAgGBiuBBAELAzALBgkrgQUQhkg/AAMwCAYGK4EEAQ4AMAgGBiuB
BAEOATAIBgYrgQQBDgIwCAYGK4EEAQ4DMA0GCSqGSIb3DQEBAQUABIICAAxJk4Io368JYRpK
fH+zU7P7yqJPTlIPNfvnDXoe1WIxNNn0PVahDI5JRsUjiZFcOngzvDgm1QiM8csfnrf+lEqQ
h7IJGqKoahzFRr9bAY15K5JL0Dy4o6fQdMEKfATt4sN/KzI6PKzTGaTZgwyv5/X2vtljWAI0
KhBCkp89hf2YKXHEZc3wmE3B72zxrJcUmZHGj7lh1ZKeeShQXpNXX7BL+XOw7BohDc0tlin4
qLVapVZkaZvE+Qt9rSQKs8zZdw0qj5RyNMv6hRauC4U0vyBpAppGLR90C+fM+NczXWIxZfAt
fcT1Dmzv/UiSHhPwvRDZXy9x9rwrKgNVy2iWD2RykDFePkX4jRTWa0AmmuCC2NGHVSYB8Q9x
Cr+TILAUDwH7tSB/vKOFYSapyAirxNerpH/ThBadNHT+RAVmDDRODefONFEKwLMw9GtJXtwA
TO8A2OjNEwlclDBrFicFIWQ9Emqky7Cx8TvJxwJ0ViBgpUf0WiPKG43hPXut9FnBc8a+uCcJ
PIvLFkeyF7onsbSkps3uuUXxCoSlSbtSPsVEfWy1KhtAsnCu7WNX0XGdLXcHJNhCpSN9GTyv
vGl4oSStthpVEiiFjnqmOdkMTMtFbi5KTplJE+yqboXLvQIKD+gnc3YGGi4A6nSeHGg5V92/
/C+dJx4gLdq2OHlFixH0AAAAAAAA
--------------ms000907020802080609020905--

From nobody Mon Dec 22 23:23:11 2025
X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dZvMn30LJz6LqcW
	for ; Mon, 22 Dec 2025 23:23:33 +0000 (UTC)
	(envelope-from polarian@polarian.dev)
Received: from mail.polarian.dev (0.e.1.e.8.3.e.f.f.f.e.3.6.1.2.0.5.8.3.2.a.7.5.0.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:57a:2385:216:3eff:fe38:e1e0])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4dZvMm5VMkz3Rs4
	for ; Mon, 22 Dec 2025 23:23:32 +0000 (UTC)
	(envelope-from polarian@polarian.dev)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=polarian.dev header.s=polarian header.b=bhCHF2bb;
	dmarc=pass (policy=reject) header.from=polarian.dev;
	spf=softfail (mx1.freebsd.org: 2001:8b0:57a:2385:216:3eff:fe38:e1e0 is neither permitted nor denied by domain of polarian@polarian.dev) smtp.mailfrom=polarian@polarian.dev
DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=polarian.dev;
	s=polarian; t=1766445797;
	bh=bxdPQD42IiJq5qsFbSif9g5DNMgLHW8dqxk7A8fIAwY=;
	h=Date:From:To:Subject:In-Reply-To:References;
	b=bhCHF2bbgk4Ql31TbUz84wzQpJZ9Q0zEZW9UL/Baxhqr8xhvUrTe+Pm48ZpMhsu76
	 pCWczr6pixTrw5XSeZP6YVz9zU5pUQ968Qjce6SV5SSVgB1RnIK2BURDakcrPXRZdJ
	 O+36RXHYgkR/82j3zqMfpYrjteV40GPmt7Yb0Xjw=
Date: Mon, 22 Dec 2025 23:23:11 +0000
From: Polarian 
To: freebsd-security@freebsd.org
Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed
Message-ID: <20251222232311.1939bf75@Hydrogen>
In-Reply-To: <9db9807a-a05e-4bcf-85b5-8e921db91f5b@denninger.net>
References: 
	<20251222210308.4352ee6f@Hydrogen>
	<479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net>
	<20251222211100.3f245825@Hydrogen>
	
	<20251222215128.212a1040@Hydrogen>
	
	<9db9807a-a05e-4bcf-85b5-8e921db91f5b@denninger.net>
X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0)
List-Id: Security issues 
List-Archive: https://lists.freebsd.org/archives/freebsd-security
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
X-BeenThere: freebsd-security@freebsd.org
Sender: owner-freebsd-security@FreeBSD.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spamd-Bar: /
X-Spamd-Result: default: False [0.30 / 15.00];
	VIOLATED_DIRECT_SPF(3.50)[];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[];
	MID_RHS_NOT_FQDN(0.50)[];
	R_DKIM_ALLOW(-0.20)[polarian.dev:s=polarian];
	ONCE_RECEIVED(0.10)[];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_ONE(0.00)[1];
	ASN(0.00)[asn:20712, ipnet:2001:8b0::/34, country:GB];
	ARC_NA(0.00)[];
	MIME_TRACE(0.00)[0:+];
	DMARC_POLICY_ALLOW(0.00)[polarian.dev,reject];
	MLMMJ_DEST(0.00)[freebsd-security@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_COUNT_ZERO(0.00)[0];
	FROM_EQ_ENVFROM(0.00)[];
	TO_DN_NONE(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	DKIM_TRACE(0.00)[polarian.dev:+]
X-Rspamd-Queue-Id: 4dZvMm5VMkz3Rs4

Hey,

> When I asked if patching the userland code was enough, you said no.

Sorry I must have misunderstood.

> 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.)

To my knowledge, rtsold sends out router solicitation, this is has
nothing to do with resolvconf, so actually I am not 100% sure I
understand how rtsold can be used in this RCE.

The domain search would be within the advertisement, and thus parsed by
rtsol and passed to resolvconf, this is where the RCE exploit could
take place.

In any case rtsold and rtsol are both used in SLAAC, and whether its
just one or them, or both of them play a part in the RCE, the
solution is the same. Rebooting if you can spare the minute downtime is
your best bet, if not netif restart should ensure the patch is applied.

Take care,
-- 
Polarian
Jabber/XMPP: polarian@icebound.dev

From nobody Tue Dec 23 21:01:30 2025
X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dbS9c1qpKz6KrYx
	for ; Tue, 23 Dec 2025 21:01:40 +0000 (UTC)
	(envelope-from mike@sentex.net)
Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "smarthost1.sentex.ca", Issuer "R13" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4dbS9b6S0Cz47WK
	for ; Tue, 23 Dec 2025 21:01:39 +0000 (UTC)
	(envelope-from mike@sentex.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19])
	by smarthost1.sentex.ca (8.18.1/8.18.1) with ESMTPS id 5BNL1Vo1078718
	(version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL);
	Tue, 23 Dec 2025 16:01:31 -0500 (EST)
	(envelope-from mike@sentex.net)
Received: from [IPV6:2607:f3e0:0:4:25a9:f019:da19:aa51] ([IPv6:2607:f3e0:0:4:25a9:f019:da19:aa51])
	by pyroxene2a.sentex.ca (8.18.1/8.15.2) with ESMTPS id 5BNL1UaM096554
	(version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO);
	Tue, 23 Dec 2025 16:01:30 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-ID: <1c9897c2-a6cc-4fb7-b6df-896c55272d4d@sentex.net>
Date: Tue, 23 Dec 2025 16:01:30 -0500
List-Id: Security issues 
List-Archive: https://lists.freebsd.org/archives/freebsd-security
List-Help: 
List-Post: 
List-Subscribe: 
List-Unsubscribe: 
X-BeenThere: freebsd-security@freebsd.org
Sender: owner-freebsd-security@FreeBSD.org
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed (mostly
 clarified)
To: Karl Denninger , freebsd-security@freebsd.org
References: 
 <20251222210308.4352ee6f@Hydrogen>
 <479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net>
 <20251222211100.3f245825@Hydrogen>
 
 <20251222215128.212a1040@Hydrogen>
 
 <9db9807a-a05e-4bcf-85b5-8e921db91f5b@denninger.net>
Content-Language: en-US
From: mike tancsa 
Autocrypt: addr=mike@sentex.net; keydata=
 xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP
 xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s
 +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW
 yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH
 VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB
 AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs
 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W
 rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS
 j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ
 cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R
 yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw
 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk
 AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1
 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt
 RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO
 l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7
 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB
 CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8
 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM
 aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X
 rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB
 Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0
 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg==
In-Reply-To: <9db9807a-a05e-4bcf-85b5-8e921db91f5b@denninger.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.86
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4dbS9b6S0Cz47WK

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 metric 0 mtu 1500
options=4e427bb
         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

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


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.