CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38613 – m68k: Fix spinlock race in kernel thread creation
https://notcve.org/view.php?id=CVE-2024-38613
In the Linux kernel, the following vulnerability has been resolved: m68k: Fix spinlock race in kernel thread creation Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch. This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register. The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()). A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck. As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit. Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). • https://git.kernel.org/stable/c/533e6903bea0440816a0f517b0845ccea4cc7917 https://git.kernel.org/stable/c/2a8d1d95302c7d52c6ac8fa5cb4a6948ae0d3a14 https://git.kernel.org/stable/c/5213cc01d0464c011fdc09f318705603ed3a746b https://git.kernel.org/stable/c/4eeffecc8e3cce25bb559502c2fd94a948bcde82 https://git.kernel.org/stable/c/77b2b67a0f8bce260c53907e5749d61466d90c87 https://git.kernel.org/stable/c/0d9ae1253535f6e85a016e09c25ecbe6f7f59ef0 https://git.kernel.org/stable/c/f3baf0f4f92af32943ebf27b960e0552c6c082fd https://git.kernel.org/stable/c/f1d4274a84c069be0f6098ab10c3443fc •
CVSS: 9.8EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38612 – ipv6: sr: fix invalid unregister error path
https://notcve.org/view.php?id=CVE-2024-38612
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: sr: corrige la ruta de error de cancelación de registro no válida La ruta de error de seg6_init() es incorrecta en caso de que CONFIG_IPV6_SEG6_LWTUNNEL no esté definido. En ese caso, si seg6_hmac_init() falla, no se llama a genl_unregister_family(). Este problema existe desde que el commit 46738b1317e1 ("ipv6: sr: agregar opción para controlar la compatibilidad con lwtunnel") y el commit 5559cea2d5aa ("ipv6: sr: corregir posible use-after-free y null-ptr-deref") reemplazó unregister_pernet_subsys() con genl_unregister_family() en esta ruta de error. • https://git.kernel.org/stable/c/46738b1317e169b281ad74690276916e24d1be6d https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7 https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4 https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01 https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925 https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66 https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c • CWE-416: Use After Free CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38611 – media: i2c: et8ek8: Don't strip remove function when driver is builtin
https://notcve.org/view.php?id=CVE-2024-38611
In the Linux kernel, the following vulnerability has been resolved: media: i2c: et8ek8: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: i2c: et8ek8: No eliminar la función de eliminación cuando el controlador está integrado. El uso de __exit para la función de eliminación hace que la devolución de llamada de eliminación se descarte con CONFIG_VIDEO_ET8EK8=y. • https://git.kernel.org/stable/c/c5254e72b8edc2ca0a98703e92e8c34959343d2c https://git.kernel.org/stable/c/c1a3803e5bb91c13e9ad582003e4288f67f06cd9 https://git.kernel.org/stable/c/43fff07e4b1956d0e5cf23717507e438278ea3d9 https://git.kernel.org/stable/c/904db2ba44ae60641b6378c5013254d09acf5e80 https://git.kernel.org/stable/c/545b215736c5c4b354e182d99c578a472ac9bfce •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38610 – drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()
https://notcve.org/view.php?id=CVE-2024-38610
In the Linux kernel, the following vulnerability has been resolved: drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes". Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks. Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VM_PAT that ends up using follow_pte(). This patch (of 3): We currently miss handling various cases, resulting in a dangerous follow_pte() (previously follow_pfn()) usage. (1) We're not checking PTE write permissions. Maybe we should simply always require pte_write() like we do for pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for ACRN_MEM_ACCESS_WRITE for now. (2) We're not rejecting refcounted pages. As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. • https://git.kernel.org/stable/c/b9c43aa0b18da5619aac347d54cb67fe30d1f884 https://git.kernel.org/stable/c/8a6e85f75a83d16a71077e41f2720c691f432002 https://git.kernel.org/stable/c/149d5fb7e0124c3763e92edd1fde19417f4d2d09 https://git.kernel.org/stable/c/02098ac42b7ff055ec72cd083ee1eb0a23481a19 https://git.kernel.org/stable/c/5c6705aa47b5b78d7ad36fea832bb69caa5bf49a https://git.kernel.org/stable/c/afeb0e69627695f759fc73c39c1640dbf8649b32 https://git.kernel.org/stable/c/e873f36ec890bece26ecce850e969917bceebbb6 https://git.kernel.org/stable/c/4c4ba3cf3a15ccfbaf787d0296fa42cdb •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-38608 – net/mlx5e: Fix netif state handling
https://notcve.org/view.php?id=CVE-2024-38608
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix netif state handling mlx5e_suspend cleans resources only if netif_device_present() returns true. However, mlx5e_resume changes the state of netif, via mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED. In the below case, the above leads to NULL-ptr Oops[1] and memory leaks: mlx5e_probe _mlx5e_resume mlx5e_attach_netdev mlx5e_nic_enable <-- netdev not reg, not calling netif_device_attach() register_netdev <-- failed for some reason. ERROR_FLOW: _mlx5e_suspend <-- netif_device_present return false, resources aren't freed :( Hence, clean resources in this case as well. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at0xffffffffffffffd6. RSP: 0018:ffff888178aaf758 EFLAGS: 00010246 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x14c/0x3c0 ? exc_page_fault+0x75/0x140 ? • https://git.kernel.org/stable/c/2c3b5beec46ab0d77c94828eb15170b333ae769a https://git.kernel.org/stable/c/f7e6cfb864a53af71c5cc904f1cc22215d68f5c6 https://git.kernel.org/stable/c/3d5918477f94e4c2f064567875c475468e264644 https://access.redhat.com/security/cve/CVE-2024-38608 https://bugzilla.redhat.com/show_bug.cgi?id=2293356 • CWE-476: NULL Pointer Dereference •