From nobody Wed May 7 02:29:54 2025 X-Original-To: freebsd-net@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 4ZsfPC35Krz5vZsj for ; Wed, 07 May 2025 02:30:07 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsfPC2n6mz3kST; Wed, 07 May 2025 02:30:07 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746585007; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JOc5Bd4b4JSzJPegBk/pipRnUpsib90bMsU2a/STuOY=; b=Zl31KZfvKSo17iNxUKg94/KKvQEUffYLUbthcdCbHkfu2geeBuGZXsPBQSqMkgO84gc25x K/Aimb1lGGkJRj55DT8d6xXn36Qi8OnDEuJEtx+wFVRaYU00tA+F0AScfLMdOrcj7yeGRu 9Fu4mor761KDlKGWIeIS4M0TFVRQhVW0IvpUncwHYBEFIKS1dJnGbxeUhBiS1aOW+rv47i 8T2QifyOcS5UEflmKdLNPPKH/oG220Odcg48gcMQFGIadcSicrRDBXJw2maMMLQsQVpddM PIGcgwo08N08GvJpJLDMKTeBrhT+p30vMVAZpmc3l4UuSmrnBp/v78AESwBkSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746585007; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JOc5Bd4b4JSzJPegBk/pipRnUpsib90bMsU2a/STuOY=; b=UkLVB81rkdR2K1yxuiSPuXthLJnzGRwRhHV3SAlVKiHjzfQ5bcpWCuPUqCqIWCI2El1wuD 2k0v/rOuTtqEg2cH+J0JOKlkKNoJHsPx5Z/zU7ZM7uGW4PJUJuaL1qfN7+RxyfRLMOlLTu R8YVlpF1bR6JXcxX6iepwqxgUeAQUMqL15iab69cgMoX/1zIV6K4UjeKFTzN4pVHL48kCD 6FfSYqocMyj2fkNaOMhTNhFGUQlnvVF2BanuBHPN/tu7ufnAHQxkOOMtx78bF4uldeqBoH mQcZj0lnhGV8wMQtaZxwJJmAtuQw8aYPqrAEigtDaOeceM+SygKK1qCfYhcp4Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746585007; a=rsa-sha256; cv=none; b=i7xsJ6LedKczskHuzD/e7CgMYsVqw2VgcKJZZzhgWxVW9716JDieMy9P5e3gWXDypTMLFd AdxeBNMN3ToLYAnWEByIwehojmYq/tn705J84OyzFaHIdX4YSVmhBJaovBKMewN+RKocOG 5MnXjWDaS1tk1Bnk9QpSiTM+9M5UD27Dcd0+d3Nuz6mQN8T/OuiPD0MyD+3X36pKmezTQ2 s5gOSa+K6QcRAQhLsI9IiP1wfuyBZTB+Ls4HcOWKpS8itHEI4R+svqUNL1eiZRPBD1kcJ0 ZTftLl0wqsZOSYLCVotJv+l0VeLu/Q7zGv3f3GepJMWMzsxj3GZedlc++h7JBw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:19f0:6001:9db:98f0:9fe0:3545:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZsfP96Jtgz15Xs; Wed, 07 May 2025 02:30:05 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8FAD9271-E47B-435B-9796-58C0C678104C" List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: [EXTERNAL] - Re: Race condition in ether_ifattach Date: Wed, 7 May 2025 10:29:54 +0800 In-Reply-To: Cc: "freebsd-net@freebsd.org" , Gleb Smirnoff To: Mike Belanger References: <7FFF346E-3205-49A9-B95A-94A418A28220@FreeBSD.org> X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_8FAD9271-E47B-435B-9796-58C0C678104C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 5, 2025, at 9:54 PM, Mike Belanger wrote: >=20 > In our reported case a startup script is loading the driver and = bringing the interface up with ifconfig. > Since they are putting these commands to the background, so ifconfig = is not properly waiting for the driver load to fully complete. > When ifconfig is successful, it will send the IPv6 neighbour discovery = packets=E2=80=A6and this can result in a crash if ether_ifattach is not = complete (ifp->if_output is NULL). I think I see the problem. > We are considering breaking up if_attach_internal, so that = ether_ifattach can call the first part and then call the end part after = the ifp is fully setup. > We can reproduce the issue by adding an artificial delay after the = if_attach in ether_ifattach. > =20 > Mike. > =20 > =20 > From: owner-freebsd-net@FreeBSD.org = > on behalf of Zhenlei Huang = > > Date: Saturday, May 3, 2025 at 9:34=E2=80=AFPM > To: Mike Belanger > > Cc: freebsd-net@freebsd.org = >, Gleb = Smirnoff > > Subject: [EXTERNAL] - Re: Race condition in ether_ifattach >=20 > CAUTION - This email is from an external source. Please be cautious = with links and attachments. (go/taginfo) > =20 > Hi Mike, >=20 >=20 > On May 1, 2025, at 9:13 PM, Mike Belanger > wrote: > =20 > There appears to be a race condition in ether_ifattach = (if_ethersubr.c). > The ether_ifattach() function calls if_attach, where the interface = will get announced, and then ether_ifattach continues with the = initialization of the ifp. > =20 > I also noticed this while working on = https://reviews.freebsd.org/D49359 = . There's an attempt for the attaching process = https://reviews.freebsd.org/D49358 = . > =20 > > then ether_ifattach continues with the initialization of the ifp. > In most cases that should not matter, as at that moment the interface = has not been flagged up ( IFF_UP ) yet. >=20 >=20 > Is there any guarantee in FreeBSD that this race condition cannot be = exposed. > We have been running the FreeBSD stack for some time under QNX and = have just recently run into an issue with this race condition. > We are considering a modification where we have the option of = deferring the interface announcement in if_attach. > =20 > Can you elaborate how the race condition happens and how that affect = you ? > =20 > Before opening a FreeBSD bug, I wanted to check if this issue would = not be valid in a FreeBSD system. > It=E2=80=99s very clear that there is a potential race when looking at = the code, but perhaps there is a mitigation that is not obvious. > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. > =20 > Best regards, > Zhenlei > =20 > This email and any attachments are intended solely for the use of the = individual or entity to whom they are addressed. This email may contain = information that is confidential, privileged, or otherwise protected = from disclosure. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this email in = error, please immediately contact the sender and delete all copies of = this email and any attachments from your systems. Any unauthorized = review, use, dissemination, distribution, or reproduction of this email = by unintended recipients is not authorized and may be unlawful. Thank = you for your cooperation. Best regards, Zhenlei --Apple-Mail=_8FAD9271-E47B-435B-9796-58C0C678104C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 5, 2025, at 9:54 PM, Mike Belanger <mibelanger@qnx.com> = wrote:

