CVE-2022-48937 in Linux
Summary
by MITRE • 08/22/2024
In the Linux kernel, the following vulnerability has been resolved:
io_uring: add a schedule point in io_add_buffers()
Looping ~65535 times doing kmalloc() calls can trigger soft lockups, especially with DEBUG features (like KASAN).
[ 253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575]
[ 253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O)
[ 253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S O 5.17.0-smp-DEV #801
[ 253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98)
[ 253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40
[ 253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246
[ 253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001
[ 253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a
[ 253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004
[ 253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380
[ 253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0
[ 253.544483] FS: 00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000
[ 253.544486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0
[ 253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 253.544494] Call Trace:
[ 253.544496]
[ 253.544498] ? io_queue_sqe (fs/io_uring.c:7143)
[ 253.544505] __kernel_text_address (kernel/extable.c:78)
[ 253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19)
[ 253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27)
[ 253.544517] ? io_queue_sqe (fs/io_uring.c:7143)
[ 253.544521] stack_trace_save (kernel/stacktrace.c:123)
[ 253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)
[ 253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)
[ 253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524)
[ 253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)
[ 253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
[ 253.544544] ? __io_queue_sqe (fs/io_uring.c:?)
[ 253.544551] __kasan_kmalloc (mm/kasan/common.c:524)
[ 253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)
[ 253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
[ 253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)
[ 253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
[ 253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
[ 253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546)
[ 253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078)
[ 253.544578] ? io_submit_sqes (fs/io_uring.c:7441)
[ 253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096)
[ 253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096)
[ 253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
[ 253.544590] ? entry_SYSCALL_64_after_hwframe (??:?)
[ 253.544596] __io_queue_sqe (fs/io_uring.c:?)
[ 253.544600] io_queue_sqe (fs/io_uring.c:7143)
[ 253.544603] io_submit_sqe (fs/io_uring.c:?)
[ 253.544608] io_submit_sqes (fs/io_uring.c:?)
[ 253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri
---truncated---
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/25/2024
The vulnerability described in CVE-2022-48937 resides within the Linux kernel's io_uring subsystem, specifically in the io_add_buffers() function. This flaw manifests as a potential soft lockup condition that can occur when the system performs approximately 65535 consecutive kmalloc() operations. The issue is particularly pronounced when debugging features such as Kernel Address Sanitizer (KASAN) are enabled, which can exacerbate memory allocation overhead and lead to system unresponsiveness. The reported soft lockup indicates that a CPU core becomes stuck for an extended period, in this case 26 seconds, preventing the system from processing further tasks. This behavior stems from the absence of a scheduling point during the buffer addition process, which prevents the kernel scheduler from yielding control to other processes or threads during intensive memory allocation cycles. The call trace reveals that the system becomes blocked during kernel memory allocation functions, particularly within kmem_cache_alloc_trace and related KASAN instrumentation code paths, leading to a state where the system cannot proceed with normal operations.
The technical root cause of this vulnerability is the lack of periodic scheduling points within the io_add_buffers() function, which is part of the io_uring asynchronous I/O implementation. When the function processes a large number of buffer additions, it continuously allocates memory without yielding execution to the kernel scheduler. This behavior violates fundamental kernel design principles that require periodic rescheduling to prevent indefinite blocking of system resources. The vulnerability is classified under CWE-664, which deals with improper control of a resource through time-varying parameters, and more specifically aligns with CWE-704, indicating improper execution of a resource management function. The io_uring subsystem, designed for high-performance asynchronous I/O operations, should maintain responsiveness even under heavy load conditions, but this flaw compromises that responsiveness by creating a scenario where the kernel cannot schedule other tasks during memory allocation bursts.
The operational impact of this vulnerability can be severe, particularly in high-performance computing environments, storage systems, or applications that heavily utilize io_uring for asynchronous operations. A system experiencing this soft lockup will become unresponsive, potentially leading to service outages, data loss, or system crashes. The vulnerability affects systems running Linux kernel versions prior to the fix, with the specific issue manifesting when applications make extensive use of io_uring's buffer management features. Attackers could potentially exploit this weakness by crafting malicious workloads that trigger the memory allocation loop, leading to denial-of-service conditions. The vulnerability is particularly concerning in containerized environments or virtualized systems where multiple processes might simultaneously engage io_uring operations, amplifying the risk of system-wide lockups. Additionally, the presence of debugging features like KASAN can make this vulnerability more likely to be triggered, as these features add additional overhead to memory allocation operations that can push systems over their scheduling thresholds.
Mitigation strategies for this vulnerability involve applying the kernel patch that introduces a schedule point within the io_add_buffers() function, allowing the kernel scheduler to yield control during intensive memory allocation operations. System administrators should prioritize updating to kernel versions that include this fix, particularly in production environments where system stability is critical. Monitoring systems should be configured to detect soft lockup conditions and alert administrators when such events occur, as they can serve as early indicators of this vulnerability. Additionally, applications utilizing io_uring should be reviewed to ensure they do not perform excessive buffer additions in tight loops, as this can contribute to triggering the vulnerability. The fix aligns with ATT&CK technique T1499.004, which involves system network configuration modification, by ensuring that kernel resource management does not lead to system unresponsiveness. Organizations should also consider implementing proper resource limits and monitoring for io_uring operations to prevent exploitation through resource exhaustion attacks. The vulnerability demonstrates the importance of kernel-level scheduling considerations in high-performance subsystems and highlights the need for careful design of memory allocation loops that could potentially block system responsiveness.