Page 218 of 2681 results (0.010 seconds)

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

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: 0

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: 0

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: 0

01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree for clk_summary Similar to the previous commit, we should make sure that all devices are runtime resumed before printing the clk_summary through debugfs. Failure to do so would result in a deadlock if the thread is resuming a device to print clk state and that device is also runtime resuming in another thread, e.g the screen is turning on and the display driver is starting up. We remove the calls to c... • https://git.kernel.org/stable/c/1bb294a7981c737e2311a78e4086635ac0220ace •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

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: 0

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: 0

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: 0

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: 7.2EPSS: 0%CPEs: 4EXPL: 0

01 May 2024 — In the Linux kernel, the following vulnerability has been resolved: serial: core: Clearing the circular buffer before NULLifying it The circular buffer is NULLified in uart_tty_port_shutdown() under the spin lock. However, the PM or other timer based callbacks may still trigger after this event without knowning that buffer pointer is not valid. Since the serial code is a bit inconsistent in checking the buffer state (some rely on the head-tail positions, some on the buffer pointer), it's better to have both... • https://git.kernel.org/stable/c/434beb66368d4fb4d3119c2116b9398500adbf47 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

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 •