CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-27010 – net/sched: Fix mirred deadlock on device recursion
https://notcve.org/view.php?id=CVE-2024-27010
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix mirred deadlock on device recursion When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below. [..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.8... • https://git.kernel.org/stable/c/e578d9c02587d57bfa7b560767c698a668a468c6 •
CVSS: 7.2EPSS: 0%CPEs: 5EXPL: 0CVE-2024-27009 – s390/cio: fix race condition during online processing
https://notcve.org/view.php?id=CVE-2024-27009
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: s390/cio: fix race condition during online processing A race condition exists in ccw_device_set_online() that can cause the online process to fail, leaving the affected device in an inconsistent state. As a result, subsequent attempts to set that device online fail with return code ENODEV. The problem occurs when a path verification request arrives after a wait for final device state completed, but before the result state is evaluated. Fix ... • https://git.kernel.org/stable/c/2297791c92d04a154ad29ba5a073f9f627982110 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27008 – drm: nv04: Fix out of bounds access
https://notcve.org/view.php?id=CVE-2024-27008
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: drm: nv04: Fix out of bounds access When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value. Utilize macros from 'enum nouveau_or' in calls instead of hardcoding. Found by Linux Verification Center (li... • https://git.kernel.org/stable/c/2e5702aff39532662198459726c624d5eadbdd78 •
CVSS: 7.2EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27005 – interconnect: Don't access req_list while it's being manipulated
https://notcve.org/view.php?id=CVE-2024-27005
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: interconnect: Don't access req_list while it's being manipulated The icc_lock mutex was split into separate icc_lock and icc_bw_lock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to icc_node::req_list. The icc_set_bw() function will eventually iterate over req_list while only holding icc_bw_lock, but req_list can be modified while only holding icc_lock. This causes races between icc_set_bw(), of_icc_... • https://git.kernel.org/stable/c/af42269c3523492d71ebbe11fefae2653e9cdc78 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-27004 – clk: Get runtime PM before walking tree during disable_unused
https://notcve.org/view.php?id=CVE-2024-27004
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree during disable_unused Doug reported [1] the following hung task: INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c... • https://git.kernel.org/stable/c/9a34b45397e5a389e25a0c5d39983300d040e5e2 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27002 – clk: mediatek: Do a runtime PM get on controllers during probe
https://notcve.org/view.php?id=CVE-2024-27002
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: Do a runtime PM get on controllers during probe mt8183-mfgcfg has a mutual dependency with genpd during the probing stage, which leads to a deadlock in the following call stack: CPU0: genpd_lock --> clk_prepare_lock genpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock() CPU1: clk_prepare_lock --> genpd_lock clk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get... • https://git.kernel.org/stable/c/acddfc2c261b3653ab1c1b567a427299bac20d31 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27001 – comedi: vmk80xx: fix incomplete endpoint checking
https://notcve.org/view.php?id=CVE-2024-27001
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: comedi: vmk80xx: fix incomplete endpoint checking While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xx_find_usb_endpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panic_on_warn' set on ... • https://git.kernel.org/stable/c/49253d542cc0f5f771dc254d248162a2a666649d •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-27000 – serial: mxs-auart: add spinlock around changing cts state
https://notcve.org/view.php?id=CVE-2024-27000
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: serial: mxs-auart: add spinlock around changing cts state The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board. [ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec [ 85.134694] Modules linke... • https://git.kernel.org/stable/c/4d90bb147ef6b91f529a21b498ff2b5fdc6785b4 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26999 – serial/pmac_zilog: Remove flawed mitigation for rx irq flood
https://notcve.org/view.php?id=CVE-2024-26999
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: serial/pmac_zilog: Remove flawed mitigation for rx irq flood The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console: ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0 That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock alread... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26997 – usb: dwc2: host: Fix dereference issue in DDMA completion flow.
https://notcve.org/view.php?id=CVE-2024-26997
01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: host: Fix dereference issue in DDMA completion flow. Fixed variable dereference issue in DDMA completion flow. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc2: host: solucionó el problema de desreferencia en el flujo de finalización de DDMA. Se solucionó el problema de desreferencia variable en el flujo de finalización de DDMA. • https://git.kernel.org/stable/c/dca1dc1e99e09e7b8eaccb55d6aecb87d9cb8ecd •