CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-34027 – f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
https://notcve.org/view.php?id=CVE-2024-34027
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. • https://git.kernel.org/stable/c/c75488fb4d82b697f381f855bf5b16779df440aa https://git.kernel.org/stable/c/a6e1f7744e9b84f86a629a76024bba8468aa153b https://git.kernel.org/stable/c/b5bac43875aa27ec032dbbb86173baae6dce6182 https://git.kernel.org/stable/c/5d47d63883735718825ca2efc4fca6915469774f https://git.kernel.org/stable/c/329edb7c9e3b6ca27e6ca67ab1cdda1740fb3a2b https://git.kernel.org/stable/c/69136304fd144144a4828c7b7b149d0f80321ba4 https://git.kernel.org/stable/c/0a4ed2d97cb6d044196cc3e726b6699222b41019 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-33847 – f2fs: compress: don't allow unaligned truncation on released compress inode
https://notcve.org/view.php?id=CVE-2024-33847
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: don't allow unaligned truncation on released compress inode f2fs image may be corrupted after below testcase: - mkfs.f2fs -O extra_attr,compression -f /dev/vdb - mount /dev/vdb /mnt/f2fs - touch /mnt/f2fs/file - f2fs_io setflags compression /mnt/f2fs/file - dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=4 - f2fs_io release_cblocks /mnt/f2fs/file - truncate -s 8192 /mnt/f2fs/file - umount /mnt/f2fs - fsck.f2fs /dev/vdb [ASSERT] (fsck_chk_inode_blk:1256) --> ino: 0x5 has i_blocks: 0x00000002, but has 0x3 blocks [FSCK] valid_block_count matching with CP [Fail] [0x4, 0x5] [FSCK] other corrupted bugs [Fail] The reason is: partial truncation assume compressed inode has reserved blocks, after partial truncation, valid block count may change w/o .i_blocks and .total_valid_block_count update, result in corruption. This patch only allow cluster size aligned truncation on released compress inode for fixing. • https://git.kernel.org/stable/c/c61404153eb683da9c35aad133131554861ed561 https://git.kernel.org/stable/c/8acae047215024d1ac499b3c8337ef1b952f160b https://git.kernel.org/stable/c/3ccf5210dc941a7aa0180596ac021568be4d35ec https://git.kernel.org/stable/c/9f9341064a9b5246a32a7fe56b9f80c6f7f3c62d https://git.kernel.org/stable/c/5268241b41b1c5d0acca75e9b97d4fd719251c8c https://git.kernel.org/stable/c/29ed2b5dd521ce7c5d8466cd70bf0cc9d07afeee https://git.kernel.org/stable/c/b8962cf98595d1ec62f40f23667de830567ec8bc •
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 •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38667 – riscv: prevent pt_regs corruption for secondary idle threads
https://notcve.org/view.php?id=CVE-2024-38667
In the Linux kernel, the following vulnerability has been resolved: riscv: prevent pt_regs corruption for secondary idle threads Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted. Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context. • https://git.kernel.org/stable/c/2875fe0561569f82d0e63658ccf0d11ce7da8922 https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44 https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80 https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af • CWE-787: Out-of-bounds Write •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-34777 – dma-mapping: benchmark: fix node id validation
https://notcve.org/view.php?id=CVE-2024-34777
In the Linux kernel, the following vulnerability has been resolved: dma-mapping: benchmark: fix node id validation While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to: BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node. Found by Linux Verification Center (linuxtesting.org). • https://git.kernel.org/stable/c/65789daa8087e125927230ccb7e1eab13999b0cf https://git.kernel.org/stable/c/35d31c8bd4722b107f5a2f5ddddce839de04b936 https://git.kernel.org/stable/c/c57874265a3c5206d7aece3793bb2fc9abcd7570 https://git.kernel.org/stable/c/34a816d8735f3924b74be8e5bf766ade1f3bd10b https://git.kernel.org/stable/c/63e7e05a48a35308aeddd7ecccb68363a5988e87 https://git.kernel.org/stable/c/1ff05e723f7ca30644b8ec3fb093f16312e408ad •