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: 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: 8EXPL: 0CVE-2024-47683 – drm/amd/display: Skip Recompute DSC Params if no Stream on Link
https://notcve.org/view.php?id=CVE-2024-47683
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip Recompute DSC Params if no Stream on Link [why] Encounter NULL pointer dereference uner mst + dsc setup. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? • https://git.kernel.org/stable/c/282f0a482ee61d5e863512f3c4fcec90216c20d9 https://git.kernel.org/stable/c/7c887efda1201110211fed8921a92a713e0b6bcd https://git.kernel.org/stable/c/718d83f66fb07b2cab89a1fc984613a00e3db18f https://git.kernel.org/stable/c/a53841b074cc196c3caaa37e1f15d6bc90943b97 https://git.kernel.org/stable/c/70275bb960c71d313254473d38c14e7101cee5ad https://git.kernel.org/stable/c/6f9c39e8169384d2a5ca9bf323a0c1b81b3d0f3a https://git.kernel.org/stable/c/d45c64d933586d409d3f1e0ecaca4da494b1d9c6 https://git.kernel.org/stable/c/8151a6c13111b465dbabe07c19f572f7c •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47679 – vfs: fix race between evice_inodes() and find_inode()&iput()
https://notcve.org/view.php?id=CVE-2024-47679
In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug. • https://git.kernel.org/stable/c/63997e98a3be68d7cec806d22bf9b02b2e1daabb https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195 https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1 https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1 https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11 https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47674 – mm: avoid leaving partial pfn mappings around in error case
https://notcve.org/view.php?id=CVE-2024-47674
In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: evitar dejar asignaciones pfn parciales en caso de error Como señala Jann, las asignaciones PFN son especiales, porque a diferencia de las asignaciones de memoria normales, no hay información de duración asociada con la asignación: es solo una asignación sin procesar de PFN sin recuento de referencias de una 'página de estructura'. Todo eso es muy intencional, pero significa que es fácil arruinar la limpieza en caso de errores. Sí, un mmap() fallido siempre limpiará eventualmente cualquier asignación parcial, pero sin ninguna duración explícita en la asignación de la tabla de páginas en sí, es muy fácil hacer el manejo de errores en el orden incorrecto. • https://git.kernel.org/stable/c/5b2c8b34f6d76bfbd1dd4936eb8a0fbfb9af3959 https://git.kernel.org/stable/c/65d0db500d7c07f0f76fc24a4d837791c4862cd2 https://git.kernel.org/stable/c/a95a24fcaee1b892e47d5e6dcc403f713874ee80 https://git.kernel.org/stable/c/954fd4c81f22c4b6ba65379a81fd252971bf4ef3 https://git.kernel.org/stable/c/79a61cc3fc0466ad2b7b89618a6157785f0293b3 https://project-zero.issues.chromium.org/issues/366053091 •