CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-53144 – Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE
https://notcve.org/view.php?id=CVE-2024-53144
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE This aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4 ("Bluetooth: Always request for user confirmation for Just Works") always request user confirmation with confirm_hint set since the likes of bluetoothd have dedicated policy around JUST_WORKS method (e.g. main.conf:JustWorksRepairing). CVE: CVE-2024-8805 • https://git.kernel.org/stable/c/ba15a58b179ed76a7e887177f2b06de12c58ec8f https://git.kernel.org/stable/c/373d1dfcffc63c68184419264a7eaed422c7958e https://git.kernel.org/stable/c/bc96ff59b2f19e924d9e15e24cee19723d674b92 https://git.kernel.org/stable/c/6ab84785311dc4d0348e6bd4e1c491293b770b98 https://git.kernel.org/stable/c/778763287ded64dd5c022435d3e0e3182f148a64 https://git.kernel.org/stable/c/9a5fcacabde0fe11456f4a1e88072c01846cea25 https://git.kernel.org/stable/c/039da39a616103ec7ab8ac351bfb317854e5507c https://git.kernel.org/stable/c/d17c631ba04e960eb6f8728b10d585de2 •
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: 2EXPL: 0CVE-2024-53128 – sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers
https://notcve.org/view.php?id=CVE-2024-53128
In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/task_stack: corrección de object_is_on_stack() para punteros etiquetados de KASAN Cuando CONFIG_KASAN_SW_TAGS y CONFIG_KASAN_STACK están habilitados, la función object_is_on_stack() puede producir resultados incorrectos debido a la presencia de etiquetas en el puntero obj, mientras que el puntero de pila no tiene etiquetas. Esta discrepancia puede provocar una detección incorrecta de objetos de pila y, posteriormente, activar advertencias si CONFIG_DEBUG_OBJECTS también está habilitado. Ejemplo de la advertencia: ODEBUG: el objeto 3eff800082ea7bb0 NO está en la pila ffff800082ea0000, pero está anotado. ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 1 en lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Módulos vinculados: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.12.0-rc5 #4 Nombre del hardware: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 00000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9: 34d77febe173e800 x8: 34d77febe173e800 x7: 0000000000000001 x6: 00000000000000001 x5: feff800082ea74b8 x4: ffff800082870a90 x3: ffff80008018d3c4 x2: 0000000000000001 x1: ffff800082858810 x0: 0000000000000050 Seguimiento de llamadas: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ fin del seguimiento 000000000000000 ]--- ODEBUG: el objeto 3eff800082ea7bb0 NO está en la pila ffff800082ea0000, pero está anotado. ------------[ cortar aquí ]------------ • https://git.kernel.org/stable/c/fbfe23012cec509dfbe09852019c4e4bb84999d0 https://git.kernel.org/stable/c/fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58 •