CVE-2021-46939

See a problem?
Source
https://nvd.nist.gov/vuln/detail/CVE-2021-46939
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2021-46939.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2021-46939
Related
Published
2024-02-27T19:04:05Z
Modified
2024-09-11T02:00:05Z
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:

tracing: Restructure traceclockglobal() to never block

It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case:

Call Trace: traceclockglobal+0x91/0xa0 _rbreservenext+0x237/0x460 ringbufferlockreserve+0x12a/0x3f0 tracebufferlockreserve+0x10/0x50 _tracegraphreturn+0x1f/0x80 tracegraphreturn+0xb7/0xf0 ? traceclockglobal+0x91/0xa0 ftracereturntohandler+0x8b/0xf0 ? pvhash+0xa0/0xa0 returntohandler+0x15/0x30 ? ftracegraphcaller+0xa0/0xa0 ? traceclockglobal+0x91/0xa0 ? _rbreservenext+0x237/0x460 ? ringbufferlockreserve+0x12a/0x3f0 ? traceeventbufferlockreserve+0x3c/0x120 ? traceeventbufferreserve+0x6b/0xc0 ? traceeventraweventdevicepmcallbackstart+0x125/0x2d0 ? dpmruncallback+0x3b/0xc0 ? pmopsisempty+0x50/0x50 ? platformgetirqbynameoptional+0x90/0x90 ? tracedevicepmcallbackstart+0x82/0xd0 ? dpmrun_callback+0x49/0xc0

With the following RIP:

RIP: 0010:nativequeuedspinlockslowpath+0x69/0x200

Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the traceclockglobal() taking a spin lock and then trying to take it again:

ringbufferlockreserve() { traceclockglobal() { archspinlock() { queuedspinlockslowpath() { /* lock taken / (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { / DEAD LOCK! */

Tracing should never block, as it can lead to strange lockups like the above.

Restructure the traceclockglobal() code to instead of simply taking a lock to update the recorded "prevtime" simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prevtime, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

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.38-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
5.10.38-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
5.10.38-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}