CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52641 – fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame()
https://notcve.org/view.php?id=CVE-2023-52641
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame() It is preferable to exit through the out: label because internal debugging functions are located there. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Agregar verificación de desreferencia de ptr NULL al final de attr_allocate_frame() Es preferible salir por la etiqueta out: porque las funciones de depuración interna se encuentran allí. • https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a •
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: 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 •