CVE-2022-50472 in Linux
Summary
by MITRE • 10/04/2025
In the Linux kernel, the following vulnerability has been resolved:
IB/mad: Don't call to function that might sleep while in atomic context
Tracepoints are not allowed to sleep, as such the following splat is generated due to call to ib_query_pkey() in atomic context.
WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220 CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
RIP: 0010:rb_commit+0xc1/0x220 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0 Call Trace: ring_buffer_unlock_commit+0x1d/0xa0 trace_buffer_unlock_commit_regs+0x3b/0x1b0 trace_event_buffer_commit+0x67/0x1d0 trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core]
ib_mad_recv_done+0x48b/0xc10 [ib_core]
? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core]
__ib_process_cq+0x91/0x1c0 [ib_core]
ib_cq_poll_work+0x26/0x80 [ib_core]
process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 78ba8509d3830a16 ]---
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 03/16/2026
The vulnerability identified as CVE-2022-50472 represents a critical flaw in the Linux kernel's InfiniBand messaging subsystem where a function that may sleep is being invoked within an atomic context. This issue specifically affects the IB/mad component of the kernel's InfiniBand core module, creating a scenario where kernel threads attempting to process InfiniBand messages can trigger kernel oops and system instability. The problem manifests when the ib_query_pkey() function is called from within a tracepoint handler that operates in atomic context, violating fundamental kernel design principles where atomic contexts must not perform operations that could block or sleep.
The technical root cause stems from improper context handling within the kernel's tracepoint infrastructure. Tracepoints are designed to be lightweight and must never sleep or block execution as they operate in atomic contexts where such behavior would lead to system deadlocks or corruption. The call trace shows the execution flow beginning in the kworker thread context, specifically within the ib_cq_poll_work workqueue handler, where the ib_mad_recv_done function attempts to invoke ib_query_pkey() while the trace_event_raw_event_ib_mad_recv_done_handler is executing in atomic context. This violates the kernel's atomic context constraints and results in the kernel's ring buffer committing operation failing with a warning indicating the sleeping function call within atomic context.
This vulnerability directly maps to CWE-367, which defines the weakness of Time-of-Check to Time-of-Use (TOCTOU) race conditions, and more specifically to CWE-126, which addresses buffer over-read conditions that can occur when improper atomic context handling leads to memory corruption. The operational impact of this vulnerability is severe as it can cause kernel panics, system crashes, and denial of service conditions affecting any system running the affected Linux kernel versions with InfiniBand capabilities. Systems utilizing InfiniBand networking for high-performance computing, data center interconnects, or storage area networks are particularly at risk since these environments rely heavily on the problematic IB/mad functionality.
The ATT&CK framework categorizes this vulnerability under T1489, which involves system network configuration modification, as the instability could potentially be exploited to disrupt network communications. Additionally, this vulnerability could be leveraged as a privilege escalation vector or denial of service mechanism in environments where InfiniBand is used for critical infrastructure. Organizations should immediately apply the kernel patches provided by Red Hat and other vendors, as the fix involves modifying the tracepoint handlers to avoid calling sleepable functions from atomic contexts. The mitigation strategy requires careful code review of all tracepoint implementations and ensuring that any function calls within atomic contexts are strictly limited to non-blocking operations only. System administrators should also monitor for kernel oops messages and ensure proper kernel version updates are deployed across all systems running affected kernel versions to prevent exploitation and maintain system stability.