CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47578 – scsi: scsi_debug: Don't call kcalloc() if size arg is zero
https://notcve.org/view.php?id=CVE-2021-47578
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Don't call kcalloc() if size arg is zero If the size arg to kcalloc() is zero, it returns ZERO_SIZE_PTR. Because of that, for a following NULL pointer check to work on the returned pointer, kcalloc() must not be called with the size arg equal to zero. Return early without error before the kcalloc() call if size arg is zero. BUG: KASAN: null-ptr-deref in memcpy include/linux/fortify-string.h:191 [inline] BUG: KASAN: null-ptr-deref in sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974 Write of size 4 at addr 0000000000000010 by task syz-executor.1/22789 CPU: 1 PID: 22789 Comm: syz-executor.1 Not tainted 5.15.0-syzk #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 __kasan_report mm/kasan/report.c:446 [inline] kasan_report.cold.14+0x112/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189 memcpy+0x3b/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:191 [inline] sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974 do_dout_fetch drivers/scsi/scsi_debug.c:2954 [inline] do_dout_fetch drivers/scsi/scsi_debug.c:2946 [inline] resp_verify+0x49e/0x930 drivers/scsi/scsi_debug.c:4276 schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533 scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline] scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __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:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 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:62 blk_execute_rq+0xdb/0x360 block/blk-exec.c:102 sg_scsi_ioctl drivers/scsi/scsi_ioctl.c:621 [inline] scsi_ioctl+0x8bb/0x15c0 drivers/scsi/scsi_ioctl.c:930 sg_ioctl_common+0x172d/0x2710 drivers/scsi/sg.c:1112 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: scsi_debug: no llamar a kcalloc() si el tamaño arg es cero. Si el tamaño arg de kcalloc() es cero, devuelve ZERO_SIZE_PTR. Por eso, para que una siguiente verificación de puntero NULL funcione en el puntero devuelto, no se debe llamar a kcalloc() con el tamaño arg igual a cero. • https://git.kernel.org/stable/c/aa1f912712a109b6306746133de7e5343f016b26 https://git.kernel.org/stable/c/47d11d35203b0aa13533634e270fe2c3610e531b https://git.kernel.org/stable/c/3344b58b53a76199dae48faa396e9fc37bf86992 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47577 – io-wq: check for wq exit after adding new worker task_work
https://notcve.org/view.php?id=CVE-2021-47577
In the Linux kernel, the following vulnerability has been resolved: io-wq: check for wq exit after adding new worker task_work We check IO_WQ_BIT_EXIT before attempting to create a new worker, and wq exit cancels pending work if we have any. But it's possible to have a race between the two, where creation checks exit finding it not set, but we're in the process of exiting. The exit side will cancel pending creation task_work, but there's a gap where we add task_work after we've canceled existing creations at exit time. Fix this by checking the EXIT bit post adding the creation task_work. If it's set, run the same cancelation that exit does. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: io-wq: comprueba la salida de wq después de agregar un nuevo trabajador task_work Comprobamos IO_WQ_BIT_EXIT antes de intentar crear un nuevo trabajador, y wq exit cancela el trabajo pendiente si tenemos alguno. Pero es posible tener una carrera entre los dos, donde las comprobaciones de creación salen y descubren que no está configurado, pero estamos en el proceso de salir. • https://git.kernel.org/stable/c/4b4e5bbf9386d4ec21d91c0cb0fd60b9bba778ec https://git.kernel.org/stable/c/71a85387546e50b1a37b0fa45dadcae3bfb35cf6 •
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: -EPSS: 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 •
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 •