CVE-2024-56548: hfsplus: don't query the device logical block size multiple times
In the Linux kernel, the following vulnerability has been resolved:
hfsplus: don't query the device logical block size multiple times
Devices block sizes may change. One of these cases is a loop device by using ioctl LOOPSETBLOCKSIZE.
While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplusreadwrapper calls hfsplussubmitbio and the latter function reads a different iosize.
Using a new miniosize initally set to sbminblocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUSSECTORSIZE and the first seen logical block size. We still use the max between HFSPLUSSECTORSIZE and miniosize in case the latter is not initialized.
Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096.
The produced KASAN report before the fix looks like this:
[ 419.944641] ================================================================== [ 419.945655] BUG: KASAN: slab-use-after-free in hfsplusreadwrapper+0x659/0xa0a [ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Call Trace: [ 419.950384] <TASK> [ 419.950676] dumpstacklvl+0x57/0x78 [ 419.951212] ? hfsplusreadwrapper+0x659/0xa0a [ 419.951830] printreport+0x14c/0x49e [ 419.952361] ? virtaddrvalid+0x267/0x278 [ 419.952979] ? kmemcachedebugflags+0xc/0x1d [ 419.953561] ? hfsplusreadwrapper+0x659/0xa0a [ 419.954231] kasanreport+0x89/0xb0 [ 419.954748] ? hfsplusreadwrapper+0x659/0xa0a [ 419.955367] hfsplusreadwrapper+0x659/0xa0a [ 419.955948] ? pfxhfsplusreadwrapper+0x10/0x10 [ 419.956618] ? dorawspinunlock+0x59/0x1a9 [ 419.957214] ? rawspinunlock+0x1a/0x2e [ 419.957772] hfsplusfillsuper+0x348/0x1590 [ 419.958355] ? hlockclass+0x4c/0x109 [ 419.958867] ? pfxhfsplusfillsuper+0x10/0x10 [ 419.959499] ? pfxstring+0x10/0x10 [ 419.960006] ? lockacquire+0x3e2/0x454 [ 419.960532] ? bdevname.constprop.0+0xce/0x243 [ 419.961129] ? pfxbdevname.constprop.0+0x10/0x10 [ 419.961799] ? pointer+0x3f0/0x62f [ 419.962277] ? pfxpointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? pfxvsnprintf+0x10/0x10 [ 419.963621] ? setupbdevsuper+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? pfxsnprintf+0x10/0x10 [ 419.964675] ? lockacquired+0x45c/0x5e9 [ 419.965016] ? setblocksize+0x139/0x1c1 [ 419.965381] ? sbsetblocksize+0x6d/0xae [ 419.965742] ? pfxhfsplusfillsuper+0x10/0x10 [ 419.966179] mountbdev+0x12f/0x1bf [ 419.966512] ? pfxmountbdev+0x10/0x10 [ 419.966886] ? vfsparsefsstring+0xce/0x111 [ 419.967293] ? pfxvfsparsefsstring+0x10/0x10 [ 419.967702] ? pfxhfsplusmount+0x10/0x10 [ 419.968073] legacygettree+0x104/0x178 [ 419.968414] vfsgettree+0x86/0x296 [ 419.968751] pathmount+0xba3/0xd0b [ 419.969157] ? pfxpathmount+0x10/0x10 [ 419.969594] ? kmemcachefree+0x1e2/0x260 [ 419.970311] domount+0x99/0xe0 [ 419.970630] ? pfxdomount+0x10/0x10 [ 419.971008] dosysmount+0x199/0x1c9 [ 419.971397] dosyscall64+0xd0/0x135 [ 419.971761] entrySYSCALL64afterhwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIGRAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated---
Other sources
This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.
— Launchpad
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.25-1Fixed in 6.12.27-1 - Upgrade
Upgrade
debian/linux-6.1to a version that resolves this vulnerability.Fixed in 6.1.129-1~deb11u1
Event History
Frequently Asked Questions
What is the severity of CVE-2024-56548?
The severity of CVE-2024-56548 is classified as low, primarily affecting the handling of device logical block sizes.
How do I fix CVE-2024-56548?
To fix CVE-2024-56548, ensure that you update your Linux kernel to the latest stable version where this vulnerability has been patched.
What types of software are affected by CVE-2024-56548?
CVE-2024-56548 affects the Linux Kernel, particularly implementations involving HFS+ filesystem on block devices.
What impact does CVE-2024-56548 have on systems?
CVE-2024-56548 could lead to potential stability issues in systems using loop devices and may result in unpredictable IO behavior.
Is CVE-2024-56548 being actively exploited?
As of the current information, there are no known active exploits for CVE-2024-56548.