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…and this can result in a crash if ether_ifattach is not complete (ifp->if_output is NULL). 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: [email protected] <[email protected]> on behalf of Zhenlei Huang <[email protected]> Date: Saturday, May 3, 2025 at 9:34 PM To: Mike Belanger <[email protected]> Cc: [email protected] <[email protected]>, Gleb Smirnoff <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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<https://urldefense.com/v3/__https:/reviews.freebsd.org/D49359__;!!JoeW-IhCUkS0Jg!Z0amzfdzApROIkoPw2gfHT4AlRbNoJhjhYrxU6fH_KH9W8eXaWsowj9sKZ0EvnqPG0to66NlKZ3FMtaxAA$>. There's an attempt for the attaching process https://reviews.freebsd.org/D49358<https://urldefense.com/v3/__https:/reviews.freebsd.org/D49358__;!!JoeW-IhCUkS0Jg!Z0amzfdzApROIkoPw2gfHT4AlRbNoJhjhYrxU6fH_KH9W8eXaWsowj9sKZ0EvnqPG0to66NlKZ30mbVejw$> . > 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 ---------------------------------------------------------------------- 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.
