CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53142 – initramfs: avoid filename buffer overrun
https://notcve.org/view.php?id=CVE-2024-53142
In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar="A" # change to "\0" to properly zero terminate / pad magic="070701" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfs_test_fname_overrun" namelen=$(( ${#fname} + 1 )) # plus one to account for terminator printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf "%.s${nilchar}" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/bb7ac96670ab1d8d681015f9d66e45dad579af4d https://git.kernel.org/stable/c/c509b1acbd867d9e09580fe059a924cb5825afb1 https://git.kernel.org/stable/c/d3df9f26cff97beaa5643e551031795d5d5cddbe https://git.kernel.org/stable/c/6983b8ac787b3add5571cda563574932a59a99bb https://git.kernel.org/stable/c/f892ddcf9f645380c358e73653cb0900f6bc9eb8 https://git.kernel.org/stable/c/1a423bbbeaf9e3e20c4686501efd9b661fe834db https://git.kernel.org/stable/c/49d01e736c3045319e030d1e75fb98301 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53141 – netfilter: ipset: add missing range check in bitmap_ip_uadt
https://notcve.org/view.php?id=CVE-2024-53141
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks. • https://git.kernel.org/stable/c/72205fc68bd13109576aa6c4c12c740962d28a6c https://git.kernel.org/stable/c/3c20b5948f119ae61ee35ad8584d666020c91581 https://git.kernel.org/stable/c/78b0f2028f1043227a8eb0c41944027fc6a04596 https://git.kernel.org/stable/c/2e151b8ca31607d14fddc4ad0f14da0893e1a7c7 https://git.kernel.org/stable/c/e67471437ae9083fa73fa67eee1573fec1b7c8cf https://git.kernel.org/stable/c/7ffef5e5d5eeecd9687204a5ec2d863752aafb7e https://git.kernel.org/stable/c/856023ef032d824309abd5c747241dffa33aae8c https://git.kernel.org/stable/c/591efa494a1cf649f50a35def649c43ae •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53133 – drm/amd/display: Handle dml allocation failure to avoid crash
https://notcve.org/view.php?id=CVE-2024-53133
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Controlar el error de asignación de dml para evitar un bloqueo [Por qué] En el caso de que una asignación de dml falle por cualquier motivo, los contextos dml del estado actual ya no serían válidos. Luego, las llamadas posteriores a dc_state_copy_internal realizarían una copia superficial de la memoria no válida y, si se liberara el nuevo estado, se produciría una doble liberación. [Cómo] Restablecer los punteros dml en new_state a NULL y evitar un puntero no válido (seleccionado de el commit bcafdc61529a48f6f06355d78eb41b3aeda5296c) • https://git.kernel.org/stable/c/874ff59cde8fc525112dda26b501a1bac17dde9f https://git.kernel.org/stable/c/6825cb07b79ffeb1d90ffaa7a1227462cdca34ae •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53131 – nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
https://notcve.org/view.php?id=CVE-2024-53131
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Serie de parches "nilfs2: fix null-ptr-deref bugs on block tracepoints". Esta serie corrige errores de desreferencia de puntero nulo que ocurren al usar nilfs2 y dos puntos de seguimiento relacionados con bloques. Este parche (de 2): Se ha informado que al usar el punto de seguimiento "block:block_touch_buffer", touch_buffer() llamado desde __nilfs_get_folio_block() causa una desreferencia de puntero NULL o un error de protección general cuando KASAN está habilitado. • https://git.kernel.org/stable/c/5305cb830834549b9203ad4d009ad5483c5e293f https://git.kernel.org/stable/c/085556bf8c70e2629e02e79268dac3016a08b8bf https://git.kernel.org/stable/c/6438f3f42cda825f6f59b4e45ac3a1da28a6f2c9 https://git.kernel.org/stable/c/b017697a517f8779ada4e8ce1c2c75dbf60a2636 https://git.kernel.org/stable/c/19c71cdd77973f99a9adc3190130bc3aa7ae5423 https://git.kernel.org/stable/c/3b2a4fd9bbee77afdd3ed5a05a0c02b6cde8d3b9 https://git.kernel.org/stable/c/59b49ca67cca7b007a5afd3de0283c8008157665 https://git.kernel.org/stable/c/77e47f89d32c2d72eb33d0becbce7abe1 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53130 – nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint
https://notcve.org/view.php?id=CVE-2024-53130
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrección de null-ptr-deref en el punto de seguimiento block_dirty_buffer Al utilizar el punto de seguimiento "block:block_dirty_buffer", mark_buffer_dirty() puede provocar una desreferencia de puntero NULL o un fallo de protección general cuando KASAN está habilitado. Esto sucede porque, dado que el punto de seguimiento se agregó en mark_buffer_dirty(), hace referencia al miembro dev_t bh->b_bdev->bd_dev independientemente de si el cabezal del búfer tiene un puntero a una estructura block_device. En la implementación actual, nilfs_grab_buffer(), que toma un búfer para leer (o crear) un bloque de metadatos, incluidos los bloques de nodos de árbol b, no establece el dispositivo de bloque, sino que lo hace solo si el búfer no está en el estado "uptodate" para cada una de sus funciones de lectura de bloque de llamada. • https://git.kernel.org/stable/c/5305cb830834549b9203ad4d009ad5483c5e293f https://git.kernel.org/stable/c/7af3309c7a2ef26831a67125b11c34a7e01c1b2a https://git.kernel.org/stable/c/0ce59fb1c73fdd5b6028226aeb46259a0cdc0957 https://git.kernel.org/stable/c/0a5014ad37c77ac6a2c525137c00a0e1724f6020 https://git.kernel.org/stable/c/d904e4d845aafbcfd8a40c1df7d999f02f062be8 https://git.kernel.org/stable/c/86b19031dbc79abc378dfae357f6ea33ebeb0c95 https://git.kernel.org/stable/c/b0e4765740040c44039282057ecacd7435d1d2ba https://git.kernel.org/stable/c/ffc440a76a0f476a7e6ea838ec0dc8e99 •