fkie_cve-2022-50220
Vulnerability from fkie_nvd
Published
2025-06-18 11:15
Modified
2025-06-18 13:47
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
usbnet: Fix linkwatch use-after-free on disconnect
usbnet uses the work usbnet_deferred_kevent() to perform tasks which may
sleep. On disconnect, completion of the work was originally awaited in
->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic
commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock":
https://git.kernel.org/tglx/history/c/0f138bbfd83c
The change was made because back then, the kernel's workqueue
implementation did not allow waiting for a single work. One had to wait
for completion of *all* work by calling flush_scheduled_work(), and that
could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex
held in ->ndo_stop().
The commit solved one problem but created another: It causes a
use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c,
ax88179_178a.c, ch9200.c and smsc75xx.c:
* If the drivers receive a link change interrupt immediately before
disconnect, they raise EVENT_LINK_RESET in their (non-sleepable)
->status() callback and schedule usbnet_deferred_kevent().
* usbnet_deferred_kevent() invokes the driver's ->link_reset() callback,
which calls netif_carrier_{on,off}().
* That in turn schedules the work linkwatch_event().
Because usbnet_deferred_kevent() is awaited after unregister_netdev(),
netif_carrier_{on,off}() may operate on an unregistered netdev and
linkwatch_event() may run after free_netdev(), causing a use-after-free.
In 2010, usbnet was changed to only wait for a single instance of
usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf
("drivers/net: don't use flush_scheduled_work()").
Unfortunately the commit neglected to move the wait back to
->ndo_stop(). Rectify that omission at long last.
References
Impacted products
Vendor | Product | Version |
---|
{ "cveTags": [], "descriptions": [ { "lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: Fix linkwatch use-after-free on disconnect\n\nusbnet uses the work usbnet_deferred_kevent() to perform tasks which may\nsleep. On disconnect, completion of the work was originally awaited in\n-\u003endo_stop(). But in 2003, that was moved to -\u003edisconnect() by historic\ncommit \"[PATCH] USB: usbnet, prevent exotic rtnl deadlock\":\n\n https://git.kernel.org/tglx/history/c/0f138bbfd83c\n\nThe change was made because back then, the kernel\u0027s workqueue\nimplementation did not allow waiting for a single work. One had to wait\nfor completion of *all* work by calling flush_scheduled_work(), and that\ncould deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex\nheld in -\u003endo_stop().\n\nThe commit solved one problem but created another: It causes a\nuse-after-free in USB Ethernet drivers aqc111.c, asix_devices.c,\nax88179_178a.c, ch9200.c and smsc75xx.c:\n\n* If the drivers receive a link change interrupt immediately before\n disconnect, they raise EVENT_LINK_RESET in their (non-sleepable)\n -\u003estatus() callback and schedule usbnet_deferred_kevent().\n* usbnet_deferred_kevent() invokes the driver\u0027s -\u003elink_reset() callback,\n which calls netif_carrier_{on,off}().\n* That in turn schedules the work linkwatch_event().\n\nBecause usbnet_deferred_kevent() is awaited after unregister_netdev(),\nnetif_carrier_{on,off}() may operate on an unregistered netdev and\nlinkwatch_event() may run after free_netdev(), causing a use-after-free.\n\nIn 2010, usbnet was changed to only wait for a single instance of\nusbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf\n(\"drivers/net: don\u0027t use flush_scheduled_work()\").\n\nUnfortunately the commit neglected to move the wait back to\n-\u003endo_stop(). Rectify that omission at long last." }, { "lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: Se corrige el Use-After-Free de linkwatch al desconectar. usbnet usa la funci\u00f3n usbnet_deferred_kevent() para ejecutar tareas que podr\u00edan estar en estado de suspensi\u00f3n. Al desconectar, la finalizaci\u00f3n de la tarea se esperaba originalmente en -\u0026gt;ndo_stop(). Sin embargo, en 2003, esto se traslad\u00f3 a -\u0026gt;disconnect() mediante el commit hist\u00f3rica \"[PATCH] USB: usbnet, previene el bloqueo rtnl ex\u00f3tico\": https://git.kernel.org/tglx/history/c/0f138bbfd83c. Este cambio se realiz\u00f3 porque, en aquel entonces, la implementaci\u00f3n de la cola de trabajo del kernel no permit\u00eda esperar una sola tarea. Se deb\u00eda esperar la finalizaci\u00f3n de *todas* las tareas llamando a flush_scheduled_work(), lo que pod\u00eda provocar un bloqueo al esperar usbnet_deferred_kevent() con rtnl_mutex en -\u0026gt;ndo_stop(). El commit resolvi\u00f3 un problema pero cre\u00f3 otro: Provoca un uso despu\u00e9s de la liberaci\u00f3n en los controladores Ethernet USB aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c y smsc75xx.c: * Si los controladores reciben una interrupci\u00f3n de cambio de enlace inmediatamente antes de la desconexi\u00f3n, generan EVENT_LINK_RESET en su devoluci\u00f3n de llamada -\u0026gt;status() (no inactiva) y programan usbnet_deferred_kevent(). * usbnet_deferred_kevent() invoca la devoluci\u00f3n de llamada -\u0026gt;link_reset() del controlador, que llama a netif_carrier_{on,off}(). * Eso a su vez programa el trabajo linkwatch_event(). Dado que usbnet_deferred_kevent() se espera despu\u00e9s de unregister_netdev(), netif_carrier_{on,off}() puede operar en un netdev no registrado y linkwatch_event() puede ejecutarse despu\u00e9s de free_netdev(), lo que provoca un error de uso despu\u00e9s de la liberaci\u00f3n. En 2010, se modific\u00f3 la configuraci\u00f3n de usbnet para que solo esperara una instancia de usbnet_deferred_kevent() en lugar de *todo* el trabajo mediante el commit 23f333a2bfaf (\"drivers/net: no usar flush_scheduled_work()\"). Lamentablemente, el commit no retras\u00f3 la espera a -\u0026gt;ndo_stop(). Se corrigi\u00f3 esta omisi\u00f3n de una vez." } ], "id": "CVE-2022-50220", "lastModified": "2025-06-18T13:47:40.833", "metrics": {}, "published": "2025-06-18T11:15:52.973", "references": [ { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/135199a2edd459d2b123144efcd7f9bcd95128e4" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/635fd8953e4309b54ca6a81bed1d4a87668694f4" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/7f77dcbc030c2faa6d8e8a594985eeb34018409e" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/8b4588b8b00b299be16a35be67b331d8fdba03f3" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/a69e617e533edddf3fa3123149900f36e0a6dc74" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/d2d6b530d89b0a912148018027386aa049f0a309" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/d49bb8cf9bfaa06aa527eb30f1a52a071da2e32f" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/db3b738ae5f726204876f4303c49cfdf4311403f" }, { "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/e2a521a7dcc463c5017b4426ca0804e151faeff7" } ], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis" }
Loading…
Loading…
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.
Loading…
Loading…