CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26780 – af_unix: Fix task hung while purging oob_skb in GC.
https://notcve.org/view.php?id=CVE-2024-26780
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix task hung while purging oob_skb in GC. syzbot reported a task hung; at the same time, GC was looping infinitely in list_for_each_entry_safe() for OOB skb. [0] syzbot demonstrated that the list_for_each_entry_safe() was not actually safe in this case. A single skb could have references for multiple sockets. If we free such a skb in the list_for_each_entry_safe(), the current and next sockets could be unlinked in a single iteration. unix_notinflight() uses list_del_init() to unlink the socket, so the prefetched next socket forms a loop itself and list_for_each_entry_safe() never stops. Here, we must use while() and make sure we always fetch the first socket. [0]: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 5065 Comm: syz-executor236 Not tainted 6.8.0-rc3-syzkaller-00136-g1f719a2f3fa6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline] RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline] RIP: 0010:__sanitizer_cov_trace_pc+0xd/0x60 kernel/kcov.c:207 Code: cc cc cc cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 48 8b 14 25 40 c2 03 00 <65> 8b 05 b4 7c 78 7e a9 00 01 ff 00 48 8b 34 24 74 0f f6 c4 01 74 RSP: 0018:ffffc900033efa58 EFLAGS: 00000283 RAX: ffff88807b077800 RBX: ffff88807b077800 RCX: 1ffffffff27b1189 RDX: ffff88802a5a3b80 RSI: ffffffff8968488d RDI: ffff88807b077f70 RBP: ffffc900033efbb0 R08: 0000000000000001 R09: fffffbfff27a900c R10: ffffffff93d48067 R11: ffffffff8ae000eb R12: ffff88807b077800 R13: dffffc0000000000 R14: ffff88807b077e40 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564f4fc1e3a8 CR3: 000000000d57a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> unix_gc+0x563/0x13b0 net/unix/garbage.c:319 unix_release_sock+0xa93/0xf80 net/unix/af_unix.c:683 unix_release+0x91/0xf0 net/unix/af_unix.c:1064 __sock_release+0xb0/0x270 net/socket.c:659 sock_close+0x1c/0x30 net/socket.c:1421 __fput+0x270/0xb80 fs/file_table.c:376 task_work_run+0x14f/0x250 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xa8a/0x2ad0 kernel/exit.c:871 do_group_exit+0xd4/0x2a0 kernel/exit.c:1020 __do_sys_exit_group kernel/exit.c:1031 [inline] __se_sys_exit_group kernel/exit.c:1029 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1029 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd5/0x270 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f9d6cbdac09 Code: Unable to access opcode bytes at 0x7f9d6cbdabdf. RSP: 002b:00007fff5952feb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9d6cbdac09 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007f9d6cc552b0 R08: ffffffffffffffb8 R09: 0000000000000006 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f9d6cc552b0 R13: 0000000000000000 R14: 00007f9d6cc55d00 R15: 00007f9d6cbabe70 </TASK> En el kernel de Linux, se resolvió la siguiente vulnerabilidad: af_unix: se corrigió la tarea bloqueada al purgar oob_skb en GC. syzbot informó que se había colgado una tarea; al mismo tiempo, GC hacía un bucle infinito en list_for_each_entry_safe() para OOB skb. [0] syzbot demostró que list_for_each_entry_safe() en realidad no era seguro en este caso. Un solo skb podría tener referencias para múltiples sockets. • https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276 https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140 https://git.kernel.org/stable/c/2a3d40b4025fcfe51b04924979f1653993b17669 https://git.kernel.org/stable/c/69e0f04460f4037e01e29f0d9675544f62aafca3 https://git.kernel.org/stable/c/cb8890318dde26fc89c6ea67d6e9070ab50b6e91 https://git.kernel.org/stable/c/36f7371de977f805750748e80279be7e370df85c https://git.kernel.org/stable/c/25236c91b5ab4a26a56ba2e79b8060cf4 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26746 – dmaengine: idxd: Ensure safe user copy of completion record
https://notcve.org/view.php?id=CVE-2024-26746
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Ensure safe user copy of completion record If CONFIG_HARDENED_USERCOPY is enabled, copying completion record from event log cache to user triggers a kernel bug. [ 1987.159822] usercopy: Kernel memory exposure attempt detected from SLUB object 'dsa0' (offset 74, size 31)! [ 1987.170845] ------------[ cut here ]------------ [ 1987.176086] kernel BUG at mm/usercopy.c:102! [ 1987.180946] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 1987.186866] CPU: 17 PID: 528 Comm: kworker/17:1 Not tainted 6.8.0-rc2+ #5 [ 1987.194537] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 [ 1987.206405] Workqueue: wq0.0 idxd_evl_fault_work [idxd] [ 1987.212338] RIP: 0010:usercopy_abort+0x72/0x90 [ 1987.217381] Code: 58 65 9c 50 48 c7 c2 17 85 61 9c 57 48 c7 c7 98 fd 6b 9c 48 0f 44 d6 48 c7 c6 b3 08 62 9c 4c 89 d1 49 0f 44 f3 e8 1e 2e d5 ff <0f> 0b 49 c7 c1 9e 42 61 9c 4c 89 cf 4d 89 c8 eb a9 66 66 2e 0f 1f [ 1987.238505] RSP: 0018:ff62f5cf20607d60 EFLAGS: 00010246 [ 1987.244423] RAX: 000000000000005f RBX: 000000000000001f RCX: 0000000000000000 [ 1987.252480] RDX: 0000000000000000 RSI: ffffffff9c61429e RDI: 00000000ffffffff [ 1987.260538] RBP: ff62f5cf20607d78 R08: ff2a6a89ef3fffe8 R09: 00000000fffeffff [ 1987.268595] R10: ff2a6a89eed00000 R11: 0000000000000003 R12: ff2a66934849c89a [ 1987.276652] R13: 0000000000000001 R14: ff2a66934849c8b9 R15: ff2a66934849c899 [ 1987.284710] FS: 0000000000000000(0000) GS:ff2a66b22fe40000(0000) knlGS:0000000000000000 [ 1987.293850] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1987.300355] CR2: 00007fe291a37000 CR3: 000000010fbd4005 CR4: 0000000000f71ef0 [ 1987.308413] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1987.316470] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1987.324527] PKRU: 55555554 [ 1987.327622] Call Trace: [ 1987.330424] <TASK> [ 1987.332826] ? show_regs+0x6e/0x80 [ 1987.336703] ? die+0x3c/0xa0 [ 1987.339988] ? • https://git.kernel.org/stable/c/c2f156bf168fb42cd6ecd0a8e2204dbe542b8516 https://git.kernel.org/stable/c/5e3022ea42e490a36ec6f2cfa6fc603deb0bace4 https://git.kernel.org/stable/c/bb71e040323175e18c233a9afef32ba14fa64eb7 https://git.kernel.org/stable/c/d3ea125df37dc37972d581b74a5d3785c3f283ab •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26745 – powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV
https://notcve.org/view.php?id=CVE-2024-26745
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer exception: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48288244 XER: 00000008 CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP _find_next_zero_bit+0x24/0x110 LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable) iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130 iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0 mlx5_cmd_init+0xc0/0x760 [mlx5_core] mlx5_function_setup+0xf0/0x510 [mlx5_core] mlx5_init_one+0x84/0x210 [mlx5_core] probe_one+0x118/0x2c0 [mlx5_core] local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200 pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0 __pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core] do_one_initcall+0x60/0x300 do_init_module+0x7c/0x2b0 At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window "ibm,dma-window" is removed from the FDT and DDW added, for the device. Now, kexec hands over control to the kdump kernel. When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct mapped, there is no need to initialize IOMMU tables. iommu_table_setparms_lpar() only considers "ibm,dma-window" property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for SR-IOV, newly created IOMMU table is not initialized. • https://git.kernel.org/stable/c/b1fc44eaa9ba31e28c4125d6b9205a3582b47b5d https://git.kernel.org/stable/c/b9f08b2649dddd4eb0698cb428b173bb01dd2fc5 https://git.kernel.org/stable/c/58942f672c6d04b6a3cd7866cb459671df881538 https://git.kernel.org/stable/c/7eb95e0af5c9c2e6fad50356eaf32d216d0e7bc3 https://git.kernel.org/stable/c/d4d1e4b1513d975961de7bb4f75e450a92d65ebf https://git.kernel.org/stable/c/5da6d306f315344af1ca2eff4bd9b10b130f0c28 https://git.kernel.org/stable/c/09a3c1e46142199adcee372a420b024b4fc61051 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26779 – wifi: mac80211: fix race condition on enabling fast-xmit
https://notcve.org/view.php?id=CVE-2024-26779
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: corrige la condición de ejecución al habilitar fast-xmit fast-xmit solo debe habilitarse después de que el sta se haya cargado en el controlador; de lo contrario, podría terminar pasando el error sta aún cargada a través de llamadas drv_tx al controlador, lo que genera posibles fallas debido a datos drv_priv no inicializados. Agregue una estación faltante->comprobación cargada y vuelva a verificar la transmisión rápida después de insertar una estación. A vulnerability was found in the mac80211 driver in the Linux kernel. This issue could lead to potential crashes or memory corruption due to of a situation where the driver attempts to utilize data structures that haven't been fully initialized yet. • https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587 https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5 https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696 https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954 https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9 https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26778 – fbdev: savage: Error out if pixclock equals zero
https://notcve.org/view.php?id=CVE-2024-26778
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: savage: error si pixclock es igual a cero. El programa de espacio de usuario podría pasar cualquier valor al controlador a través de la interfaz ioctl(). • https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1 https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24 https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1 https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4 https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13 https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01 https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fd •