CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2025-22015 – mm/migrate: fix shmem xarray update during migration
https://notcve.org/view.php?id=CVE-2025-22015
08 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: mm/migrate: fix shmem xarray update during migration A shmem folio can be either in page cache or in swap cache, but not at the same time. Namely, once it is in swap cache, folio->mapping should be NULL, and the folio is no longer in a shmem mapping. In __folio_migrate_mapping(), to determine the number of xarray entries to update, folio_test_swapbacked() is used, but that conflates shmem in page cache case and shmem in swap cache case. It ... • https://git.kernel.org/stable/c/be72d197b2281e2ee3f28017fc9be1ab17e26d16 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2025-22014 – soc: qcom: pdr: Fix the potential deadlock
https://notcve.org/view.php?id=CVE-2025-22014
08 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pdr: Fix the potential deadlock When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr->locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queue... • https://git.kernel.org/stable/c/fbe639b44a82755d639df1c5d147c93f02ac5a0f •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2025-22013 – KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state
https://notcve.org/view.php?id=CVE-2025-22013
08 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state There are several problems with the way hyp code lazily saves the host's FPSIMD/SVE state, including: * Host SVE being discarded unexpectedly due to inconsistent configuration of TIF_SVE and CPACR_ELx.ZEN. This has been seen to result in QEMU crashes where SVE is used by memmove(), as reported by Eric Auger: https://issues.redhat.com/browse/RHEL-68997 * Host SVE state is disca... • https://git.kernel.org/stable/c/8c845e2731041f0fdf9287dea80b039b26332c9f •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2025-22010 – RDMA/hns: Fix soft lockup during bt pages loop
https://notcve.org/view.php?id=CVE-2025-22010
08 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup during bt pages loop Driver runs a for-loop when allocating bt pages and mapping them with buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated, it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... • https://git.kernel.org/stable/c/38389eaa4db192648916464b60f6086d6bbaa6de •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2025-22009 – regulator: dummy: force synchronous probing
https://notcve.org/view.php?id=CVE-2025-22009
08 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: regulator: dummy: force synchronous probing Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack: anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get() By placing some extra BUG_ON() statements I could verify that this is raised because probing of the 'dummy' regulator driver is not completed ('dummy_regulator_rdev' is still NULL). I... • https://git.kernel.org/stable/c/259b93b21a9ffe5117af4dfb5505437e463c6a5a •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2025-22008 – regulator: check that dummy regulator has been probed before using it
https://notcve.org/view.php?id=CVE-2025-22008
08 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: regulator: check that dummy regulator has been probed before using it Due to asynchronous driver probing there is a chance that the dummy regulator hasn't already been probed when first accessing it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulador: comprobar que el regulador ficticio haya sido probado antes de usarlo Debido al sondeo asincrónico del controlador existe la posibilidad de que el regulador ficticio ... • https://git.kernel.org/stable/c/270fe5c090f62dfce1cad0f5053e4827a6f50df4 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-22007 – Bluetooth: Fix error code in chan_alloc_skb_cb()
https://notcve.org/view.php?id=CVE-2025-22007
03 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix error code in chan_alloc_skb_cb() The chan_alloc_skb_cb() function is supposed to return error pointers on error. Returning NULL will lead to a NULL dereference. In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix error code in chan_alloc_skb_cb() The chan_alloc_skb_cb() function is supposed to return error pointers on error. Returning NULL will lead to a NULL dereference. • https://git.kernel.org/stable/c/6b8d4a6a03144c5996f98db7f8256267b0d72a3a •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-22005 – ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
https://notcve.org/view.php?id=CVE-2025-22005
03 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw(). fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails. Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak. Let's c... • https://git.kernel.org/stable/c/7dd73168e273938b9e9bb42ca51b0c27d807992b •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2025-22004 – net: atm: fix use after free in lec_send()
https://notcve.org/view.php?id=CVE-2025-22004
03 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: net: atm: fix use after free in lec_send() The ->send() operation frees skb so save the length before calling ->send() to avoid a use after free. In the Linux kernel, the following vulnerability has been resolved: net: atm: fix use after free in lec_send() The ->send() operation frees skb so save the length before calling ->send() to avoid a use after free. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 • CWE-416: Use After Free •
CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2025-22003 – can: ucan: fix out of bound read in strscpy() source
https://notcve.org/view.php?id=CVE-2025-22003
03 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix out of bound read in strscpy() source Commit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()") unintentionally introduced a one byte out of bound read on strscpy()'s source argument (which is kind of ironic knowing that strscpy() is meant to be a more secure alternative :)). Let's consider below buffers: dest[len + 1]; /* will be NUL terminated */ src[len]; /* may not be NUL terminated */ When doing: strncpy(d... • https://git.kernel.org/stable/c/7fdaf8966aae476deafe11f9a0067ff588615444 •