Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
8 - https://git.kernel.org/stable/c/edafcad84c4134ebec4bc24b29ca4497a1184eea - https://git.kernel.org/stable/c/f85cb059fad03a3b33a50023be91e944bb065ae8 - https://git.kernel.org/stable/c/fadc626cae99aaa1325094edc6a9e2b883f3e562 - https://git.kernel.org/stable/c/32e10aabc287f09a148ff759bb9ce70b01b0012c - https://git.kernel.org/stable/c/c51d00472fa54b9b05c17789ed665c17adf3a25d - https://git.kernel.org/stable/c/0f8bc147a963686b7351aa35d1701124ffacac08 - https://git.kernel.org/stable/c/194d250cdc4a40ccbd179afd522a9e9846957402
CVE ID: CVE-2022-49533 State: PUBLISHED Published: 2025-02-26T02:13:52.495Z Last Updated: 2025-05-04T08:39:58.645Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ath11k: Change max no of active probe SSID and BSSID to fw capability The maximum number of SSIDs in a for active probe requests is currently reported as 16 (WLAN_SCAN_PARAMS_MAX_SSID) when registering the driver. The scan_req_params structure only has the capacity to hold 10 SSIDs. This leads to a buffer overflow which can be triggered from wpa_supplicant in userspace. When copying the SSIDs into the scan_req_params structure in the ath11k_mac_op_hw_scan route, it can
icant in userspace. When copying the SSIDs into the scan_req_params structure in the ath11k_mac_op_hw_scan route, it can overwrite the extraie pointer. Firmware supports 16 ssid * 4 bssid, for each ssid 4 bssid combo probe request will be sent, so totally 64 probe requests supported. So set both max ssid and bssid to 16 and 4 respectively. Remove the redundant macros of ssid and bssid. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01300-QCAHKSWPL_SILICONZ-1 References: - https://git.kernel.org/stable/c/210505788f1d243232e21ef660efcd4838890ce8 - https://git.kernel.org/stable/c/ec5dfa1d66f2f71a48dab027d26a9fa78eb0f58f - https://git.kernel.org/stable/c/50dc9ce9f80554a88e33b73c30851acf2be36ed3
CVE ID: CVE-2022-49534 State: PUBLISHED Published: 2025-02-26T02:13:52.978Z Last Updated: 2025-10-01T19:46:40.777Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT There is a potential memory leak in lpfc_ignore_els_cmpl() and lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT (lpfc_rcv_plogi()'s login_mbox). Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(), and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf for service parameters. For lpfc_els_rsp_reject() failure, free both the ctx_buf for service parameters an
mbox->ctx_buf for service parameters. For lpfc_els_rsp_reject() failure, free both the ctx_buf for service parameters and the login_mbox. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c00df0f34a6d5e14da379f96ea67e501ce67b002 - https://git.kernel.org/stable/c/672d1cb40551ea9c95efad43ab6d45e4ab4e015f
CVE ID: CVE-2022-49535 State: PUBLISHED Published: 2025-02-26T02:13:53.482Z Last Updated: 2025-05-04T08:40:01.596Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI If lpfc_issue_els_flogi() fails and returns non-zero status, the node reference count is decremented to trigger the release of the nodelist structure. However, if there is a prior registration or dev-loss-evt work pending, the node may be released prematurely. When dev-loss-evt completes, the released node is referenced causing a use-after-free null pointer dereference. Similarly, when proc
s-evt completes, the released node is referenced causing a use-after-free null pointer dereference. Similarly, when processing non-zero ELS PLOGI completion status in lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport registration before triggering node removal. If dev-loss-evt work is pending, the node may be released prematurely and a subsequent call to lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference. Add test for pending dev-loss before decrementing the node reference count for FLOGI, PLOGI, PRLI, and ADISC handling. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c7dc74ab7975c9b96284abfe4cca756d75fa4
lyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c7dc74ab7975c9b96284abfe4cca756d75fa4604 - https://git.kernel.org/stable/c/10663ebec0ad5c78493a0dd34c9ee4d73d7ca0df - https://git.kernel.org/stable/c/577a942df3de2666f6947bdd3a5c9e8d30073424
CVE ID: CVE-2022-49536 State: PUBLISHED Published: 2025-02-26T02:13:54.014Z Last Updated: 2025-10-01T19:46:40.573Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock During stress I/O tests with 500+ vports, hard LOCKUP call traces are observed. CPU A: native_queued_spin_lock_slowpath+0x192 _raw_spin_lock_irqsave+0x32 lpfc_handle_fcp_err+0x4c6 lpfc_fcp_io_cmd_wqe_cmpl+0x964 lpfc_sli4_fp_handle_cqe+0x266 __lpfc_sli4_process_cq+0x105 __lpfc_sli4_hba_process_cq+0x3c lpfc_cq_poll_hdler+0x16 irq_poll_softirq+0x76 __softirqentry_text_start+0xe4 irq_exit+0xf7 do_IRQ+0x7f CPU B
ess_cq+0x3c lpfc_cq_poll_hdler+0x16 irq_poll_softirq+0x76 __softirqentry_text_start+0xe4 irq_exit+0xf7 do_IRQ+0x7f CPU B: native_queued_spin_lock_slowpath+0x5b _raw_spin_lock+0x1c lpfc_abort_handler+0x13e scmd_eh_abort_handler+0x85 process_one_work+0x1a7 worker_thread+0x30 kthread+0x112 ret_from_fork+0x1f Diagram of lockup: CPUA CPUB ---- ---- lpfc_cmd->buf_lock phba->hbalock lpfc_cmd->buf_lock phba->hbalock Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock first before phba->hbalock. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7625e81de216
->hbalock. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7625e81de2164a082810e1f27547d388406da610 - https://git.kernel.org/stable/c/21c0d469349957b5dc811c41200a2a998996ca8d - https://git.kernel.org/stable/c/0c4eed901285b9cae36a622f32bea3e92490da6c - https://git.kernel.org/stable/c/03cbbd7c2f5ee288f648f4aeedc765a181188553
CVE ID: CVE-2022-49537 State: PUBLISHED Published: 2025-02-26T02:13:54.542Z Last Updated: 2025-10-29T10:50:03.168Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix call trace observed during I/O with CMF enabled The following was seen with CMF enabled: BUG: using smp_processor_id() in preemptible code: systemd-udevd/31711 kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: CPU: 12 PID: 31711 Comm: systemd-udevd kernel: Call Trace: kernel: <TASK> kernel: dump_stack_lvl+0x44/0x57 kernel: check_preemption_disabled+0xbf/0xe0 kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: lpfc_nvme_fcp_io_submit+0x
l: check_preemption_disabled+0xbf/0xe0 kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc] this_cpu_ptr() calls smp_processor_id() in a preemptible context. Fix by using per_cpu_ptr() with raw_smp_processor_id() instead. References: - https://git.kernel.org/stable/c/ae373d66c427812754db5292eb1481b181daf9ce - https://git.kernel.org/stable/c/cd7f899de4b1b829125d72ee6fbfd878b637b815 - https://git.kernel.org/stable/c/517e0835cfb2007713ff16c4fb8479f08b16aec7 - https://git.kernel.org/stable/c/d6d45f67a11136cb88a70a29ab22ea6db8ae6bd5
CVE ID: CVE-2022-49538 State: PUBLISHED Published: 2025-02-26T02:13:55.036Z Last Updated: 2025-10-01T19:46:40.376Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: jack: Access input_dev under mutex It is possible when using ASoC that input_dev is unregistered while calling snd_jack_report, which causes NULL pointer dereference. In order to prevent this serialize access to input_dev using mutex lock. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/74bab3bcf422593c582e47130aa8eb41ebb2dc09 - https://git.kernel.org/stable/c/8487a88136d54a1a4d3f26f1399685db648ab879 - https://git.
22593c582e47130aa8eb41ebb2dc09 - https://git.kernel.org/stable/c/8487a88136d54a1a4d3f26f1399685db648ab879 - https://git.kernel.org/stable/c/c093b62c40027c21d649c5534ad7aa3605a99b00 - https://git.kernel.org/stable/c/f68bed124c7699e23ffb4ce4fcc84671e9193cde - https://git.kernel.org/stable/c/e2b8681769f6e205382f026b907d28aa5ec9d59a - https://git.kernel.org/stable/c/5cc6f623f4818c7d7e9e966a45ebf324901ca9c5 - https://git.kernel.org/stable/c/9e6a73b0c0f2014eb89249fb1640c5a3d58221c4 - https://git.kernel.org/stable/c/582aea6084cc59fec881204f026816d1219f2348 - https://git.kernel.org/stable/c/1b6a6fc5280e97559287b61eade2d4b363e836f2
CVE ID: CVE-2022-49539 State: PUBLISHED Published: 2025-02-26T02:13:55.529Z Last Updated: 2025-05-04T08:40:06.520Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rtw89: ser: fix CAM leaks occurring in L2 reset The CAM, meaning address CAM and bssid CAM here, will get leaks during SER (system error recover) L2 reset process and ieee80211_restart_hw() which is called by L2 reset process eventually. The normal flow would be like -> add interface (acquire 1) -> enter ips (release 1) -> leave ips (acquire 1) -> connection (occupy 1) <(A) 1 leak after L2 reset if non-sec connection> The ieee80211_restart_hw() flow (under connection)
nection (occupy 1) <(A) 1 leak after L2 reset if non-sec connection> The ieee80211_restart_hw() flow (under connection) -> ieee80211 reconfig -> add interface (acquire 1) -> leave ips (acquire 1) -> connection (occupy (A) + 2) <(B) 1 more leak> Originally, CAM is released before HW restart only if connection is under security. Now, release CAM whatever connection it is to fix leak in (A). OTOH, check if CAM is already valid to avoid acquiring multiple times to fix (B). Besides, if AP mode, release address CAM of all stations before HW restart. References: - https://git.kernel.org/stable/c/f6aff772c9978844529618d86aafb53e5d3ae161 - https://git.kernel.org/stable/c/b169f877f001a474fb89939842c39
el.org/stable/c/f6aff772c9978844529618d86aafb53e5d3ae161 - https://git.kernel.org/stable/c/b169f877f001a474fb89939842c390518160bcc5
CVE ID: CVE-2022-49540 State: PUBLISHED Published: 2025-02-26T02:13:56.012Z Last Updated: 2025-05-04T08:40:07.765Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix race in schedule and flush work While booting secondary CPUs, cpus_read_[lock/unlock] is not keeping online cpumask stable. The transient online mask results in below calltrace. [ 0.324121] CPU1: Booted secondary processor 0x0000000001 [0x410fd083] [ 0.346652] Detected PIPT I-cache on CPU2 [ 0.347212] CPU2: Booted secondary processor 0x0000000002 [0x410fd083] [ 0.377255] Detected PIPT I-cache on CPU3 [ 0.377823] CPU3: Booted secondary processor 0x0000000
0000000002 [0x410fd083] [ 0.377255] Detected PIPT I-cache on CPU3 [ 0.377823] CPU3: Booted secondary processor 0x0000000003 [0x410fd083] [ 0.379040] ------------[ cut here ]------------ [ 0.383662] WARNING: CPU: 0 PID: 10 at kernel/workqueue.c:3084 __flush_work+0x12c/0x138 [ 0.384850] Modules linked in: [ 0.385403] CPU: 0 PID: 10 Comm: rcu_tasks_rude_ Not tainted 5.17.0-rc3-v8+ #13 [ 0.386473] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 0.387289] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.388308] pc : __flush_work+0x12c/0x138 [ 0.388970] lr : __flush_work+0x80/0x138 [ 0.389620] sp : ffffffc00aaf3c60 [ 0.390139] x29: ffffffc00aaf3d20 x28: ffffffc009c16af0 x27
: __flush_work+0x80/0x138 [ 0.389620] sp : ffffffc00aaf3c60 [ 0.390139] x29: ffffffc00aaf3d20 x28: ffffffc009c16af0 x27: ffffff80f761df48 [ 0.391316] x26: 0000000000000004 x25: 0000000000000003 x24: 0000000000000100 [ 0.392493] x23: ffffffffffffffff x22: ffffffc009c16b10 x21: ffffffc009c16b28 [ 0.393668] x20: ffffffc009e53861 x19: ffffff80f77fbf40 x18: 00000000d744fcc9 [ 0.394842] x17: 000000000000000b x16: 00000000000001c2 x15: ffffffc009e57550 [ 0.396016] x14: 0000000000000000 x13: ffffffffffffffff x12: 0000000100000000 [ 0.397190] x11: 0000000000000462 x10: ffffff8040258008 x9 : 0000000100000000 [ 0.398364] x8 : 0000000000000000 x7 : ffffffc0093c8bf4 x6 : 0000000000000000 [ 0.399538] x5
8008 x9 : 0000000100000000 [ 0.398364] x8 : 0000000000000000 x7 : ffffffc0093c8bf4 x6 : 0000000000000000 [ 0.399538] x5 : 0000000000000000 x4 : ffffffc00a976e40 x3 : ffffffc00810444c [ 0.400711] x2 : 0000000000000004 x1 : 0000000000000000 x0 : 0000000000000000 [ 0.401886] Call trace: [ 0.402309] __flush_work+0x12c/0x138 [ 0.402941] schedule_on_each_cpu+0x228/0x278 [ 0.403693] rcu_tasks_rude_wait_gp+0x130/0x144 [ 0.404502] rcu_tasks_kthread+0x220/0x254 [ 0.405264] kthread+0x174/0x1ac [ 0.405837] ret_from_fork+0x10/0x20 [ 0.406456] irq event stamp: 102 [ 0.406966] hardirqs last enabled at (101): [<ffffffc0093c8468>] _raw_spin_unlock_irq+0x78/0xb4 [ 0.408304] hardirqs last disabled at (102): [<
st enabled at (101): [<ffffffc0093c8468>] _raw_spin_unlock_irq+0x78/0xb4 [ 0.408304] hardirqs last disabled at (102): [<ffffffc0093b8270>] el1_dbg+0x24/0x5c [ 0.409410] softirqs last enabled at (54): [<ffffffc0081b80c8>] local_bh_enable+0xc/0x2c [ 0.410645] softirqs last disabled at (50): [<ffffffc0081b809c>] local_bh_disable+0xc/0x2c [ 0.411890] ---[ end trace 0000000000000000 ]--- [ 0.413000] smp: Brought up 1 node, 4 CPUs [ 0.413762] SMP: Total of 4 processors activated. [ 0.414566] CPU features: detected: 32-bit EL0 Support [ 0.415414] CPU features: detected: 32-bit EL1 Support [ 0.416278] CPU features: detected: CRC32 instructions [ 0.447021] Callback from call_rcu_tasks_rude() invoked.
Support [ 0.416278] CPU features: detected: CRC32 instructions [ 0.447021] Callback from call_rcu_tasks_rude() invoked. [ 0.506693] Callback from call_rcu_tasks() invoked. This commit therefore fixes this issue by applying a single-CPU optimization to the RCU Tasks Rude grace-period process. The key point here is that the purpose of this RCU flavor is to force a schedule on each online CPU since some past event. But the rcu_tasks_rude_wait_gp() function runs in the context of the RCU Tasks Rude's grace-period kthread, so there must already have been a context switch on the current CPU since the call to either synchronize_rcu_tasks_rude() or call_rcu_tasks_rude(). So if there is only a singl
current CPU since the call to either synchronize_rcu_tasks_rude() or call_rcu_tasks_rude(). So if there is only a single CPU online, RCU Tasks Rude's grace-period kthread does not need to anything at all. It turns out that the rcu_tasks_rude_wait_gp() function's call to schedule_on_each_cpu() causes problems during early boot. During that time, there is only one online CPU, namely the boot CPU. Therefore, applying this single-CPU optimization fixes early-boot instances of this problem. References: - https://git.kernel.org/stable/c/1c6c3f2336642fb3074593911f5176565f47ec41 - https://git.kernel.org/stable/c/ba722d061bc4b54802d701fc63fc2fd988934603 - https://git.kernel.org/stable/c/230bf5878af6
https://git.kernel.org/stable/c/ba722d061bc4b54802d701fc63fc2fd988934603 - https://git.kernel.org/stable/c/230bf5878af6038dfb63d9184272a58475236580 - https://git.kernel.org/stable/c/8f49a8758b5cd541bd7aa9a0d0d11c7426141c0e - https://git.kernel.org/stable/c/f75fd4b9221d93177c50dcfde671b2e907f53e86
CVE ID: CVE-2022-49541 State: PUBLISHED Published: 2025-02-26T02:13:56.496Z Last Updated: 2025-10-01T19:46:40.187Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential double free during failed mount RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2088799 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ce0008a0e410cdd95f0d8cd81b2902ec10a660c4 - https://git.kernel.org/stable/c/9a167fc440e5693c1cdd7f07071e05658bd9d89d - https://git.kernel.org/stable/c/ee71f8f1cd3c8c4a251fd3e8abc89215ae3457cb - https://git.kernel.org/stable/c/8378a51e3f8140f60901fb27208cc7a6e47047b5
CVE ID: CVE-2022-49542 State: PUBLISHED Published: 2025-02-26T02:13:56.961Z Last Updated: 2025-10-01T19:46:40.025Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg() In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard lockup call trace hangs the system. Call Trace: _raw_spin_lock_irqsave+0x32/0x40 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do
sh_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do_work+0x1485/0x1d70 [lpfc] kthread+0x112/0x130 ret_from_fork+0x1f/0x40 Kernel panic - not syncing: Hard LOCKUP The same CPU tries to claim the phba->port_list_lock twice. Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need to take the phba->port_list_lock within lpfc_dmp_dbg(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/271725e4028559ae7974d762a8467dc9de412f2e - https://git.kernel.org/stable/c/cc6501afccec55b8b6c90584cbf71f1fefa77d
able/c/271725e4028559ae7974d762a8467dc9de412f2e - https://git.kernel.org/stable/c/cc6501afccec55b8b6c90584cbf71f1fefa77d1e - https://git.kernel.org/stable/c/09c772557a4fd9490fed1bfb133268313ea22213 - https://git.kernel.org/stable/c/e294647b1aed4247fe52851f3a3b2b19ae906228
CVE ID: CVE-2022-49543 State: PUBLISHED Published: 2025-02-26T02:13:57.422Z Last Updated: 2025-05-04T08:40:11.855Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ath11k: fix the warning of dev_wake in mhi_pm_disable_transition() When test device recovery with below command, it has warning in message as below. echo assert > /sys/kernel/debug/ath11k/wcn6855\ hw2.0/simulate_fw_crash echo assert > /sys/kernel/debug/ath11k/qca6390\ hw2.0/simulate_fw_crash warning message: [ 1965.642121] ath11k_pci 0000:06:00.0: simulating firmware assert crash [ 1968.471364] ieee80211 phy0: Hardware restart was requested [ 1968.511305] ------------[
ulating firmware assert crash [ 1968.471364] ieee80211 phy0: Hardware restart was requested [ 1968.511305] ------------[ cut here ]------------ [ 1968.511368] WARNING: CPU: 3 PID: 1546 at drivers/bus/mhi/core/pm.c:505 mhi_pm_disable_transition+0xb37/0xda0 [mhi] [ 1968.511443] Modules linked in: ath11k_pci ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core [ 1968.511563] CPU: 3 PID: 1546 Comm: kworker/u17:0 Kdump: loaded Tainted: G W 5.17.0-rc3-wt-ath+ #579 [ 1968.511629] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi] [ 1968.511787] RIP: 0010:
.0067.2021.0528.1339 05/28/2021 [ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi] [ 1968.511787] RIP: 0010:mhi_pm_disable_transition+0xb37/0xda0 [mhi] [ 1968.511870] Code: a9 fe ff ff 4c 89 ff 44 89 04 24 e8 03 46 f6 e5 44 8b 04 24 41 83 f8 01 0f 84 21 fe ff ff e9 4c fd ff ff 0f 0b e9 af f8 ff ff <0f> 0b e9 5c f8 ff ff 48 89 df e8 da 9e ee e3 e9 12 fd ff ff 4c 89 [ 1968.511923] RSP: 0018:ffffc900024efbf0 EFLAGS: 00010286 [ 1968.511969] RAX: 00000000ffffffff RBX: ffff88811d241250 RCX: ffffffffc0176922 [ 1968.512014] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff888118a90a24 [ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27 [ 1968.512102] R10:
I: ffff888118a90a24 [ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27 [ 1968.512102] R10: ffffed1023152144 R11: 0000000000000001 R12: ffff888118a908ac [ 1968.512229] R13: ffff888118a90928 R14: dffffc0000000000 R15: ffff888118a90a24 [ 1968.512310] FS: 0000000000000000(0000) GS:ffff888234200000(0000) knlGS:0000000000000000 [ 1968.512405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1968.512493] CR2: 00007f5538f443a8 CR3: 000000016dc28001 CR4: 00000000003706e0 [ 1968.512587] Call Trace: [ 1968.512672] <TASK> [ 1968.512751] ? _raw_spin_unlock_irq+0x1f/0x40 [ 1968.512859] mhi_pm_st_worker+0x3ac/0x790 [mhi] [ 1968.512959] ? mhi_pm_mission_mode_transition.isra.0
k_irq+0x1f/0x40 [ 1968.512859] mhi_pm_st_worker+0x3ac/0x790 [mhi] [ 1968.512959] ? mhi_pm_mission_mode_transition.isra.0+0x7d0/0x7d0 [mhi] [ 1968.513063] process_one_work+0x86a/0x1400 [ 1968.513184] ? pwq_dec_nr_in_flight+0x230/0x230 [ 1968.513312] ? move_linked_works+0x125/0x290 [ 1968.513416] worker_thread+0x6db/0xf60 [ 1968.513536] ? process_one_work+0x1400/0x1400 [ 1968.513627] kthread+0x241/0x2d0 [ 1968.513733] ? kthread_complete_and_exit+0x20/0x20 [ 1968.513821] ret_from_fork+0x22/0x30 [ 1968.513924] </TASK> Reason is mhi_deassert_dev_wake() from mhi_device_put() is called but mhi_assert_dev_wake() from __mhi_device_get_sync() is not called in progress of recovery. Commit 8e0559921f9a
alled but mhi_assert_dev_wake() from __mhi_device_get_sync() is not called in progress of recovery. Commit 8e0559921f9a ("bus: mhi: core: Skip device wake in error or shutdown state") add check for the pm_state of mhi in __mhi_device_get_sync(), and the pm_state is not the normal state untill recovery is completed, so it leads the dev_wake is not 0 and above warning print in mhi_pm_disable_transition() while checking mhi_cntrl->dev_wake. Add check in ath11k_pci_write32()/ath11k_pci_read32() to skip call mhi_device_put() if mhi_device_get_sync() does not really do wake, then the warning gone. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 References: - https:
the warning gone. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 References: - https://git.kernel.org/stable/c/5f18206cddae033c488e4879f198699092ca0524 - https://git.kernel.org/stable/c/a2d9b7357469949ad02f511fc69f8fa3a1afbf89 - https://git.kernel.org/stable/c/0d7a8a6204ea9271f1d0a8c66a9fd2f54d2e3cbc
CVE ID: CVE-2022-49544 State: PUBLISHED Published: 2025-02-26T02:13:57.898Z Last Updated: 2025-10-01T19:46:39.844Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipw2x00: Fix potential NULL dereference in libipw_xmit() crypt and crypt->ops could be null, so we need to checking null before dereference Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1ff6b0727c8988f25eeb670b6c038c1120bb58dd - https://git.kernel.org/stable/c/b4628e0d3754ab2fc98ee6e3d21851ba45798077 - https://git.kernel.org/stable/c/167affc11781d7d35c4c3a7630a549ac74dd0b21 - https://git.kernel.org/stable/c/8fb1b9beb08
- https://git.kernel.org/stable/c/167affc11781d7d35c4c3a7630a549ac74dd0b21 - https://git.kernel.org/stable/c/8fb1b9beb085bb767ae43e441db5ac6fcd66a04d - https://git.kernel.org/stable/c/98d1dc32f890642476dbb78ed3437a456bf421b0 - https://git.kernel.org/stable/c/48d4a820fd33f012e5f63735a59d15b5a3882882 - https://git.kernel.org/stable/c/5f7ea274e88c0eeffe6bd6dbf6cf5c479d356af6 - https://git.kernel.org/stable/c/528d2023ccf4748fd542582955236c1634a7d293 - https://git.kernel.org/stable/c/e8366bbabe1d207cf7c5b11ae50e223ae6fc278b