https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 17:03:52 +0000 https://vulnerability.circl.lu/vuln/cve-2022-49379 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>driver core: Fix wait_for_device_probe() &amp; deferred_probe_timeout interaction</p> <p>Mounting NFS rootfs was timing out when deferred_probe_timeout was non-zero [1]. This was because ip_auto_config() initcall times out waiting for the network interfaces to show up when deferred_probe_timeout was non-zero. While ip_auto_config() calls wait_for_device_probe() to make sure any currently running deferred probe work or asynchronous probe finishes, that wasn&#39;t sufficient to account for devices being deferred until deferred_probe_timeout.</p> <p>Commit 35a672363ab3 (&#34;driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires&#34;) tried to fix that by making sure wait_for_device_probe() waits for deferred_probe_timeout to expire before returning.</p> <p>However, if wait_for_device_probe() is called from the kernel_init() context:</p> <p>- Before deferred_probe_initcall() [2], it causes the boot process to hang due to a deadlock.</p> <p>- After deferred_probe_initcall() [3], it blocks kernel_init() from continuing till deferred_probe_timeout expires and beats the point of deferred_probe_timeout that&#39;s trying to wait for userspace to load modules.</p> <p>Neither of this is good. So revert the changes to wait_for_device_probe().</p> <p>[1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/ [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/ […</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>driver core: Fix wait_for_device_probe() &amp; deferred_probe_timeout interaction</p> <p>Mounting NFS rootfs was timing out when deferred_probe_timeout was non-zero [1]. This was because ip_auto_config() initcall times out waiting for the network interfaces to show up when deferred_probe_timeout was non-zero. While ip_auto_config() calls wait_for_device_probe() to make sure any currently running deferred probe work or asynchronous probe finishes, that wasn&#39;t sufficient to account for devices being deferred until deferred_probe_timeout.</p> <p>Commit 35a672363ab3 (&#34;driver core: Ensure wait_for_device_probe() waits until the deferred_probe_timeout fires&#34;) tried to fix that by making sure wait_for_device_probe() waits for deferred_probe_timeout to expire before returning.</p> <p>However, if wait_for_device_probe() is called from the kernel_init() context:</p> <p>- Before deferred_probe_initcall() [2], it causes the boot process to hang due to a deadlock.</p> <p>- After deferred_probe_initcall() [3], it blocks kernel_init() from continuing till deferred_probe_timeout expires and beats the point of deferred_probe_timeout that&#39;s trying to wait for userspace to load modules.</p> <p>Neither of this is good. So revert the changes to wait_for_device_probe().</p> <p>[1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/ [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/ […</p> https://vulnerability.circl.lu/vuln/cve-2022-49379