
CVE-2021-47671 – can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path
https://notcve.org/view.php?id=CVE-2021-47671
17 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path In es58x_rx_err_msg(), if can->do_set_mode() fails, the function directly returns without calling netif_rx(skb). This means that the skb previously allocated by alloc_can_err_skb() is not freed. In other terms, this is a memory leak. This patch simply removes the return statement in the error branch and let the function continue. Issue was found with GCC -fanalyzer, please f... • https://git.kernel.org/stable/c/8537257874e949a59c834cecfd5a063e11b64b0b • CWE-401: Missing Release of Memory after Effective Lifetime •

CVE-2021-47670 – can: peak_usb: fix use after free bugs
https://notcve.org/view.php?id=CVE-2021-47670
17 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: fix use after free bugs After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the peak_usb_netif_rx_ni(). Reordering the lines solves the issue. • https://git.kernel.org/stable/c/0a25e1f4f18566b750ebd3ae995af64e23111e63 • CWE-416: Use After Free •

CVE-2021-47669 – can: vxcan: vxcan_xmit: fix use after free bug
https://notcve.org/view.php?id=CVE-2021-47669
17 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: can: vxcan: vxcan_xmit: fix use after free bug After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the canfd_frame cfd which aliases skb memory is accessed after the netif_rx_ni(). • https://git.kernel.org/stable/c/a8f820a380a2a06fc4fe1a54159067958f800929 • CWE-416: Use After Free •

CVE-2021-47668 – can: dev: can_restart: fix use after free bug
https://notcve.org/view.php?id=CVE-2021-47668
17 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: can: dev: can_restart: fix use after free bug After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the netif_rx_ni() in: stats->rx_bytes += cf->len; Reordering the lines solves the issue. • https://git.kernel.org/stable/c/39549eef3587f1c1e8c65c88a2400d10fd30ea17 • CWE-416: Use After Free •

CVE-2020-36789 – can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context
https://notcve.org/view.php?id=CVE-2020-36789
17 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but not always, the case), the 'WARN_ON(in_irq)' in net/core/skbuff.c#skb_release_head_state() might be triggered, under network congestion circumstances, together with the potential risk of a NULL pointer dereference. The root cause of this issue is the call to kfree_skb() instead of dev_... • https://git.kernel.org/stable/c/39549eef3587f1c1e8c65c88a2400d10fd30ea17 •

CVE-2025-23138 – watch_queue: fix pipe accounting mismatch
https://notcve.org/view.php?id=CVE-2025-23138
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: watch_queue: fix pipe accounting mismatch Currently, watch_queue_set_size() modifies the pipe buffers charged to user->pipe_bufs without updating the pipe->nr_accounted on the pipe itself, due to the if (!pipe_has_watch_queue()) test in pipe_resize_ring(). This means that when the pipe is ultimately freed, we decrement user->pipe_bufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn c... • https://git.kernel.org/stable/c/162ae0e78bdabf84ef10c1293c4ed7865cb7d3c8 •

CVE-2025-23137 – cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update
https://notcve.org/view.php?id=CVE-2025-23137
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update. • https://git.kernel.org/stable/c/e8f555daacd3377bf691fdda2490c0b164e00085 •

CVE-2025-23136 – thermal: int340x: Add NULL check for adev
https://notcve.org/view.php?id=CVE-2025-23136
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: thermal: int340x: Add NULL check for adev Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL"). Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402_thermal_probe(). Note, under the same directory, int3400_thermal_probe() has such a check. [ rjw: Subject edit, added Fix... • https://git.kernel.org/stable/c/77e337c6e23e3b9d22e09ffec202a80f755a54c2 •

CVE-2025-23135 – RISC-V: KVM: Teardown riscv specific bits after kvm_exit
https://notcve.org/view.php?id=CVE-2025-23135
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Teardown riscv specific bits after kvm_exit During a module removal, kvm_exit invokes arch specific disable call which disables AIA. However, we invoke aia_exit before kvm_exit resulting in the following warning. KVM kernel module can't be inserted afterwards due to inconsistent state of IRQ. [25469.031389] percpu IRQ 31 still enabled on CPU0! [25469.031732] WARNING: CPU: 3 PID: 943 at kernel/irq/manage.c:2476 __free_percpu_irq... • https://git.kernel.org/stable/c/54e43320c2ba0c70258a3aea690da38c6ea3293c •

CVE-2025-23134 – ALSA: timer: Don't take register_mutex with copy_from/to_user()
https://notcve.org/view.php?id=CVE-2025-23134
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Don't take register_mutex with copy_from/to_user() The infamous mmap_lock taken in copy_from/to_user() can be often problematic when it's called inside another mutex, as they might lead to deadlocks. In the case of ALSA timer code, the bad pattern is with guard(mutex)(®ister_mutex) that covers copy_from/to_user() -- which was mistakenly introduced at converting to guard(), and it had been carefully worked around in the past.... • https://git.kernel.org/stable/c/3923de04c81733b30b8ed667569632272fdfed9a •