CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38664 – drm: zynqmp_dpsub: Always register bridge
https://notcve.org/view.php?id=CVE-2024-38664
In the Linux kernel, the following vulnerability has been resolved: drm: zynqmp_dpsub: Always register bridge We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning: [ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]--- (cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae) En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm: zynqmp_dpsub: Registrar siempre puente Siempre debemos registrar el puente DRM, ya que zynqmp_dp_hpd_work_func llama a drm_bridge_hpd_notify, que a su vez espera que hpd_mutex se inicialice. Hacemos esto antes de zynqmp_dpsub_drm_init ya que llama a drm_bridge_attach. • https://git.kernel.org/stable/c/eb2d64bfcc174919a921295a5327b99a3b8f4166 https://git.kernel.org/stable/c/6ead3eccf67bc8318b1ce95ed879b2cc05b4fce9 https://git.kernel.org/stable/c/603661357056b5e5ba6d86f505fbc936eff396ba https://git.kernel.org/stable/c/be3f3042391d061cfca2bd22630e0d101acea5fc • CWE-667: Improper Locking •
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 •