Skip to content
Fencer Vulns
high 7.8

CVE-2022-50220 json

usbnet: Fix linkwatch use-after-free on disconnect

published 2025-06-18 16 mo ago modified 2026-11-05 3 d ago also EUVD-2022-55202

cvss
7.8
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 15%
public exploits
0
none known

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.

Patch / fix

  • Linux Linux 4.9.326, 4.14.291, 4.19.256, 5.4.211, 5.10.137, 5.15.61, 5.18.18, 5.19.2, 6.0
  • linux Debian 14, Debian 13, Debian 12 6.0.2-1

debian advisories DEBIAN-CVE-2022-50220

  • linux Ubuntu 18.04 LTS 4.15.0-197.208
  • linux Ubuntu 20.04 LTS 5.4.0-132.148
  • linux Ubuntu 22.04 LTS 5.15.0-53.59
  • linux-aws Ubuntu 18.04 LTS 4.15.0-1143.155
  • linux-aws Ubuntu 20.04 LTS 5.4.0-1089.97
  • linux-aws Ubuntu 22.04 LTS 5.15.0-1023.27
  • linux-gcp Ubuntu 20.04 LTS 5.4.0-1093.102
  • linux-gcp Ubuntu 22.04 LTS 5.15.0-1022.29

ubuntu advisories UBUNTU-CVE-2022-50220

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel-64kb SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS, SLE High Performance Computing 15 SP4-ESPOS 5.14.21-150400.24.170.2
  • kernel-syms SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS +3 more 5.14.21-150400.24.170.1
  • kernel-source SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS +3 more 5.14.21-150400.24.170.1
  • kernel-default SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE Micro 5.4 +6 more 5.14.21-150400.24.170.2
  • kernel-zfcpdump SLES 15 SP4-LTSS, Manager Server 4.3 5.14.21-150400.24.170.2
  • kernel-obs-build SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE High Performance Computing 15 SP4-LTSS +1 more 5.14.21-150400.24.170.2
  • kernel-default-base SLES for SAP 15 SP4, SLES 15 SP4-LTSS, SLE Micro 5.4 +5 more 5.14.21-150400.24.170.2.150400.24.86.2
  • kernel-rt SLE Micro 5.4, SLE Micro 5.3 5.14.21-150400.15.124.1

suse advisories SUSE-SU-2025:02537-1SUSE-SU-2025:02334-1SUSE-SU-2025:02322-1SUSE-SU-2025:02321-1SUSE-SU-2025:02320-1SUSE-SU-2025:02308-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2022-50220 updated cvss 4.2

kernel: usbnet: Fix linkwatch use-after-free on disconnect

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more
    affected: no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more
    affected: no fix available “Fix deferred”
  • Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    affected: no fix available
  • Red Hat Enterprise Linux 10 kernel
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
3 d ago

Exploit prediction

0.25% chance of exploitation in the next 30 days, higher than 15% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Affected products

  • Linux Linux

Classification

Weakness
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.