DEBIAN-CVE-2022-50220

See a problem?
Please try reporting it to the source first.
Source
https://security-tracker.debian.org/tracker/CVE-2022-50220
Import Source
https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2022-50220.json
JSON Data
https://api.osv.dev/v1/vulns/DEBIAN-CVE-2022-50220
Upstream
Published
2025-06-18T11:15:52Z
Modified
2025-09-25T03:23:17.371757Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix linkwatch use-after-free on disconnect usbnet uses the work usbnetdeferredkevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndostop(). 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 flushscheduledwork(), and that could deadlock when waiting for usbnetdeferredkevent() with rtnlmutex held in ->ndostop(). The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asixdevices.c, ax88179178a.c, ch9200.c and smsc75xx.c: * If the drivers receive a link change interrupt immediately before disconnect, they raise EVENTLINKRESET in their (non-sleepable) ->status() callback and schedule usbnetdeferredkevent(). * usbnetdeferredkevent() invokes the driver's ->linkreset() callback, which calls netifcarrier{on,off}(). * That in turn schedules the work linkwatchevent(). Because usbnetdeferredkevent() is awaited after unregisternetdev(), netifcarrier{on,off}() may operate on an unregistered netdev and linkwatchevent() may run after freenetdev(), causing a use-after-free. In 2010, usbnet was changed to only wait for a single instance of usbnetdeferredkevent() instead of all work by commit 23f333a2bfaf ("drivers/net: don't use flushscheduledwork()"). Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last.

References

Affected packages

Debian:11 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.10.140-1

Affected versions

5.*

5.10.46-4
5.10.46-5
5.10.70-1~bpo10+1
5.10.70-1
5.10.84-1
5.10.92-1~bpo10+1
5.10.92-1
5.10.92-2
5.10.103-1~bpo10+1
5.10.103-1
5.10.106-1
5.10.113-1
5.10.120-1~bpo10+1
5.10.120-1
5.10.127-1
5.10.127-2~bpo10+1
5.10.127-2
5.10.136-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:12 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.0.2-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.0.2-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:14 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.0.2-1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}