In the Linux kernel, the following vulnerability has been resolved:
driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction
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't sufficient to
account for devices being deferred until deferred_probe_timeout.
Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits
until the deferred_probe_timeout fires") tried to fix that by making
sure wait_for_device_probe() waits for deferred_probe_timeout to expire
before returning.
However, if wait_for_device_probe() is called from the kernel_init()
context:
- Before deferred_probe_initcall() [2], it causes the boot process to
hang due to a deadlock.
- 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's trying to wait for userspace to load
modules.
Neither of this is good. So revert the changes to
wait_for_device_probe().
[1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/
[2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/
[3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel boot reliability issue. Under specific deferred device probing conditions, systems can hang during boot or wait unnecessarily, especially around network-dependent boot flows such as NFS root filesystems. The public sources do not show active exploitation or a remote attack path.
Executive priority
Treat this as a targeted availability risk, not an internet-scale emergency. Prioritize platforms where failed or delayed boot would affect service recovery, appliances, embedded systems, or network-booted Linux hosts.
Technical view
The issue is in driver core handling of wait_for_device_probe() and deferred_probe_timeout. A prior fix made wait_for_device_probe() wait for deferred_probe_timeout, but calls from kernel_init() could deadlock before deferred_probe_initcall() or stall boot after it. Stable kernel commits revert that interaction.
Likely exposure
Exposure appears limited to Linux systems running affected kernel versions where deferred_probe_timeout and boot-time device probing matter. Systems using NFS rootfs or depending on late-loaded modules during boot are most relevant.
Exploitation context
CISA KEV status is false in the bundle. The provided sources describe boot hangs and timeouts, not public exploitation, privilege escalation, remote code execution, or weaponized abuse.
Researcher notes
The evidence points to a regression-style kernel availability bug in boot sequencing. No CVSS, CWE, exploit narrative, or vendor-specific package matrix is provided, so affected distribution status must be validated from vendor advisories.
Mitigation direction
Check vendor kernel advisories for affected distributions and supported fixed builds.
Prioritize updates for systems using NFS rootfs or deferred_probe_timeout.
Apply kernel versions containing the listed stable fixes when available.
Avoid changing boot probe settings without vendor guidance and regression testing.
Validation and detection
Inventory Linux kernel versions across production and boot-critical systems.
Identify systems using NFS rootfs, deferred_probe_timeout, or late module loading.
Confirm whether vendor kernels include one of the referenced stable commits.
Test patched kernels through full reboot and network initialization paths.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-49379 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Feb 26, 2025, 02:11 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.