Out-of-bounds Read Affecting kernel-64k-debug-modules-core package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL9-KERNEL64KDEBUGMODULESCORE-8424656
- published27 Nov 2024
- disclosed19 Nov 2024
Introduced: 19 Nov 2024
CVE-2024-50278 (opens in a new tab)How to fix?
There is no fixed version for RHEL:9 kernel-64k-debug-modules-core.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-64k-debug-modules-core package and not the kernel-64k-debug-modules-core package as distributed by RHEL.
See How to fix? for RHEL:9 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix potential out-of-bounds access on the first resume
Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue.
Reproduce steps:
- prepare component devices:
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct
- load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate.
dmsetup create cache --notable
dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache
- suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40:
dmsetup suspend cache
KASAN reports:
BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90
(...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0
(...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
Fix by checking the size change on the first resume.
References
- https://access.redhat.com/security/cve/CVE-2024-50278
- https://git.kernel.org/stable/c/036dd6e3d2638103e0092864577ea1d091466b86
- https://git.kernel.org/stable/c/13ed3624c6ef283acefa4cc42cc8ae54fd4391a4
- https://git.kernel.org/stable/c/2222b0929d00e2d13732b799b63be391b5de4492
- https://git.kernel.org/stable/c/483b7261b35a9d369082ab298a6670912243f0be
- https://git.kernel.org/stable/c/c0ade5d98979585d4f5a93e4514c2e9a65afa08d
- https://git.kernel.org/stable/c/c52ec00cb2f9bebfada22edcc0db385b910a1cdb
- https://git.kernel.org/stable/c/e492f71854ce03474d49e87fd98b8df1f7cd1d2d
- https://git.kernel.org/stable/c/fdef3b94dfebd57e3077a578b6e309a2bb6fa688