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.
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"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

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…