CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47576 – scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()
https://notcve.org/view.php?id=CVE-2021-47576
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select() In resp_mode_select() sanity check the block descriptor len to avoid UAF. BUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509 Read of size 1 at addr ffff888026670f50 by task scsicmd/15032 CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Call Trace: <TASK> dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306 resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509 schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483 scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537 scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1762 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:63 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52 do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50 entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_debug: Verifique la longitud del descriptor del bloque en resp_mode_select() En resp_mode_select(), verifique la longitud del descriptor del bloque para evitar UAF. ERROR: KASAN: use-after-free en resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509 Lectura del tamaño 1 en la dirección ffff888026670f50 por tarea scsicmd/15032 CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0 -01d0625 #15 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), seguimiento de llamadas del BIOS: dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107 print_address_description.constprop.9+0x28/0x160 mm/kasan/ report.c:257 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306 resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c: 2509 Schedule_resp+0x4af/0x1a10 controladores/scsi/scsi_debug.c:5483 scsi_debug_queuecommand+0x8c9/0x1e70 controladores/scsi/scsi_debug.c:7537 scsi_queue_rq+0x16b4/0x2d10 controladores/scsi/scsi_lib.c:1521 blk_mq_dispatch_rq_list+0xb9b/0x2700 bloque/ blk-mq.c:1640 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/ 0x150 cuadra/blk-mq. c:1762 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 ched.c:474 blk_execute_rq_nowait+0x16b /0x1c0 block/blk-exec.c:63 sg_common_write.isra.18+0xeb3/0x2000 controladores/scsi/sg.c:837 sg_new_write.isra.19+0x570/0x8c0 controladores/scsi/sg.c:775 sg_ioctl_common+0x14d6 /0x2710 controladores/scsi/sg.c:941 sg_ioctl+0xa2/0x180 controladores/scsi/sg.c:1166 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52 do_syscall_64+0x3a/0x80 arch/x86/entry/common. c:50 entrada_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113 • https://git.kernel.org/stable/c/adcecd50da6cab7b4957cba0606771dcc846c5a9 https://git.kernel.org/stable/c/90491283b4064220682e4b0687d07b05df01e3bf https://git.kernel.org/stable/c/04181973c38f3d6a353f9246dcf7fee08024fd9e https://git.kernel.org/stable/c/b847ecff850719c46c95acd25a0d555dfd16e10d https://git.kernel.org/stable/c/a9078e791426c2cbbdf28a320c3670f6e0a611e6 https://git.kernel.org/stable/c/dfc3fff63793c571147930b13c0f8c689c4281ac https://git.kernel.org/stable/c/e0a2c28da11e2c2b963fc01d50acbf03045ac732 •
CVSS: 5.3EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38618 – ALSA: timer: Set lower bound of start tick time
https://notcve.org/view.php?id=CVE-2024-38618
In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Set lower bound of start tick time Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: temporizador: establece el límite inferior del tiempo de inicio. Actualmente, el temporizador ALSA no tiene el límite inferior del tiempo de inicio y permite un tamaño muy pequeño, por ejemplo, 1 tic. con resolución de 1ns para hrtimer. Tal situación puede provocar una parada inesperada de la RCU, donde la devolución de llamada pone en cola repetidamente la actualización caducada, según lo informado por fuzzer. • https://git.kernel.org/stable/c/68396c825c43664b20a3a1ba546844deb2b4e48f https://git.kernel.org/stable/c/74bfb8d90f2601718ae203faf45a196844c01fa1 https://git.kernel.org/stable/c/bdd0aa055b8ec7e24bbc19513f3231958741d0ab https://git.kernel.org/stable/c/83f0ba8592b9e258fd80ac6486510ab1dcd7ad6e https://git.kernel.org/stable/c/ceab795a67dd28dd942d0d8bba648c6c0f7a044b https://git.kernel.org/stable/c/2c95241ac5fc90c929d6c0c023e84bf0d30e84c3 https://git.kernel.org/stable/c/abb1ad69d98cf1ff25bb14fff0e7c3f66239e1cd https://git.kernel.org/stable/c/4a63bd179fa8d3fcc44a0d9d71d941ddd • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
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 •