CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38663 – blk-cgroup: fix list corruption from resetting io stat
https://notcve.org/view.php?id=CVE-2024-38663
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from resetting io stat Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part. • https://git.kernel.org/stable/c/3b8cc6298724021da845f2f9fd7dd4b6829a6817 https://git.kernel.org/stable/c/d4a60298ac34f027a09f8f893fdbd9e06279bb24 https://git.kernel.org/stable/c/89bb36c72e1951843f9e04dc84412e31fcc849a9 https://git.kernel.org/stable/c/6da6680632792709cecf2b006f2fe3ca7857e791 https://access.redhat.com/security/cve/CVE-2024-38663 https://bugzilla.redhat.com/show_bug.cgi?id=2294225 • CWE-665: Improper Initialization •
CVSS: 8.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38384 – blk-cgroup: fix list corruption from reorder of WRITE ->lqueued
https://notcve.org/view.php?id=CVE-2024-38384
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from reorder of WRITE ->lqueued __blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start is being executed. If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one stat instance being added in blk_cgroup_bio_start(), then the local list in __blkcg_rstat_flush() could be corrupted. Fix the issue by adding one barrier. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-cgroup: corrupción de la lista de arreglos debido al reordenamiento de WRITE ->lqueued __blkcg_rstat_flush() se puede ejecutar en cualquier momento, especialmente cuando se está ejecutando blk_cgroup_bio_start. Si la ESCRITURA de `->lqueued` se reordena con la READ de 'bisc->lnode.next' en el bucle de __blkcg_rstat_flush(), se puede asignar `next_bisc` agregando una instancia de estadística en blk_cgroup_bio_start(), entonces el La lista local en __blkcg_rstat_flush() podría estar dañada. Solucione el problema agregando una barrera. • https://git.kernel.org/stable/c/3b8cc6298724021da845f2f9fd7dd4b6829a6817 https://git.kernel.org/stable/c/714e59b5456e4d6e4295a9968c564abe193f461c https://git.kernel.org/stable/c/785298ab6b802afa75089239266b6bbea590809c https://git.kernel.org/stable/c/d0aac2363549e12cc79b8e285f13d5a9f42fd08e https://access.redhat.com/security/cve/CVE-2024-38384 https://bugzilla.redhat.com/show_bug.cgi?id=2294220 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') CWE-400: Uncontrolled Resource Consumption •
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 •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2024-39277 – dma-mapping: benchmark: handle NUMA_NO_NODE correctly
https://notcve.org/view.php?id=CVE-2024-39277
In the Linux kernel, the following vulnerability has been resolved: dma-mapping: benchmark: handle NUMA_NO_NODE correctly cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark() resulting in the following sanitizer report: UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan.c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) 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) Use cpumask_of_node() in place when binding a kernel thread to a cpuset of a particular node. Note that the provided node id is checked inside map_benchmark_ioctl(). It's just a NUMA_NO_NODE case which is not handled properly later. Found by Linux Verification Center (linuxtesting.org). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-mapping: benchmark: maneja NUMA_NO_NODE correctamente. Se puede llamar a cpumask_of_node() para NUMA_NO_NODE dentro de do_map_benchmark(), lo que genera el siguiente informe de sanitización: UBSAN: array-index-out-of- Los límites en ./arch/x86/include/asm/topology.h:72:28 el índice -1 están fuera del rango para el tipo 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma No contaminado 6.9. 0-rc6 #29 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan. c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [en línea] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) 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) Utilice cpumask_of_node( ) en su lugar al vincular un subproceso del kernel a un cpuset de un nodo en particular. • https://git.kernel.org/stable/c/65789daa8087e125927230ccb7e1eab13999b0cf https://git.kernel.org/stable/c/b41b0018e8ca06e985e87220a618ec633988fd13 https://git.kernel.org/stable/c/8e1ba9df9a35e8dc64f657a64e523c79ba01e464 https://git.kernel.org/stable/c/5a91116b003175302f2e6ad94b76fb9b5a141a41 https://git.kernel.org/stable/c/50ee21bfc005e69f183d6b4b454e33f0c2571e1f https://git.kernel.org/stable/c/e64746e74f717961250a155e14c156616fcd981f • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38780 – dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
https://notcve.org/view.php?id=CVE-2024-38780
In the Linux kernel, the following vulnerability has been resolved: dma-buf/sw-sync: don't enable IRQ from sync_print_obj() Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf/sw-sync: no habilitar IRQ desde sync_print_obj() Desde el commit a6aa8fca4d79 ("dma-buf/sw-sync: reducir irqsave/irqrestore desde el contexto conocido" ) por error reemplazó spin_unlock_irqrestore() con spin_unlock_irq() tanto para sync_debugfs_show() como para sync_print_obj() a pesar de que sync_print_obj() se llama desde sync_debugfs_show(), lockdep se queja de una advertencia de estado de bloqueo inconsistente. Utilice spin_{lock,unlock}() simple para sync_print_obj(), ya que sync_debugfs_show() ya está usando spin_{lock,unlock}_irq(). • https://git.kernel.org/stable/c/a6aa8fca4d792c72947e341d7842d2f700534335 https://git.kernel.org/stable/c/f14ad42b8743897d140808467ed4ae3ce93bd0a5 https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8 https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878 https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc54396 • CWE-667: Improper Locking •