In = our reported case a startup script is loading the driver and bringing = the interface up with ifconfig.
Since they are = putting these commands to the background, so ifconfig is not properly = waiting for the driver load to fully complete.
When ifconfig is successful, it = will send the IPv6 neighbour discovery packets=E2=80=A6and this can = result in a crash if ether_ifattach is not complete = (ifp->if_output is = NULL).

I think I see the problem.

We are considering breaking up = if_attach_internal, so that ether_ifattach can call the first part and = then call the end part after the ifp is fully setup.
We can reproduce the issue by = adding an artificial delay after the if_attach in ether_ifattach.
 
Mike.
 
 

From: owner-freebsd-net@FreeBSD.org <owner-freebsd-net@FreeBSD.org> on behalf of Zhenlei = Huang <zlei@FreeBSD.org>
Date: Saturday, May 3, 2025 = at 9:34=E2=80=AFPM
To: Mike Belanger <mibelanger@qnx.com>
Cc: freebsd-net@freebsd.org <freebsd-net@freebsd.org>, = Gleb Smirnoff <glebius@FreeBSD.org>
Subject: [EXTERNAL] - Re: Race = condition in ether_ifattach

CAUTION - This email is from an = external source. Please be cautious with links and attachments. = (go/taginfo)
 
Hi Mike,


On May 1, 2025, at 9:13 PM, Mike = Belanger <mibelanger@qnx.com> wrote:
 
There appears to be a race condition in ether_ifattach = (if_ethersubr.c).
The ether_ifattach() function = calls if_attach, where the interface will get announced, and then = ether_ifattach continues with the initialization of the ifp.
 
I also noticed this while working on https://reviews.freebsd.org/D49359. There's an attempt for the = attaching process https://reviews.freebsd.org/D49358 .
 
> then ether_ifattach continues with the initialization of the = ifp.
In most cases that should not = matter, as at that moment the interface has not been flagged up ( IFF_UP = ) yet.


Is there any guarantee in FreeBSD that this race condition = cannot be exposed.
We have been running the FreeBSD = stack for some time under QNX and have just recently run into an issue = with this race condition.
We are = considering a modification where we have the option of deferring the = interface announcement in if_attach.
 
Can you elaborate how the race condition happens and how that = affect you ?
 
Before opening a FreeBSD bug, I wanted to check if this issue = would not be valid in a FreeBSD system.
It=E2=80=99s very clear that there is a potential race when = looking at the code, but perhaps there is a mitigation that is not = obvious.
This transmission (including any attachments) may = contain confidential information, privileged material (including = material protected by the solicitor-client or other applicable = privileges), or constitute non-public information. Any use of this = information by anyone other than the intended recipient is prohibited. = If you have received this transmission in error, please immediately = reply to the sender and delete this information from your system. Use, = dissemination, distribution, or reproduction of this transmission by = unintended recipients is not authorized and may be unlawful.
 
Best regards,
Zhenlei
 
This email = and any attachments are intended solely for the use of the individual or = entity to whom they are addressed. This email may contain information = that is confidential, privileged, or otherwise protected from = disclosure. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this email in = error, please immediately contact the sender and delete all copies of = this email and any attachments from your systems. Any unauthorized = review, use, dissemination, distribution, or reproduction of this email = by unintended recipients is not authorized and may be unlawful. Thank = you for your cooperation.
Best regards,
Zhenlei

= --Apple-Mail=_8FAD9271-E47B-435B-9796-58C0C678104C--