CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-37354 – btrfs: fix crash on racing fsync and size-extending write into prealloc
https://notcve.org/view.php?id=CVE-2024-37354
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix crash on racing fsync and size-extending write into prealloc We have been seeing crashes on duplicate keys in btrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs] With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file.c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c:212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121) So we're logging a changed extent from fsync, which is splitting an extent in the log tree. But this split part already exists in the tree, triggering the BUG(). This is the state of the log tree at the time of the crash, dumped with drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py) to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ... So the real problem happened earlier: notice that items 4 (4k-12k) and 5 (8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and item 5 starts at i_size. Here is the state of ---truncated--- • https://git.kernel.org/stable/c/1ff2bd566fbcefcb892be85c493bdb92b911c428 https://git.kernel.org/stable/c/3d08c52ba1887a1ff9c179d4b6a18b427bcb2097 https://git.kernel.org/stable/c/f4e5ed974876c14d3623e04dc43d3e3281bc6011 https://git.kernel.org/stable/c/9d274c19a71b3a276949933859610721a453946b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-37078 – nilfs2: fix potential kernel bug due to lack of writeback flag waiting
https://notcve.org/view.php?id=CVE-2024-37078
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential kernel bug due to lack of writeback flag waiting Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (__folio_start_writeback in the log below): kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state. Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state. • https://git.kernel.org/stable/c/9ff05123e3bfbb1d2b68ba1d9bf1f7d1dffc1453 https://git.kernel.org/stable/c/95f6f81e50d858a7c9aa7c795ec14a0ac3819118 https://git.kernel.org/stable/c/a75b8f493dfc48aa38c518430bd9e03b53bffebe https://git.kernel.org/stable/c/0ecfe3a92869a59668d27228dabbd7965e83567f https://git.kernel.org/stable/c/33900d7eae616647e179eee1c66ebe654ee39627 https://git.kernel.org/stable/c/271dcd977ccda8c7a26e360425ae7b4db7d2ecc0 https://git.kernel.org/stable/c/614d397be0cf43412b3f94a0f6460eddced8ce92 https://git.kernel.org/stable/c/1f3bff69f1214fe03a02bc650d5bbfaa6 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48772 – media: lgdt3306a: Add a check against null-pointer-def
https://notcve.org/view.php?id=CVE-2022-48772
In the Linux kernel, the following vulnerability has been resolved: media: lgdt3306a: Add a check against null-pointer-def The driver should check whether the client provides the platform_data. The following log reveals it: [ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasan_report+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasan_check_range+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306a_probe+0x52/0x310 [ 29.616339] i2c_device_probe+0x951/0xa90 • https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0 https://git.kernel.org/stable/c/b479fd59a1f4a342b69fce34f222d93bf791dca4 https://git.kernel.org/stable/c/526238d32c3acc3d597fd8c9a34652bfe9086cea https://git.kernel.org/stable/c/d082757b8359201c3864323cea4b91ea30a1e676 https://git.kernel.org/stable/c/7d12e918f2994c883f41f22552a61b9310fa1e87 https://git.kernel.org/stable/c/8e1e00718d0d9dd83337300572561e30b9c0d115 https://git.kernel.org/stable/c/c1115ddbda9c930fba0fdd062e7a8873ebaf898d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-37021 – fpga: manager: add owner module and take its refcount
https://notcve.org/view.php?id=CVE-2024-37021
In the Linux kernel, the following vulnerability has been resolved: fpga: manager: add owner module and take its refcount The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga manager. Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions. • https://git.kernel.org/stable/c/654ba4cc0f3ed7c0f08bfb39f66059d8c42943ee https://git.kernel.org/stable/c/2da62a139a6221a345db4eb9f4f1c4b0937c89ad https://git.kernel.org/stable/c/62ac496a01c9337a11362cea427038ba621ca9eb https://git.kernel.org/stable/c/4d4d2d4346857bf778fafaa97d6f76bb1663e3c9 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39292 – um: Add winch to winch_handlers before registering winch IRQ
https://notcve.org/view.php?id=CVE-2024-39292
In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: um: Agregar cabrestante a winch_handlers antes de registrar la IRQ del cabrestante Registrar una IRQ del cabrestante es picante, puede ocurrir una interrupción antes de que el cabrestante se agregue a la lista de winch_handlers. Si eso sucede, Register_winch_irq() agrega a esa lista un cabrestante que está programado para ser liberado (o que ya ha sido) liberado, causando pánico más adelante en winch_cleanup(). Evite la ejecución agregando el cabrestante a la lista winch_handlers antes de registrar la IRQ y retrocediendo si um_request_irq() falla. • https://git.kernel.org/stable/c/42a359e31a0e438b5b978a8f0fecdbd3c86bb033 https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33 https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0 https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14 https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2 https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4 https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0 https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a • CWE-415: Double Free •