CVSS: 8.5EPSS: 0%CPEs: 6EXPL: 0CVE-2025-37893 – LoongArch: BPF: Fix off-by-one error in build_prologue()
https://notcve.org/view.php?id=CVE-2025-37893
18 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Fix off-by-one error in build_prologue() Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue. There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, build_prologue(... • https://git.kernel.org/stable/c/5dc615520c4dfb358245680f1904bad61116648e •
CVSS: 7.1EPSS: 0%CPEs: 2EXPL: 0CVE-2025-37860 – sfc: fix NULL dereferences in ef100_process_design_param()
https://notcve.org/view.php?id=CVE-2025-37860
18 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: sfc: fix NULL dereferences in ef100_process_design_param() Since cited commit, ef100_probe_main() and hence also ef100_check_design_params() run before efx->net_dev is created; consequently, we cannot netif_set_tso_max_size() or _segs() at this point. Move those netif calls to ef100_probe_netdev(), and also replace netif_err within the design params code with pci_err. In the Linux kernel, the following vulnerability has been resolved: sfc: ... • https://git.kernel.org/stable/c/98ff4c7c8ac7f5339aac6114105395fea19f992e •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2025-37785 – ext4: fix OOB read when checking dotdot dir
https://notcve.org/view.php?id=CVE-2025-37785
18 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() ... • https://git.kernel.org/stable/c/ac27a0ec112a089f1a5102bc8dffc79c8c815571 •
CVSS: 3.3EPSS: 0%CPEs: 3EXPL: 0CVE-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 •
CVSS: 7.1EPSS: 0%CPEs: 9EXPL: 0CVE-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 •
CVSS: 5.6EPSS: 0%CPEs: 2EXPL: 0CVE-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 •
CVSS: 6.4EPSS: 0%CPEs: 9EXPL: 0CVE-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 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-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 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-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 •
CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2025-23133 – wifi: ath11k: update channel list in reg notifier instead reg worker
https://notcve.org/view.php?id=CVE-2025-23133
16 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: update channel list in reg notifier instead reg worker Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue reg_work. 2. cfg80211 handles new channel list during reg_work. 3. update cfg80211's handled channel list to firmware by ath11k_reg_update_chan_list(). But ath11k will immediately execute step 3 after reg_work is just queued... • https://git.kernel.org/stable/c/f45cb6b29cd36514e13f7519770873d8c0457008 •