Date: Thu, 1 May 2025 13:13:30 +0000 From: Mike Belanger <mibelanger@qnx.com> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Race condition in ether_ifattach Message-ID: <YQXPR01MB41989535A01FA09637C82906C2822@YQXPR01MB4198.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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. 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. 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. [-- Attachment #2 --] <html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">; <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Aptos; panose-1:2 11 0 4 2 2 2 2 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:12.0pt; font-family:"Aptos",sans-serif; mso-ligatures:standardcontextual;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style> </head> <body lang="EN-CA" link="#467886" vlink="#96607D" style="word-wrap:break-word"> <div class="WordSection1"> <p class="MsoNormal"><span style="font-size:11.0pt">There appears to be a race condition in ether_ifattach (if_ethersubr.c).<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">The ether_ifattach() function calls if_attach, where the interface will get announced, and then ether_ifattach continues with the initialization of the ifp.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">Is there any guarantee in FreeBSD that this race condition cannot be exposed.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">We have been running the FreeBSD stack for some time under QNX and have just recently run into an issue with this race condition.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">We are considering a modification where we have the option of deferring the interface announcement in if_attach.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">Before opening a FreeBSD bug, I wanted to check if this issue would not be valid in a FreeBSD system.<o:p></o:p></span></p> <p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p> </div> <HR>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.<BR> </body> </html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR01MB41989535A01FA09637C82906C2822>