From nobody Sun May 4 01:33:43 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 4ZqnHg3c3zz5v1dg for ; Sun, 04 May 2025 01:33:51 +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 4ZqnHg30Gpz3T9Y; Sun, 04 May 2025 01:33:51 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746322431; 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=tS7caFXP4yS08sg3GbNL7EwQn8UYBDE3Ty2rNnRkYro=; b=TqhtD3o95516ttRINXk1IZLPD9QQip57uwBa7OAGvgVtyWKUlgtljF+EJnVcE7sFKgIwE5 Y8UGoqjOLYYcQsPkvbIQKRW7phw8HpmDov+IoCCgawaI9TNIZabuAH0h35ip+tyFWRmkqz 7GwGYULCIWS7kLcFhx3Dd8SZ+WxHJ8wS7INV0DdePs7geLkKNjY+DDjZdym1YT98WcqMYo eG8BVEVnCX/FnZLOjT56HFWuZeJqMHNe4t1bdtfA/1Jov/fdZuaF3p0KwKbXVfPIqRRFzX tbElDFyBmhN1eUyWOaL2Q+n6A6e+utZad/1481f7mTjyrlpgtKAqXSUi0yHCsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746322431; 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=tS7caFXP4yS08sg3GbNL7EwQn8UYBDE3Ty2rNnRkYro=; b=hUuqkhVdStl40cjMY8txGBuq2bMqkLgqgUCvxYDS1vWBGzBNLE2j9itBWx1PbSOni5bxES ih8JjqgBwSMHolVH1iKMYk15nO9oFagZKhmRc0wrPo5bI3RHVUQpaI/JRwwHqcrBjNhPsU Rz1Rmfq+bIGw4FFjkEv+0LJwk2sUbFOcVxucZamHuP2LpUBPnEaO4cx7PVYNv6gZu4Yfm3 vaYS8zxB1sua4Iv2uLWNR04MafGFf1bBBY1IDwR02GyO6ak8/+99b7bd812y8lRqpZhppf xSebnmLPgOZk8RNEW+9hzZ3PR+GpEy+HJFoOZBZvDcguabEH6Gq/GjYqCjdiWA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746322431; a=rsa-sha256; cv=none; b=nRo+lOpU2SmR/FXRAioBTISop8h3lyhi1gAd8H0gwuA4vkzRxlPYhPC70w1Cgxv2369ARy /P0PVBZ52Q+O9gP1frjPl6mQLjWgpnNxROrgMnNPZNhiumabud1fmECh4ZW9Z/gM63Su6e 05aP52iTIRoYnnV0fefKbTcwmKIT0V5IsqeZAwmDQeO2IlIqtBbEREmzt5mFOXPt5zeWj9 jE32jvxu19obcngEQfzUdLwSfCf3jqvbeoKA8ERVoait/xbd3BULazp5Z38AcfBj3VWyw/ 2fEgssUHJpv26ItOhbPn7BaYuFg977lEoR+x7Ng/OUnfAD7zxNHSpqMDHRngyQ== 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 4ZqnHf1nC6zFLT; Sun, 04 May 2025 01:33:49 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <7FFF346E-3205-49A9-B95A-94A418A28220@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_90ECC2FF-4B9D-4DBA-B191-E34D665E842F" 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: Race condition in ether_ifattach Date: Sun, 4 May 2025 09:33:43 +0800 In-Reply-To: Cc: "freebsd-net@freebsd.org" , Gleb Smirnoff To: Mike Belanger References: X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_90ECC2FF-4B9D-4DBA-B191-E34D665E842F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, > 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. 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 --Apple-Mail=_90ECC2FF-4B9D-4DBA-B191-E34D665E842F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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

= --Apple-Mail=_90ECC2FF-4B9D-4DBA-B191-E34D665E842F--