CVE-2022-49379

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: Fix wait_for_device_probe() &amp; deferred_probe_timeout interaction<br /> <br /> Mounting NFS rootfs was timing out when deferred_probe_timeout was<br /> non-zero [1]. This was because ip_auto_config() initcall times out<br /> waiting for the network interfaces to show up when<br /> deferred_probe_timeout was non-zero. While ip_auto_config() calls<br /> wait_for_device_probe() to make sure any currently running deferred<br /> probe work or asynchronous probe finishes, that wasn&amp;#39;t sufficient to<br /> account for devices being deferred until deferred_probe_timeout.<br /> <br /> Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits<br /> until the deferred_probe_timeout fires") tried to fix that by making<br /> sure wait_for_device_probe() waits for deferred_probe_timeout to expire<br /> before returning.<br /> <br /> However, if wait_for_device_probe() is called from the kernel_init()<br /> context:<br /> <br /> - Before deferred_probe_initcall() [2], it causes the boot process to<br /> hang due to a deadlock.<br /> <br /> - After deferred_probe_initcall() [3], it blocks kernel_init() from<br /> continuing till deferred_probe_timeout expires and beats the point of<br /> deferred_probe_timeout that&amp;#39;s trying to wait for userspace to load<br /> modules.<br /> <br /> Neither of this is good. So revert the changes to<br /> wait_for_device_probe().<br /> <br /> [1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/<br /> [2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/<br /> [3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/