CVE-2024-56548

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 LOOPSETBLOCK_SIZE.

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 io_size.

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---