Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-22001 State: PUBLISHED Published: 2025-04-03T07:19:04.251Z Last Updated: 2025-10-01T17:10:29.970Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Fix integer overflow in qaic_validate_req() These are u64 variables that come from the user via qaic_attach_slice_bo_ioctl(). Use check_add_overflow() to ensure that the math doesn't have an integer wrapping bug. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4b2a170c25862ad116bd31be6b9841646b4862e8 - https://git.kernel.org/stable/c/b362fc904d264a88b4af20baae9e82491c285e9c - https://git.kernel.org/stable/c/5
46b4862e8 - https://git.kernel.org/stable/c/b362fc904d264a88b4af20baae9e82491c285e9c - https://git.kernel.org/stable/c/57fae0c505f49bb1e3d5660cd2cc49697ed85f7c - https://git.kernel.org/stable/c/67d15c7aa0864dfd82325c7e7e7d8548b5224c7b
CVE ID: CVE-2025-22002 State: PUBLISHED Published: 2025-04-03T07:19:04.875Z Last Updated: 2025-10-01T17:10:14.114Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfs: Call `invalidate_cache` only if implemented Many filesystems such as NFS and Ceph do not implement the `invalidate_cache` method. On those filesystems, if writing to the cache (`NETFS_WRITE_TO_CACHE`) fails for some reason, the kernel crashes like this: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: Oops: 0010 [#1] SMP PTI CPU: 9 UID: 0
fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: Oops: 0010 [#1] SMP PTI CPU: 9 UID: 0 PID: 3380 Comm: kworker/u193:11 Not tainted 6.13.3-cm4all1-hp #437 Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018 Workqueue: events_unbound netfs_write_collection_worker RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffff9b86e2ca7dc0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 7fffffffffffffff RDX: 0000000000000001 RSI: ffff89259d576a18 RDI: ffff89259d576900 RBP: ffff89259d5769b0 R08: ffff9b86e2ca7d28 R09: 0000000000000002 R10: ffff89258ceaca80 R11: 0000000000000001 R12: 00000000000000
89259d5769b0 R08: ffff9b86e2ca7d28 R09: 0000000000000002 R10: ffff89258ceaca80 R11: 0000000000000001 R12: 0000000000000020 R13: ffff893d158b9338 R14: ffff89259d576900 R15: ffff89259d5769b0 FS: 0000000000000000(0000) GS:ffff893c9fa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000054442e003 CR4: 00000000001706f0 Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x15c/0x460 ? try_to_wake_up+0x2d2/0x530 ? exc_page_fault+0x5e/0x100 ? asm_exc_page_fault+0x22/0x30 netfs_write_collection_worker+0xe9f/0x12b0 ? xs_poll_check_readable+0x3f/0x80 ? xs_stream_data_receive_workfn+0x8d/0x110 process_one_work+0x134/0x2d0 worker_thread+0
xs_poll_check_readable+0x3f/0x80 ? xs_stream_data_receive_workfn+0x8d/0x110 process_one_work+0x134/0x2d0 worker_thread+0x299/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xba/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: CR2: 0000000000000000 This patch adds the missing `NULL` check. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0def1a40c3e76a468f8f66aa572caed44ec37277 - https://git.kernel.org/stable/c/c2d5d14a7bcbb045d0cd0095cefe95f2a4b91159 - https://git.kernel.org/stable/c/344b7ef248f420ed4ba3a3539cb0a0fc18df9a6c
CVE ID: CVE-2025-22003 State: PUBLISHED Published: 2025-04-03T07:19:05.403Z Last Updated: 2025-10-01T17:09:59.255Z Vendors: Linux Products: Linux Description: 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(dest, src, len); dest[len] = '
* will be NUL terminated */ src[len]; /* may not be NUL terminated */ When doing: strncpy(dest, src, len); dest[len] = '\0'; strncpy() will read up to len bytes from src. On the other hand: strscpy(dest, src, len + 1); will read up to len + 1 bytes from src, that is to say, an out of bound read of one byte will occur on src if it is not NUL terminated. Note that the src[len] byte is never copied, but strscpy() still needs to read it to check whether a truncation occurred or not. This exact pattern happened in ucan. The root cause is that the source is not NUL terminated. Instead of doing a copy in a local buffer, directly NUL terminate it as soon as usb_control_msg() returns. With this, the
stead of doing a copy in a local buffer, directly NUL terminate it as soon as usb_control_msg() returns. With this, the local firmware_str[] variable can be removed. On top of this do a couple refactors: - ucan_ctl_payload->raw is only used for the firmware string, so rename it to ucan_ctl_payload->fw_str and change its type from u8 to char. - ucan_device_request_in() is only used to retrieve the firmware string, so rename it to ucan_get_fw_str() and refactor it to make it directly handle all the string termination logic. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cc29775a8a72d7f3b56cc026796ad99bd65804a7 - https://git.kernel.org/stable/c/
eferences: - https://git.kernel.org/stable/c/cc29775a8a72d7f3b56cc026796ad99bd65804a7 - https://git.kernel.org/stable/c/8cec9e314d3360fc1d8346297c41a6ee45cb45a9 - https://git.kernel.org/stable/c/a4994161a61bc8fd71d105c579d847cefee99262 - https://git.kernel.org/stable/c/1d22a122ffb116c3cf78053e812b8b21f8852ee9
CVE ID: CVE-2025-22004 State: PUBLISHED Published: 2025-04-03T07:19:06.022Z Last Updated: 2025-11-03T19:40:44.831Z Vendors: Linux Products: Linux Description: 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/50e288097c2c6e5f374ae079394436fc29d1e88e - https://git.kernel.org/stable/c/8cd90c7db08f32829bfa1b5b2b11fbc542afbab7 - https://git.kernel.org/stable/c/82d9084a97892de1ee4881eb5c17911fcd9be6f6 - https://git.
8f32829bfa1b5b2b11fbc542afbab7 - https://git.kernel.org/stable/c/82d9084a97892de1ee4881eb5c17911fcd9be6f6 - https://git.kernel.org/stable/c/51e8be9578a2e74f9983d8fd8de8cafed191f30c - https://git.kernel.org/stable/c/9566f6ee13b17a15d0a47667ad1b1893c539f730 - https://git.kernel.org/stable/c/326223182e4703cde99fdbd36d07d0b3de9980fb - https://git.kernel.org/stable/c/f3271f7548385e0096739965961c7cbf7e6b4762 - https://git.kernel.org/stable/c/f3009d0d6ab78053117f8857b921a8237f4d17b3
CVE ID: CVE-2025-22005 State: PUBLISHED Published: 2025-04-03T07:19:06.716Z Last Updated: 2025-11-03T19:40:47.614Z Vendors: Linux Products: Linux Description: 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 call fib_nh_common_release() a
u_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak. Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path. Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/16267a5036173d0173377545b4b6021b081d0933 - https://git.kernel.org/stable/c/1bd12dfc058e1e68759d313d7727d68dbc1b8964 - https://git.kernel.org/stable/c/596a883c4ce2d2e9c175f25b98fed3a1f33fea38 - https://git.kernel.org/stable/c/77c41cdbe6bce476e08d3251c0d501feaf10a9f3 - https://git.kernel.org/stable/c/119dcafe36795a15
ps://git.kernel.org/stable/c/77c41cdbe6bce476e08d3251c0d501feaf10a9f3 - https://git.kernel.org/stable/c/119dcafe36795a15ae53351cbbd6177aaf94ffef - https://git.kernel.org/stable/c/29d91820184d5cbc70f3246d4911d96eaeb930d6 - https://git.kernel.org/stable/c/d3d5b4b5ae263c3225db363ba08b937e2e2b0380 - https://git.kernel.org/stable/c/9740890ee20e01f99ff1dde84c63dcf089fabb98
CVE ID: CVE-2025-22006 State: PUBLISHED Published: 2025-04-03T07:19:07.407Z Last Updated: 2025-10-01T17:09:33.963Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw: Fix NAPI registration sequence Registering the interrupts for TX or RX DMA Channels prior to registering their respective NAPI callbacks can result in a NULL pointer dereference. This is seen in practice as a random occurrence since it depends on the randomness associated with the generation of traffic by Linux and the reception of traffic from the wire. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.or
ception of traffic from the wire. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d4bf956547c38c04fad8d72a961ac4dc00bad000 - https://git.kernel.org/stable/c/942557abed7f38b77a47d77b92d448802eefe185 - https://git.kernel.org/stable/c/5f079290e5913a0060e059500b7d440990ac1066
CVE ID: CVE-2025-22007 State: PUBLISHED Published: 2025-04-03T07:19:07.986Z Last Updated: 2025-11-03T19:40:50.363Z Vendors: Linux Products: Linux Description: 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b3d607e36fef4bd05fb938a8a868ff70e9fedbe2 - https://git.kernel.org/stable/c/1bd68db7beb426ab5a45d81516ed9611284affc8 - https://git.kernel.org/stable/c/76304cba8cba12bb10d89d01
.kernel.org/stable/c/1bd68db7beb426ab5a45d81516ed9611284affc8 - https://git.kernel.org/stable/c/76304cba8cba12bb10d89d016c28403a2dd89a29 - https://git.kernel.org/stable/c/788ae2ae4cf484e248b5bc29211c7ac6510e3e92 - https://git.kernel.org/stable/c/ecd06ad0823a90b4420c377ef8917e44e23ee841 - https://git.kernel.org/stable/c/761b7c36addd22c7e6ceb05caaadc3b062d99faa - https://git.kernel.org/stable/c/a78692ec0d1e17a96b09f2349a028878f5b305e4 - https://git.kernel.org/stable/c/72d061ee630d0dbb45c2920d8d19b3861c413e54
CVE ID: CVE-2025-22008 State: PUBLISHED Published: 2025-04-08T08:17:59.257Z Last Updated: 2025-11-03T19:40:53.165Z Vendors: Linux Products: Linux Description: 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. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3a9c46af5654783f99015727ac65bc2a23e2735a - https://git.kernel.org/stable/c/8e500180904aae63afdce95cb378aeabe119ecda - https://git.kernel.org/stable/c/270fe5c090f62dfce1cad0f505
ernel.org/stable/c/8e500180904aae63afdce95cb378aeabe119ecda - https://git.kernel.org/stable/c/270fe5c090f62dfce1cad0f5053e4827a6f50df4 - https://git.kernel.org/stable/c/998b1aae22dca87da392ea35f089406cbef6032d - https://git.kernel.org/stable/c/a99f1254b11eaadd0794b74a8178bad92ab01cae - https://git.kernel.org/stable/c/21e3fdf3146f9c63888d6bfabbd553434a5fb93f - https://git.kernel.org/stable/c/2c7a50bec4958f1d1c84d19cde518d0e96a676fd
CVE ID: CVE-2025-22009 State: PUBLISHED Published: 2025-04-08T08:17:59.840Z Last Updated: 2025-10-01T17:09:02.444Z Vendors: Linux Products: Linux Description: 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). In the JTAG debugger I can see
of the 'dummy' regulator driver is not completed ('dummy_regulator_rdev' is still NULL). In the JTAG debugger I can see that dummy_regulator_probe() and anatop_regulator_probe() can be run by different kernel threads (kworker/u4:*). I haven't further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don't expect much boot time penalty by probing the 'dummy' regulator synchronously. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e26f24ca4fb940b15e092796c5993142a2558bd9 - https://git.kernel.org/stable/c/d3b83a1442a09b145006eb4294b1a963c534
stable/c/e26f24ca4fb940b15e092796c5993142a2558bd9 - https://git.kernel.org/stable/c/d3b83a1442a09b145006eb4294b1a963c5345c9c - https://git.kernel.org/stable/c/5ade367b56c3947c990598df92395ce737bee872 - https://git.kernel.org/stable/c/8619909b38eeebd3e60910158d7d68441fc954e9
CVE ID: CVE-2025-22010 State: PUBLISHED Published: 2025-04-08T08:18:00.430Z Last Updated: 2025-11-03T19:40:55.912Z Vendors: Linux Products: Linux Description: 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! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns
+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bc Add a cond_resched() to fix soft lockup during these loops. In order not to affect the allocation performance of norm
bc Add a cond_resched() to fix soft lockup during these loops. In order not to affect the allocation performance of normal-size buffer, set the loop count of a 100GB MR as the threshold to call cond_resched(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/461eb4ddede266df8f181f578732bb01742c3fd6 - https://git.kernel.org/stable/c/efe544462fc0b499725364f90bd0f8bbf16f861a - https://git.kernel.org/stable/c/4104b0023ff66b5df900d23dbf38310893deca79 - https://git.kernel.org/stable/c/975355faba56c0751292ed15a90c3e2c7dc0aad6 - https://git.kernel.org/stable/c/13a52f6c9ff99f7d88f81da535cb4e85eade662b - https://git.kernel.org/stable/c/9ab20fec7a1ce3057a
://git.kernel.org/stable/c/13a52f6c9ff99f7d88f81da535cb4e85eade662b - https://git.kernel.org/stable/c/9ab20fec7a1ce3057ad86afd27bfd08420b7cd11 - https://git.kernel.org/stable/c/25655580136de59ec89f09089dd28008ea440fc9
CVE ID: CVE-2025-22011 State: PUBLISHED Published: 2025-04-08T08:18:01.074Z Last Updated: 2025-10-01T18:14:52.265Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: dts: bcm2711: Fix xHCI power-domain During s2idle tests on the Raspberry CM4 the VPU firmware always crashes on xHCI power-domain resume: root@raspberrypi:/sys/power# echo freeze > state [ 70.724347] xhci_suspend finished [ 70.727730] xhci_plat_suspend finished [ 70.755624] bcm2835-power bcm2835-power: Power grafx off [ 70.761127] USB: Set power to 0 [ 74.653040] USB: Failed to set power to 1 (-110) This seems to be caused because of the mixed usage of raspberrypi
to 0 [ 74.653040] USB: Failed to set power to 1 (-110) This seems to be caused because of the mixed usage of raspberrypi-power and bcm2835-power at the same time. So avoid the usage of the VPU firmware power-domain driver, which prevents the VPU crash. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/b8a47aa0b3df701d0fc41b3caf78d00571776be0 - https://git.kernel.org/stable/c/393947e06867923d4c2be380d46efd03407a8ce2 - https://git.kernel.org/stable/c/f44fa354a0715577ca32b085f6f60bcf32c748dd
CVE ID: CVE-2025-22012 State: PUBLISHED Published: 2025-04-08T08:18:03.312Z Last Updated: 2025-10-01T17:06:57.968Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu" There are reports that the pagetable walker cache coherency is not a given across the spectrum of SDM845/850 devices, leading to lock-ups and resets. It works fine on some devices (like the Dragonboard 845c, but not so much on the Lenovo Yoga C630). This unfortunately looks like a fluke in firmware development, where likely somewhere in the vast hypervisor stack, a change to accommodate for this was only
in firmware development, where likely somewhere in the vast hypervisor stack, a change to accommodate for this was only introduced after the initial software release (which often serves as a baseline for products). Revert the change to avoid additional guesswork around crashes. This reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/9e6e9fc90258a318d30b417bcccda908bb82ee9d - https://git.kernel.org/stable/c/f00db31d235946853fb430de8c6aa1295efc8353
CVE ID: CVE-2025-22013 State: PUBLISHED Published: 2025-04-08T08:18:04.000Z Last Updated: 2025-05-04T07:27:37.103Z Vendors: Linux Products: Linux Description: 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 discarded *after* modification by
ported by Eric Auger: https://issues.redhat.com/browse/RHEL-68997 * Host SVE state is discarded *after* modification by ptrace, which was an unintentional ptrace ABI change introduced with lazy discarding of SVE state. * The host FPMR value can be discarded when running a non-protected VM, where FPMR support is not exposed to a VM, and that VM uses FPSIMD/SVE. In these cases the hyp code does not save the host's FPMR before unbinding the host's FPSIMD/SVE/SME state, leaving a stale value in memory. Avoid these by eagerly saving and "flushing" the host's FPSIMD/SVE/SME state when loading a vCPU such that KVM does not need to save any of the host's FPSIMD/SVE/SME state. For clarity, fpsimd_kvm
when loading a vCPU such that KVM does not need to save any of the host's FPSIMD/SVE/SME state. For clarity, fpsimd_kvm_prepare() is removed and the necessary call to fpsimd_save_and_flush_cpu_state() is placed in kvm_arch_vcpu_load_fp(). As 'fpsimd_state' and 'fpmr_ptr' should not be used, they are set to NULL; all uses of these will be removed in subsequent patches. Historical problems go back at least as far as v5.17, e.g. erroneous assumptions about TIF_SVE being clear in commit: 8383741ab2e773a9 ("KVM: arm64: Get rid of host SVE tracking/saving") ... and so this eager save+flush probably needs to be backported to ALL stable trees. References: - https://git.kernel.org/stable/c/5289ac43b
save+flush probably needs to be backported to ALL stable trees. References: - https://git.kernel.org/stable/c/5289ac43b69c61a49c75720921f2008005a31c43 - https://git.kernel.org/stable/c/04c50cc23a492c4d43fdaefc7c1ecc0ff6f7b82e - https://git.kernel.org/stable/c/806d5c1e1d2e5502175a24bf70f251648d99c36a - https://git.kernel.org/stable/c/79e140bba70bcacc5fe15bf8c0b958793fd7d56f - https://git.kernel.org/stable/c/900b444be493b7f404898c785d6605b177a093d0 - https://git.kernel.org/stable/c/fbc7e61195e23f744814e78524b73b59faa54ab4
CVE ID: CVE-2025-22014 State: PUBLISHED Published: 2025-04-08T08:18:04.622Z Last Updated: 2025-11-03T19:40:58.659Z Vendors: Linux Products: Linux Description: 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 queued to the same qmi->wq and it
lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock. Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here. Process A Process B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PD
r_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret); Timeout error log due to deadlock: " PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 " Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/72a222b6af10c2a05a5fad0029246229ed8912c2 - https://git.kernel.org/stable/c/
eferences: - https://git.kernel.org/stable/c/72a222b6af10c2a05a5fad0029246229ed8912c2 - https://git.kernel.org/stable/c/daba84612236de3ab39083e62c9e326a654ebd20 - https://git.kernel.org/stable/c/0a566a79aca9851fae140536e0fc5b0853c90a90 - https://git.kernel.org/stable/c/f2bbfd50e95bc117360f0f59e629aa03d821ebd6 - https://git.kernel.org/stable/c/f4489260f5713c94e1966e5f20445bff262876f4 - https://git.kernel.org/stable/c/02612f1e4c34d94d6c8ee75bf7d254ed697e22d4 - https://git.kernel.org/stable/c/2eeb03ad9f42dfece63051be2400af487ddb96d2