CVE-2021-46939: tracing: Restructure trace_clock_global() to never block
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 ? dpmruncallback+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) ringbufferlockreserve() { traceclockglobal() { archspinlock() { queuedspinlockslowpath() { / 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/showbug.cgi?id=212761
Other sources
In the Linux kernel, the following vulnerability has been resolved:
tracing: Restructure traceclockglobal() to never block
The Linux kernel CVE team has assigned CVE-2021-46939 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/20240227184057.2368370-4-gregkh@linuxfoundation.org/T/#u
— Red Hat
Linux Kernel is vulnerable to a denial of service, caused by a flaw in the ring buffer recursion detection. By sending a specially crafted request, a local authenticated attacker could exploit this vulnerability to cause a denial of service condition.
— IBM
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2021-46939?
CVE-2021-46939 is classified as a high-severity vulnerability due to its potential to cause system hangs during suspend and resume operations.
How do I fix CVE-2021-46939?
To fix CVE-2021-46939, upgrade to one of the patched Linux kernel versions such as 5.10.223-1, 5.10.226-1, or later.
Which versions of the Linux kernel are affected by CVE-2021-46939?
CVE-2021-46939 affects various Linux kernel versions between 2.6.30 to 5.12.3.
What types of systems are impacted by CVE-2021-46939?
CVE-2021-46939 impacts systems running affected versions of the Linux kernel, particularly those using ring buffer recursion detection.
Is there a specific package I need to install to resolve CVE-2021-46939?
You should install the specific Linux packages such as 'linux' version 5.10.223-1 or later to address CVE-2021-46939.