CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52640 – fs/ntfs3: Fix oob in ntfs_listxattr
https://notcve.org/view.php?id=CVE-2023-52640
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix oob in ntfs_listxattr The length of name cannot exceed the space occupied by ea. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se corrige oob en ntfs_listxattr La longitud del nombre no puede exceder el espacio ocupado por ea. • https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23 https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26726 – btrfs: don't drop extent_map for free space inode on write error
https://notcve.org/view.php?id=CVE-2024-26726
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. • https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555 https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7 https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade •
CVSS: 5.5EPSS: 0%CPEs: 18EXPL: 0CVE-2024-26720 – mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
https://notcve.org/view.php?id=CVE-2024-26720
In the Linux kernel, the following vulnerability has been resolved: mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again (struct dirty_throttle_control *)->thresh is an unsigned long, but is passed as the u32 divisor argument to div_u64(). On architectures where unsigned long is 64 bytes, the argument will be implicitly truncated. Use div64_u64() instead of div_u64() so that the value used in the "is this a safe division" check is the same as the divisor. Also, remove redundant cast of the numerator to u64, as that should happen implicitly. This would be difficult to exploit in memcg domain, given the ratio-based arithmetic domain_drity_limits() uses, but is much easier in global writeback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/writeback: corrige la posible división por cero en wb_dirty_limits(), nuevamente (struct dirty_throttle_control *)->thresh es un largo sin firmar, pero se pasa como argumento del divisor u32 a div_u64(). En arquitecturas donde la longitud sin firmar es de 64 bytes, el argumento se truncará implícitamente. Utilice div64_u64() en lugar de div_u64() para que el valor utilizado en la comprobación "¿Es esta una división segura" sea el mismo que el divisor? Además, elimine la conversión redundante del numerador a u64, ya que eso debería suceder implícitamente. • https://git.kernel.org/stable/c/f6789593d5cea42a4ecb1cbeab6a23ade5ebbba7 https://git.kernel.org/stable/c/c5fec566bef6a027e75c84c35ec970482eb88cea https://git.kernel.org/stable/c/c05d1fe6c19f4df2f0b8cba151a8f0c53b87d878 https://git.kernel.org/stable/c/3f7d325fbbe12e5ade71a1f90759c06ed2d27e3c https://git.kernel.org/stable/c/c593d26fb5d577ef31b6e49a31e08ae3ebc1bc1e https://git.kernel.org/stable/c/253f9ea7e8e53a5176bd80ceb174907b10724c1a https://git.kernel.org/stable/c/1f12e4b3284d6c863f272eb2de0d4248ed211cf4 https://git.kernel.org/stable/c/23a28f5f3f6ca1e4184bd0e9631cd0944 • CWE-369: Divide By Zero •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26719 – nouveau: offload fence uevents work to workqueue
https://notcve.org/view.php?id=CVE-2024-26719
In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nuevo: descargar valla uevents work to workqueue Esto debería romper el punto muerto entre el bloqueo fctx y el bloqueo irq. Esto descarga el procesamiento del trabajo del irq a una cola de trabajo. • https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906 https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9 https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0 https://access.redhat.com/security/cve/CVE-2024-26719 https://bugzilla.redhat.com/show_bug.cgi?id=2273143 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26706 – parisc: Fix random data corruption from exception handler
https://notcve.org/view.php?id=CVE-2024-26706
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not convert to an integer. This patch takes another, better and more flexible approach: We extend the __ex_table (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction "or %r0,%r0,%reg", where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the __ex_table entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register. Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT config option any longer. • https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592 https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2 https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003 https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831 •