CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-46736 – smb: client: fix double put of @cfile in smb2_rename_path()
https://notcve.org/view.php?id=CVE-2024-46736
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double put of @cfile in smb2_rename_path() If smb2_set_path_attr() is called with a valid @cfile and returned -EINVAL, we need to call cifs_get_writable_path() again as the reference of @cfile was already dropped by previous smb2_compound_op() call. • https://git.kernel.org/stable/c/1e60bc0e954389af82f1d9a85f13a63f6572350f https://git.kernel.org/stable/c/71f15c90e785d1de4bcd65a279e7256684c25c0d https://git.kernel.org/stable/c/b27ea9c96efd2c252a981fb00d0f001b86c90f3e https://git.kernel.org/stable/c/1a46c7f6546b73cbf36f5a618a1a6bbb45391eb3 https://git.kernel.org/stable/c/3523a3df03c6f04f7ea9c2e7050102657e331a4f •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46735 – ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery()
https://notcve.org/view.php?id=CVE-2024-46735
In the Linux kernel, the following vulnerability has been resolved: ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery() When two UBLK_CMD_START_USER_RECOVERY commands are submitted, the first one sets 'ubq->ubq_daemon' to NULL, and the second one triggers WARN in ublk_queue_reinit() and subsequently a NULL pointer dereference issue. Fix it by adding the check in ublk_ctrl_start_recovery() and return immediately in case of zero 'ub->nr_queues_ready'. BUG: kernel NULL pointer dereference, address: 0000000000000028 RIP: 0010:ublk_ctrl_start_recovery.constprop.0+0x82/0x180 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x75/0x170 ? exc_page_fault+0x64/0x140 ? asm_exc_page_fault+0x22/0x30 ? • https://git.kernel.org/stable/c/c732a852b419fa057b53657e2daaf9433940391c https://git.kernel.org/stable/c/ca249435893dda766f3845c15ca77ca5672022d8 https://git.kernel.org/stable/c/136a29d8112df4ea0a57f9602ddf3579e04089dc https://git.kernel.org/stable/c/7c890ef60bf417d3fe5c6f7a9f6cef0e1d77f74f https://git.kernel.org/stable/c/e58f5142f88320a5b1449f96a146f2f24615c5c7 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46734 – btrfs: fix race between direct IO write and fsync when using same fd
https://notcve.org/view.php?id=CVE-2024-46734
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between direct IO write and fsync when using same fd If we have 2 threads that are using the same file descriptor and one of them is doing direct IO writes while the other is doing fsync, we have a race where we can end up either: 1) Attempt a fsync without holding the inode's lock, triggering an assertion failures when assertions are enabled; 2) Do an invalid memory access from the fsync task because the file private points to memory allocated on stack by the direct IO task and it may be used by the fsync task after the stack was destroyed. The race happens like this: 1) A user space program opens a file descriptor with O_DIRECT; 2) The program spawns 2 threads using libpthread for example; 3) One of the threads uses the file descriptor to do direct IO writes, while the other calls fsync using the same file descriptor. 4) Call task A the thread doing direct IO writes and task B the thread doing fsyncs; 5) Task A does a direct IO write, and at btrfs_direct_write() sets the file's private to an on stack allocated private with the member 'fsync_skip_inode_lock' set to true; 6) Task B enters btrfs_sync_file() and sees that there's a private structure associated to the file which has 'fsync_skip_inode_lock' set to true, so it skips locking the inode's VFS lock; 7) Task A completes the direct IO write, and resets the file's private to NULL since it had no prior private and our private was stack allocated. Then it unlocks the inode's VFS lock; 8) Task B enters btrfs_get_ordered_extents_for_logging(), then the assertion that checks the inode's VFS lock is held fails, since task B never locked it and task A has already unlocked it. The stack trace produced is the following: assertion failed: inode_is_locked(&inode->vfs_inode), in fs/btrfs/ordered-data.c:983 ------------[ cut here ]------------ kernel BUG at fs/btrfs/ordered-data.c:983! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 9 PID: 5072 Comm: worker Tainted: G U OE 6.10.5-1-default #1 openSUSE Tumbleweed 69f48d427608e1c09e60ea24c6c55e2ca1b049e8 Hardware name: Acer Predator PH315-52/Covini_CFS, BIOS V1.12 07/28/2020 RIP: 0010:btrfs_get_ordered_extents_for_logging.cold+0x1f/0x42 [btrfs] Code: 50 d6 86 c0 e8 (...) RSP: 0018:ffff9e4a03dcfc78 EFLAGS: 00010246 RAX: 0000000000000054 RBX: ffff9078a9868e98 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff907dce4a7800 RDI: ffff907dce4a7800 RBP: ffff907805518800 R08: 0000000000000000 R09: ffff9e4a03dcfb38 R10: ffff9e4a03dcfb30 R11: 0000000000000003 R12: ffff907684ae7800 R13: 0000000000000001 R14: ffff90774646b600 R15: 0000000000000000 FS: 00007f04b96006c0(0000) GS:ffff907dce480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f32acbfc000 CR3: 00000001fd4fa005 CR4: 00000000003726f0 Call Trace: <TASK> ? __die_body.cold+0x14/0x24 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? • https://git.kernel.org/stable/c/4e17707035a65f6e5b2a4d987a308cf8ed8c5ad1 https://git.kernel.org/stable/c/6cae8d04d8b3d1ecfadcaa989e673f6f73349ed5 https://git.kernel.org/stable/c/0a108bde616a7017653385b5a12111015051a294 https://git.kernel.org/stable/c/3831170f740685fddc8f6aa57a83ad0fef4711bf https://git.kernel.org/stable/c/d116a0b0e02f395cedfb8c725bd67480aa7c428c https://git.kernel.org/stable/c/cd3087582e4fa36e89be4e6f859e75a4400292b4 https://git.kernel.org/stable/c/7b5595f33c3c273613b590892a578d78186bb400 https://git.kernel.org/stable/c/01681aa609b5f110502f56c4e3b2938ef •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46733 – btrfs: fix qgroup reserve leaks in cow_file_range
https://notcve.org/view.php?id=CVE-2024-46733
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix qgroup reserve leaks in cow_file_range In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent. Therefore, any errors that occur before the ordered_extent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cow_file_range where we fail to get to allocating the ordered extent. Note that because we *do* clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path. This results in failures at the unmount stage of the test that look like: BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:close_ctree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: <TASK> ? close_ctree+0x222/0x4d0 [btrfs] ? __warn.cold+0x8e/0xea ? • https://git.kernel.org/stable/c/e42ef22bc10f0309c0c65d8d6ca8b4127a674b7f https://git.kernel.org/stable/c/30479f31d44d47ed00ae0c7453d9b253537005b2 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-46732 – drm/amd/display: Assign linear_pitch_alignment even for VM
https://notcve.org/view.php?id=CVE-2024-46732
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Assign linear_pitch_alignment even for VM [Description] Assign linear_pitch_alignment so we don't cause a divide by 0 error in VM environments • https://git.kernel.org/stable/c/4bd7710f2fecfc5fb2dda1ca2adc69db8a66b8b6 https://git.kernel.org/stable/c/d219f902b16d42f0cb8c499ea8f31cf3c0f36349 https://git.kernel.org/stable/c/d2fe7ac613a1ea8c346c9f5c89dc6ecc27232997 https://git.kernel.org/stable/c/c44b568931d23aed9d37ecbb31fb5fbdd198bf7b https://git.kernel.org/stable/c/984debc133efa05e62f5aa1a7a1dd8ca0ef041f4 •