CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47702 – bpf: Fail verification for sign-extension of packet data/data_end/data_meta
https://notcve.org/view.php?id=CVE-2024-47702
In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 ("bpf: Handle sign-extenstin ctx member accesses"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since "r2 <<= 32" is not allowed as "r2" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/ • https://git.kernel.org/stable/c/1f1e864b65554e33fe74e3377e58b12f4302f2eb https://git.kernel.org/stable/c/f1620c93a1ec950d87ef327a565d3907736d3340 https://git.kernel.org/stable/c/f09757fe97a225ae505886eac572e4cbfba96537 https://git.kernel.org/stable/c/92de36080c93296ef9005690705cba260b9bd68a •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47701 – ext4: avoid OOB when system.data xattr changes underneath the filesystem
https://notcve.org/view.php?id=CVE-2024-47701
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 </TASK> Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem. • https://git.kernel.org/stable/c/e8e948e7802a2ab05c146d3e72a39b93b5718236 https://git.kernel.org/stable/c/7fc22c3b3ffc0e952f5e0062dd11aa6ae76affba https://git.kernel.org/stable/c/be2e9b111e2790962cc66a177869b4e9717b4e29 https://git.kernel.org/stable/c/ea32883e4a03ed575a2eb7a66542022312bde477 https://git.kernel.org/stable/c/2a6579ef5f2576a940125729f7409cc182f1c8df https://git.kernel.org/stable/c/371d0bacecd529f887ea2547333d9173e7bcdc0a https://git.kernel.org/stable/c/ccb8c18076e2e630fea23fbec583cdad61787fc5 https://git.kernel.org/stable/c/c6b72f5d82b1017bad80f9ebf502832fc •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-47700 – ext4: check stripe size compatibility on remount as well
https://notcve.org/view.php?id=CVE-2024-47700
In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well. • https://git.kernel.org/stable/c/c3defd99d58cbdd132bd197714e5523dac976b66 https://git.kernel.org/stable/c/faeff8b1ee2eaa5969c8e994d66c3337298cefed https://git.kernel.org/stable/c/297615e992bbb30a55c158141086be6505d5d722 https://git.kernel.org/stable/c/a31b712f75445d52fc0451dc54fd7b16a552cb7c https://git.kernel.org/stable/c/ee85e0938aa8f9846d21e4d302c3cf6a2a75110d •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47699 – nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()
https://notcve.org/view.php?id=CVE-2024-47699
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series "nilfs2: fix potential issues with empty b-tree nodes". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on. • https://git.kernel.org/stable/c/17c76b0104e4a6513983777e1a17e0297a12b0c4 https://git.kernel.org/stable/c/24bf40740a3da6b4056721da34997ae6938f3da1 https://git.kernel.org/stable/c/73d23ecf234b7a6d47fb883f2dabe10e3230b31d https://git.kernel.org/stable/c/f68523e0f26faade18833fbef577a4295d8e2c94 https://git.kernel.org/stable/c/21839b6fbc3c41b3e374ecbdb0cabbbb2c53cf34 https://git.kernel.org/stable/c/db73500d3f0e558eb642aae1d4782e7726b4a03f https://git.kernel.org/stable/c/3644554d308ddf2669e459a1551a7edf60b2d62b https://git.kernel.org/stable/c/9403001ad65ae4f4c5de368bdda3a0636 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47698 – drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
https://notcve.org/view.php?id=CVE-2024-47698
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg] • https://git.kernel.org/stable/c/4b01e01a81b6629878344430531ced347cc2ed5b https://git.kernel.org/stable/c/6ae3b9aee42616ee93c4585174f40c767828006d https://git.kernel.org/stable/c/a879b6cdd48134a3d58949ea4f075c75fa2d7d71 https://git.kernel.org/stable/c/15bea004e939d938a6771dfcf2a26cc899ffd20a https://git.kernel.org/stable/c/527ab3eb3b0b4a6ee00e183c1de6a730239e2835 https://git.kernel.org/stable/c/66dbe0df6eccc7ee53a2c35016ce81e13b3ff447 https://git.kernel.org/stable/c/bedd42e07988dbdd124b23e758ffef7a681b9c60 https://git.kernel.org/stable/c/8ae06f360cfaca2b88b98ca89144548b3 •