CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35990 – dma: xilinx_dpdma: Fix locking
https://notcve.org/view.php?id=CVE-2024-35990
In the Linux kernel, the following vulnerability has been resolved: dma: xilinx_dpdma: Fix locking There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like [ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: events_unbound deferred_probe_work_func [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50/0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] do_take_over_console+0x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered+0x2d0/0x34c [ 31.082663] register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] really_probe+0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dma: xilinx_dpdma: bloqueo de reparación Hay varios lugares donde chan->lock o chan->vchan.lock no se mantuvieron. Agregue el bloqueo apropiado. Esto corrige advertencias de bloqueo como [31.077578] ------------[ cortar aquí ]------------ [ 31.077831] ADVERTENCIA: CPU: 2 PID: 40 en los controladores/ dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Módulos vinculados en: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 No contaminado 6.6.20+ #98 [ 31.07 8102] Nombre del hardware : xlnx,zynqmp (DT) [31.078169] Cola de trabajo: events_unbound deferred_probe_work_func [31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [31.078377] pc: xilinx_dpdma_chan_queue _transfer+0x274/0x5e0 [ 31.078473 ] lr: xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [31.078550] sp: ffffffc083bb2e10 [31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: 65a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 00000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9: 0001ffc082aa3def [31.079824 ] x8: 0001ffc082aa3dec x7: 0000000000000000 x6: 0000000000000516 [31.079982] x5: ffffffc7f8d43000 x4: ffffff88003c9c40 x3: ffffffffffffffff [ 31.0 80147] x2: ffffffc7f8d43000 x1: 00000000000000c0 x0: 0000000000000000 [31.080307] Rastreo de llamadas: [31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [31. 080518 ] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit +0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50 /0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered +0x2d0/0x34c [ 31.082663] Register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 3 1.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0 /0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] +0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207 device_initial_probe+0x14/0 x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451 ] Process_one_work+0x3ac/0x988 [31.084643] work_thread+0x398/0x694 [31.084752] kthread+0x1bc/0x1c0 [31.084848] ret_from_fork+0x10/0x20 [31.084932] sello de evento irq: 9 [31.084970] hardirqs habilitado por última vez en (64548): [ ] _raw_spin_unlock_irqrestore+0x80/0x90 [31.085157] ---truncado--- • https://git.kernel.org/stable/c/7cbb0c63de3fc218fd06ecfedb477772a4d12f76 https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076 https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11 https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557 https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-667: Improper Locking •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35988 – riscv: Fix TASK_SIZE on 64-bit NOMMU
https://notcve.org/view.php?id=CVE-2024-35988
In the Linux kernel, the following vulnerability has been resolved: riscv: Fix TASK_SIZE on 64-bit NOMMU On NOMMU, userspace memory can come from anywhere in physical RAM. The current definition of TASK_SIZE is wrong if any RAM exists above 4G, causing spurious failures in the userspace access routines. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: corrige TASK_SIZE en NOMMU de 64 bits En NOMMU, la memoria del espacio de usuario puede provenir de cualquier lugar de la RAM física. La definición actual de TASK_SIZE es incorrecta si existe RAM por encima de 4G, lo que provoca fallos falsos en las rutinas de acceso al espacio de usuario. • https://git.kernel.org/stable/c/6bd33e1ece528f67646db33bf97406b747dafda0 https://git.kernel.org/stable/c/04bf2e5f95c1a52e28a7567a507f926efe31c3b6 https://git.kernel.org/stable/c/52e8a42b11078d2aad4b9ba96503d77c7299168b https://git.kernel.org/stable/c/4201b8c8f2c32af321fb50867e68ac6c1cbed4be https://git.kernel.org/stable/c/a0f0dbbb1bc49fa0de18e92c36492ff6d804cdaa https://git.kernel.org/stable/c/efdcfa554b6eb228943ef1dd4d023c606be647d2 https://git.kernel.org/stable/c/6065e736f82c817c9a597a31ee67f0ce4628e948 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35984 – i2c: smbus: fix NULL function pointer dereference
https://notcve.org/view.php?id=CVE-2024-35984
In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: smbus: corrige la desreferencia del puntero de función NULL. Baruch informó de un OOPS al usar el controlador de designware como destino únicamente. Los modos de solo objetivo rompen el supuesto de que siempre hay una función de transferencia disponible. • https://git.kernel.org/stable/c/63453b59e41173241c4efe9335815f6432fa8586 https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23 https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620 https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85 https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d04 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35983 – bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS
https://notcve.org/view.php?id=CVE-2024-35983
In the Linux kernel, the following vulnerability has been resolved: bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS bits_per() rounds up to the next power of two when passed a power of two. This causes crashes on some machines and configurations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: límites: utilice el número correcto de bits para potencia de dos CONFIG_NR_CPUS bits_per() redondea a la siguiente potencia de dos cuando se pasa una potencia de dos. Esto provoca fallos en algunas máquinas y configuraciones. • https://git.kernel.org/stable/c/d6077e0d38b4953c863d0db4a5b3f41d21e0d546 https://git.kernel.org/stable/c/83a2275f9d3230c761014b1467888b1ef469be74 https://git.kernel.org/stable/c/d2a7a81088c6abe778b0a93a7eeb79487a943818 https://git.kernel.org/stable/c/428ca0000f0abd5c99354c52a36becf2b815ca21 https://git.kernel.org/stable/c/b46c822f8b555b9513df44047b0e72c06720df62 https://git.kernel.org/stable/c/cf778fff03be1ee88c49b72959650147573c3301 https://git.kernel.org/stable/c/b2e1b090a590d41abe647eadb6bf2a5dc47b63ab https://git.kernel.org/stable/c/d34a516f2635090d36a306f84573e8de3 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-35982 – batman-adv: Avoid infinite loop trying to resize local TT
https://notcve.org/view.php?id=CVE-2024-35982
In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. • https://git.kernel.org/stable/c/a19d3d85e1b854e4a483a55d740a42458085560d https://git.kernel.org/stable/c/5eaeaa72113865661568002bb57d611492451d3e https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924 https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6 https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259 https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede5 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •