CVE-2024-44952

See a problem?
Source
https://nvd.nist.gov/vuln/detail/CVE-2024-44952
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-44952.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-44952
Related
Published
2024-09-04T19:15:30Z
Modified
2024-10-07T19:49:45.342502Z
Severity
  • 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

driver core: Fix uevent_show() vs driver detach race

ueventshow() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct devicedriver).devgroups. Instead, the anti-pattern of taking the devicelock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock.

This deadlock is typically invisible to lockdep given the devicelock() is marked lockdepsetnovalidateclass(), but some subsystems allocate a local lockdep key for @dev->mutex to reveal reports of the form:

====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G OE N

modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: _kernfsremove+0xde/0x220

but task is already holding lock: ffff8c22016e88f8 (&cxlrootkey){+.+.}-{3:3}, at: devicereleasedriver_internal+0x39/0x210

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&cxlrootkey){+.+.}-{3:3}: _mutexlock+0x99/0xc30 ueventshow+0xac/0x130 devattrshow+0x18/0x40 sysfskfseqshow+0xac/0xf0 seqreaditer+0x110/0x450 vfsread+0x25b/0x340 ksysread+0x67/0xf0 dosyscall64+0x75/0x190 entrySYSCALL64afterhwframe+0x76/0x7e

-> #0 (kn->active#6){++++}-{0:0}: _lockacquire+0x121a/0x1fa0 lockacquire+0xd6/0x2e0 kernfsdrain+0x1e9/0x200 _kernfsremove+0xde/0x220 kernfsremovebynamens+0x5e/0xa0 devicedel+0x168/0x410 deviceunregister+0x13/0x60 devresreleaseall+0xb8/0x110 deviceunbindcleanup+0xe/0x70 devicereleasedriverinternal+0x1c7/0x210 driverdetach+0x47/0x90 busremovedriver+0x6c/0xf0 cxlacpiexit+0xc/0x11 [cxlacpi] _dosysdeletemodule.isra.0+0x181/0x260 dosyscall64+0x75/0x190 entrySYSCALL64after_hwframe+0x76/0x7e

The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronizercu() in moduleremovedriver() to close any potential races. It is potentially overkill to suffer synchronizercu() just to handle the rare module removal racing uevent_show() event.

Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1].

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.226-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
5.10.140-1
5.10.148-1
5.10.149-1
5.10.149-2
5.10.158-1
5.10.158-2
5.10.162-1
5.10.178-1
5.10.178-2
5.10.178-3
5.10.179-1
5.10.179-2
5.10.179-3
5.10.179-4
5.10.179-5
5.10.191-1
5.10.197-1
5.10.205-1
5.10.205-2
5.10.209-1
5.10.209-2
5.10.216-1
5.10.218-1
5.10.221-1
5.10.223-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.1.106-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-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.10.6-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3
6.1.112-1
6.3.1-1~exp1
6.3.2-1~exp1
6.3.4-1~exp1
6.3.5-1~exp1
6.3.7-1~bpo12+1
6.3.7-1
6.3.11-1
6.4~rc6-1~exp1
6.4~rc7-1~exp1
6.4.1-1~exp1
6.4.4-1~bpo12+1
6.4.4-1
6.4.4-2
6.4.4-3~bpo12+1
6.4.4-3
6.4.11-1
6.4.13-1
6.5~rc4-1~exp1
6.5~rc6-1~exp1
6.5~rc7-1~exp1
6.5.1-1~exp1
6.5.3-1~bpo12+1
6.5.3-1
6.5.6-1
6.5.8-1
6.5.10-1~bpo12+1
6.5.10-1
6.5.13-1
6.6.3-1~exp1
6.6.4-1~exp1
6.6.7-1~exp1
6.6.8-1
6.6.9-1
6.6.11-1
6.6.13-1~bpo12+1
6.6.13-1
6.6.15-1
6.6.15-2
6.7-1~exp1
6.7.1-1~exp1
6.7.4-1~exp1
6.7.7-1
6.7.9-1
6.7.9-2
6.7.12-1~bpo12+1
6.7.12-1
6.8.9-1
6.8.11-1
6.8.12-1~bpo12+1
6.8.12-1
6.9.2-1~exp1
6.9.7-1~bpo12+1
6.9.7-1
6.9.8-1
6.9.9-1
6.9.10-1~bpo12+1
6.9.10-1
6.9.11-1
6.9.12-1
6.10-1~exp1
6.10.1-1~exp1
6.10.3-1
6.10.4-1
6.10.6-1~bpo12+1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}