CVE-2022-48847 in Linux
Summary
by MITRE • 07/16/2024
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Fix filter limit check
In watch_queue_set_filter(), there are a couple of places where we check that the filter type value does not exceed what the type_filter bitmap can hold. One place calculates the number of bits by:
if (tf[i].type >= sizeof(wfilter->type_filter) * 8)
which is fine, but the second does:
if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)
which is not. This can lead to a couple of out-of-bounds writes due to a too-large type:
(1) __set_bit() on wfilter->type_filter (2) Writing more elements in wfilter->filters[] than we allocated.
Fix this by just using the proper WATCH_TYPE__NR instead, which is the number of types we actually know about.
The bug may cause an oops looking something like:
BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740 Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611 ... Call Trace: dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 ... kasan_report.cold+0x7f/0x11b ... watch_queue_set_filter+0x659/0x740 ... __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae
Allocated by task 611: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 watch_queue_set_filter+0x23a/0x740 __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88800d2c66a0 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 28 bytes inside of 32-byte region [ffff88800d2c66a0, ffff88800d2c66c0)
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/25/2024
The vulnerability identified as CVE-2022-48847 resides within the Linux kernel's watch_queue subsystem, specifically in the watch_queue_set_filter function where improper bounds checking leads to potential out-of-bounds memory accesses. This flaw manifests due to a discrepancy in how the system calculates the maximum allowable filter type values, creating conditions where malicious input could trigger kernel memory corruption. The issue affects the kernel's ability to properly validate filter type values against the available type_filter bitmap capacity, potentially enabling privilege escalation or system instability through carefully crafted ioctl operations.
The technical root cause stems from inconsistent bit width calculations within the filter validation logic. While one validation correctly uses sizeof(wfilter->type_filter) 8 to determine the number of available bits, a second check incorrectly employs sizeof(wfilter->type_filter) BITS_PER_LONG, which results in an inflated bit count. This miscalculation allows filter type values that exceed the actual allocated space, leading to memory corruption when the system attempts to set bits in the type_filter bitmap or populate the filters array beyond its allocated boundaries. The vulnerability specifically impacts the __set_bit() operation and array writes in wfilter->filters[], both of which can overwrite adjacent memory regions.
The operational impact of this vulnerability extends beyond simple memory corruption, as it can be exploited to trigger kernel oops conditions and potentially enable more serious security breaches. The KASAN (Kernel Address Sanitizer) report indicates that the bug manifests as a slab-out-of-bounds write operation, where the kernel attempts to write 4 bytes at an address that exceeds the allocated memory region. This type of memory corruption can lead to system crashes, data corruption, or in more sophisticated exploitation scenarios, allow attackers to gain elevated privileges or execute arbitrary code within the kernel context. The vulnerability is particularly concerning as it operates through standard ioctl system calls, making it accessible to unprivileged users who can craft malicious inputs to trigger the flawed code path.
Mitigation strategies for this vulnerability involve applying the official kernel patch that corrects the bit width calculation by utilizing WATCH_TYPE__NR instead of the incorrect BITS_PER_LONG multiplier. This ensures that filter type values are properly validated against the actual number of supported types rather than an inflated theoretical maximum. System administrators should prioritize updating to kernel versions containing this fix, particularly in environments where untrusted users might have access to ioctl operations. Additionally, monitoring for unusual kernel oops messages or memory allocation patterns can help detect exploitation attempts. The vulnerability aligns with CWE-129, which addresses insufficient validation of length of input buffers, and can be mapped to ATT&CK technique T1068, which covers privilege escalation through local exploits. Organizations should also consider implementing kernel hardening measures such as KASAN and other memory safety mechanisms to detect and prevent similar out-of-bounds access patterns in other kernel subsystems.