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: 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-38607 – macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
https://notcve.org/view.php?id=CVE-2024-38607
In the Linux kernel, the following vulnerability has been resolved: macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: macintosh/via-macii: Corrección "ERROR: función de suspensión llamada desde un contexto no válido" El controlador ADB via-macii llama a request_irq() después de deshabilitar las interrupciones bruscas. Pero aquí no es necesario deshabilitar las interrupciones porque la interrupción del registro de desplazamiento de VIA se enmascaró durante la inicialización de VIA1. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/e4ff8bcfb2841fe4e17e5901578b632adb89036d https://git.kernel.org/stable/c/1e9c3f2caec548cfa7a65416ec4e6006e542f18e https://git.kernel.org/stable/c/280619bbdeac186fb320fab3d61122d2a085def8 https://git.kernel.org/stable/c/010d4cb19bb13f423e3e746b824f314a9bf3e9a9 https://git.kernel.org/stable/c/787fb79efc15b3b86442ecf079b8148f173376d7 https://git.kernel.org/stable/c/d43a8c7ec0841e0ff91a968770aeca83f0fd4c56 https://git.kernel.org/stable/c/5900a88e897e6deb1bdce09ee34167a81 •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-38600 – ALSA: Fix deadlocks with kctl removals at disconnection
https://notcve.org/view.php?id=CVE-2024-38600
In the Linux kernel, the following vulnerability has been resolved: ALSA: Fix deadlocks with kctl removals at disconnection In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now. • https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7 https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68 https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7 https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4 https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c https://access.redhat.com/security/cve/CVE-2024-38600 https://bugzilla.redhat.com/show_bug.cgi?id=2293365 • CWE-833: Deadlock •