fkie_cve-2022-49379
Vulnerability from fkie_nvd
Published
2025-02-26 07:01
Modified
2025-02-26 07:01
Severity ?
Summary
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/
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/29357883a89193863f3cc6a2c5e0b42ceb022761
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/4ad6af07efcca85369c21e4897b3020cff2c170b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/528229474e1cbb1b3451cb713d94aecb5f6ee264
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5ee76c256e928455212ab759c51d198fedbe7523
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/71cbce75031aed26c72c2dc8a83111d181685f1b
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: Fix wait_for_device_probe() \u0026 deferred_probe_timeout interaction\n\nMounting NFS rootfs was timing out when deferred_probe_timeout was\nnon-zero [1].  This was because ip_auto_config() initcall times out\nwaiting for the network interfaces to show up when\ndeferred_probe_timeout was non-zero. While ip_auto_config() calls\nwait_for_device_probe() to make sure any currently running deferred\nprobe work or asynchronous probe finishes, that wasn\u0027t sufficient to\naccount for devices being deferred until deferred_probe_timeout.\n\nCommit 35a672363ab3 (\"driver core: Ensure wait_for_device_probe() waits\nuntil the deferred_probe_timeout fires\") tried to fix that by making\nsure wait_for_device_probe() waits for deferred_probe_timeout to expire\nbefore returning.\n\nHowever, if wait_for_device_probe() is called from the kernel_init()\ncontext:\n\n- Before deferred_probe_initcall() [2], it causes the boot process to\n  hang due to a deadlock.\n\n- After deferred_probe_initcall() [3], it blocks kernel_init() from\n  continuing till deferred_probe_timeout expires and beats the point of\n  deferred_probe_timeout that\u0027s trying to wait for userspace to load\n  modules.\n\nNeither of this is good. So revert the changes to\nwait_for_device_probe().\n\n[1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/\n[2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/\n[3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: n\u00facleo del controlador: se corrige la interacci\u00f3n wait_for_device_probe() y deferred_probe_timeout El montaje de rootfs NFS se agotaba cuando deferred_probe_timeout no era cero [1]. Esto se deb\u00eda a que la llamada de inicio ip_auto_config() agotaba el tiempo de espera a que aparecieran las interfaces de red cuando deferred_probe_timeout no era cero. Si bien ip_auto_config() llama a wait_for_device_probe() para asegurarse de que cualquier sonda diferida que se est\u00e9 ejecutando actualmente funcione o la sonda asincr\u00f3nica finalice, eso no era suficiente para explicar los dispositivos que se aplazaban hasta deferred_probe_timeout. El commit 35a672363ab3 (\"driver core: Ensure wait_for_device_probe() waits Until the deferred_probe_timeout fires\") intent\u00f3 solucionar eso asegur\u00e1ndose de que wait_for_device_probe() espere a que deferred_probe_timeout expire antes de regresar. Sin embargo, si wait_for_device_probe() se llama desde el contexto kernel_init(): - Antes de deferred_probe_initcall() [2], hace que el proceso de arranque se cuelgue debido a un punto muerto. - Despu\u00e9s de deferred_probe_initcall() [3], impide que kernel_init() contin\u00fae hasta que deferred_probe_timeout expire y supere el punto de deferred_probe_timeout que est\u00e1 tratando de esperar a que el espacio de usuario cargue m\u00f3dulos. Ninguna de estas opciones es buena. Por lo tanto, revierta los cambios a 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/"
    }
  ],
  "id": "CVE-2022-49379",
  "lastModified": "2025-02-26T07:01:14.543",
  "metrics": {},
  "published": "2025-02-26T07:01:14.543",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/29357883a89193863f3cc6a2c5e0b42ceb022761"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/4ad6af07efcca85369c21e4897b3020cff2c170b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/528229474e1cbb1b3451cb713d94aecb5f6ee264"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5ee76c256e928455212ab759c51d198fedbe7523"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/71cbce75031aed26c72c2dc8a83111d181685f1b"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.