Hi Mike, > On May 1, 2025, at 9:13 PM, Mike Belanger <mibelan...@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’s 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
