CVE-2022-49889

ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters()

MEDIUM
5.5
CVSS Score
Published: May 1, 2025 at 02:10 PM UTC
Updated: June 17, 2026 at 05:19 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters() On some machines the number of listed CPUs may be bigger than the actual CPUs that exist. The tracing subsystem allocates a per_cpu directory with access to the per CPU ring buffer via a cpuX file. But to save space, the ring buffer will only allocate buffers for online CPUs, even though the CPU array will be as big as the nr_cpu_ids. With the addition of waking waiters on the ring buffer when closing the file, the ring_buffer_wake_waiters() now needs to make sure that the buffer is allocated (with the irq_work allocated with it) before trying to wake waiters, as it will cause a NULL pointer dereference. While debugging this, I added a NULL check for the buffer itself (which is OK to do), and also NULL pointer checks against buffer->buffers (which is not fine, and will WARN) as well as making sure the CPU number passed in is within the nr_cpu_ids (which is also not fine if it isn't). Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v ≥ 5.19.175.15.75 ≤ v < 5.15.785.19.17 ≤ v < 5.205.19.17 ≤ v < 6.06.0.3 ≤ v < 6.0.82475de2bc0de17fb1b24c5e90194f84b5ca70d3e5.15.755.19.175544f411a4e8bc39e6a444badbac37dd0e0caf0a6.0.3f3ddb74ad0790030c9592229fb14d8c451f4e9a8f4f15344110d0b5b8822ac97bc8200e71939c945
Vendor states this is fixed in 49ca992f6e50d0f46ec9608f44e011cf3121f389 (fixed)
Vendor states this is fixed in 7433632c9ff68a991bd0bc38cabf354e9d2de410 (fixed)
Vendor states this is fixed in b5074df412bf3df9d6ce096b6fa03eb1082d05c9 (fixed)
Affected range stops below 5.15.78, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.20, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.0, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.0.8, so it looks safe — our inference, not a vendor statement

References (3)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/49ca992f6e50d0f46ec9608f44e011cf3121f389
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/7433632c9ff68a991bd0bc38cabf354e9d2de410
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/b5074df412bf3df9d6ce096b6fa03eb1082d05c9

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

5.5MEDIUMCISA-ADP
Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-476

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card