{"uuid": "cbeab3db-0d97-4414-8081-9eb8fa39b098", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2023-53143", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/24353", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2023-53143 - \"Ext4 Linux Kernel Off-by-One Error in fsmap Handling\"\", \n  \"Content\": \"CVE ID : CVE-2023-53143 \nPublished : May 2, 2025, 4:15 p.m. | 1\u00a0hour, 4\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \next4: fix another off-by-one fsmap error on 1k block filesystems  \n  \nApparently syzbot figured out that issuing this FSMAP call:  \n  \nstruct fsmap_head cmd = {  \n .fmh_count = ...;  \n .fmh_keys = {  \n  { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },  \n  { .fmr_device = /* ext4 dev */, .fmr_physical = 0, },  \n },  \n...  \n};  \nret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);  \n  \nProduces this crash if the underlying filesystem is a 1k-block ext4  \nfilesystem:  \n  \nkernel BUG at fs/ext4/ext4.h:3331!  \ninvalid opcode: 0000 [#1] PREEMPT SMP  \nCPU: 3 PID: 3227965 Comm: xfs_io Tainted: G        W  O       6.2.0-rc8-achx  \nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014  \nRIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]  \nRSP: 0018:ffffc90007c03998 EFLAGS: 00010246  \nRAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000  \nRDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11  \nRBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400  \nR10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001  \nR13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398  \nFS:  00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000  \nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \nCR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0  \nCall Trace:  \n   \n ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]  \n ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]  \n ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]  \n ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]  \n __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80]  \n __x64_sys_ioctl+0x82/0xa0  \n do_syscall_64+0x2b/0x80  \n entry_SYSCALL_64_after_hwframe+0x46/0xb0  \nRIP: 0033:0x7fdf20558aff  \nRSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010  \nRAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff  \nRDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003  \nRBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001  \nR10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010  \nR13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000  \n  \nFor GETFSMAP calls, the caller selects a physical block device by  \nwriting its block number into fsmap_head.fmh_keys[01].fmr_device.  \nTo query mappings for a subrange of the device, the starting byte of the  \nrange is written to fsmap_head.fmh_keys[0].fmr_physical and the last  \nbyte of the range goes in fsmap_head.fmh_keys[1].fmr_physical.  \n  \nIOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you'd  \nset the inputs as follows:  \n  \n fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3},  \n fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14},  \n  \nWhich would return you whatever is mapped in the 12 bytes starting at  \nphysical offset 3.  \n  \nThe crash is due to insufficient range validation of keys[1] in  \next4_getfsmap_datadev.  On 1k-block filesystems, block 0 is not part of  \nthe filesystem, which means that s_first_data_block is nonzero.  \next4_get_group_no_and_offset subtracts this quantity from the blocknr  \nargument before cracking it into a group number and a block number  \nwithin a group.  IOWs, block group 0 spans blocks 1-8192 (1-based)  \ninstead of 0-8191 (0-based) like what happens with larger blocksizes.  \n  \nThe net result of this encoding is that blocknr < s_first_data_block is  \nnot a valid input to this function.  The end_fsb variable is set from  \nthe keys that are copied from userspace, which means that in the above  \nexample, its value is zero.  That leads [...]", "creation_timestamp": "2025-05-02T20:07:39.000000Z"}