Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
he core driver (intel_qat.ko) remains loaded. Since the driver uses a shared workqueue (`qat_misc_wq`) across all devices and owned by intel_qat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50 To prevent t
ntel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50 To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded. Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability. References: - https://git.kernel.org/stable/c/5858448a6c65d8ee3f8600570d3ce19febcb33be - https://git.kernel.org/stable/c/fe546f5c50fc474daca6bee72caa7ab68a74c33d - https://git.kernel.org/stable/c/e59a52e429e13df3feb34f4853a8e36d121ed937 - https://git.kernel.org/stable/c/3d4df408ba9bad2b205c7
git.kernel.org/stable/c/e59a52e429e13df3feb34f4853a8e36d121ed937 - https://git.kernel.org/stable/c/3d4df408ba9bad2b205c7fb8afc1836a6a4ca88a
CVE ID: CVE-2025-39722 State: PUBLISHED Published: 2025-09-05T17:21:29.924Z Last Updated: 2025-09-29T05:58:09.333Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP Since the CAAM on these SoCs is managed by another ARM core, called the SECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which also reserves access to register page 0 suspend operations cannot touch this page. This is similar to when running OPTEE, where OPTEE will reserve page 0. Track this situation using a new state variable no_page0, reflecting if page 0 is reserved elsewhere, either b
e page 0. Track this situation using a new state variable no_page0, reflecting if page 0 is reserved elsewhere, either by other management cores in SoC or by OPTEE. Replace the optee_en check in suspend/resume with the new check. optee_en cannot go away as it's needed elsewhere to gate OPTEE specific situations. Fixes the following splat at suspend: Internal error: synchronous external abort: 0000000096000010 [#1] SMP Hardware name: Freescale i.MX8QXP ACU6C (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : readl+0x0/0x18 lr : rd_reg32+0x18/0x3c sp : ffffffc08192ba20 x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000 x26: ffffffc0808ae808 x25: ffffffc080
ffffffc08192ba20 x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000 x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090 x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010 x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5 x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001 x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000 x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002 x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000 x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004 Call trace: readl+0x0/0
21726880 x3 : ffffffc081200000 x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004 Call trace: readl+0x0/0x18 caam_ctrl_suspend+0x30/0xdc dpm_run_callback.constprop.0+0x24/0x5c device_suspend+0x170/0x2e8 dpm_suspend+0xa0/0x104 dpm_suspend_start+0x48/0x50 suspend_devices_and_enter+0x7c/0x45c pm_suspend+0x148/0x160 state_store+0xb4/0xf8 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x38/0x48 kernfs_fop_write_iter+0xb4/0x178 vfs_write+0x118/0x178 ksys_write+0x6c/0xd0 __arm64_sys_write+0x14/0x1c invoke_syscall.constprop.0+0x64/0xb0 do_el0_svc+0x90/0xb0 el0_svc+0x18/0x44 el0t_64_sync_handler+0x88/0x124 el0t_64_sync+0x150/0x154 Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000) Referenc
4 el0t_64_sync_handler+0x88/0x124 el0t_64_sync+0x150/0x154 Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000) References: - https://git.kernel.org/stable/c/f9534674ce53f133c91c272f091f0242932574ae - https://git.kernel.org/stable/c/488ed465e579a20485f38080e4ef8b90b69ef7c0 - https://git.kernel.org/stable/c/5ffc47feddcf8eb4d8ac7b42111a02c8e8146512
CVE ID: CVE-2025-39723 State: PUBLISHED Published: 2025-09-05T17:21:31.137Z Last Updated: 2025-09-29T05:58:10.575Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfs: Fix unbuffered write error handling If all the subrequests in an unbuffered write stream fail, the subrequest collector doesn't update the stream->transferred value and it retains its initial LONG_MAX value. Unfortunately, if all active streams fail, then we take the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to set in wreq->transferred - which is then returned from ->write_iter(). LONG_MAX was chosen as the initial value so that all the streams
nsferred - which is then returned from ->write_iter(). LONG_MAX was chosen as the initial value so that all the streams can be quickly assessed by taking the smallest value of all stream->transferred - but this only works if we've set any of them. Fix this by adding a flag to indicate whether the value in stream->transferred is valid and checking that when we integrate the values. stream->transferred can then be initialised to zero. This was found by running the generic/750 xfstest against cifs with cache=none. It splices data to the target file. Once (if) it has used up all the available scratch space, the writes start failing with ENOSPC. This causes ->write_iter() to fail. However, it was
l the available scratch space, the writes start failing with ENOSPC. This causes ->write_iter() to fail. However, it was returning wreq->transferred, i.e. LONG_MAX, rather than an error (because it thought the amount transferred was non-zero) and iter_file_splice_write() would then try to clean up that amount of pipe bufferage - leading to an oops when it overran. The kernel log showed: CIFS: VFS: Send error in write = -28 followed by: BUG: kernel NULL pointer dereference, address: 0000000000000008 with: RIP: 0010:iter_file_splice_write+0x3a4/0x520 do_splice+0x197/0x4e0 or: RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282) iter_file_splice_write (fs/splice.c:755) Also put a warning
RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282) iter_file_splice_write (fs/splice.c:755) Also put a warning check into splice to announce if ->write_iter() returned that it had written more than it was asked to. References: - https://git.kernel.org/stable/c/f08c80af3c9a9849cd178b4843b7c01d103506a1 - https://git.kernel.org/stable/c/387164a2b97e1f5404c6d0049a7409bac7d2bc5b - https://git.kernel.org/stable/c/a3de58b12ce074ec05b8741fa28d62ccb1070468
CVE ID: CVE-2025-39724 State: PUBLISHED Published: 2025-09-05T17:21:32.005Z Last Updated: 2025-11-03T17:42:46.902Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: serial: 8250: fix panic due to PSLVERR When the PSLVERR_RESP_EN parameter is set to 1, the device generates an error response if an attempt is made to read an empty RBR (Receive Buffer Register) while the FIFO is enabled. In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR
50_force_idle() and serial8250_clear_and_reinit_fifos(). The latter function enables the FIFO via serial_out(p, UART_FCR, p->fcr). Execution proceeds to the serial_port_in(port, UART_RX). This satisfies the PSLVERR trigger condition. When another CPU (e.g., using printk()) is accessing the UART (UART is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter dw8250_force_idle(). Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock to fix this issue. Panic backtrace: [ 0.442336] Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c
Oops - unknown exception [#1] [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e ... [ 0.442416] console_on_rootfs+0x26/0x70 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0b882f00655afefbc7729c6b5aec86f7a5473a3d - https://git.kernel.org/stable/c/b8ca8e3f75ede308b4d49a6ca5081460be01bdb5 - https://git.kernel.org/stable/c/68c4613e89f000e8198f9ace643082c697921c9f - https://git.kernel.org/stable/c/c826943abf473a3f7260fbadfad65e44db475460 - https://git.kernel.org/stable/c/cb7b3633ed749db8e56f475f43c960652cbd6882 - https://git.kernel.org/stable/c/8e2739478c164147d0774802008528d9e03fb802 - https://git.k
49db8e56f475f43c960652cbd6882 - https://git.kernel.org/stable/c/8e2739478c164147d0774802008528d9e03fb802 - https://git.kernel.org/stable/c/38c0ea484dedb58cb3a4391229933e16be0d1031 - https://git.kernel.org/stable/c/7f8fdd4dbffc05982b96caf586f77a014b2a9353
CVE ID: CVE-2025-39725 State: PUBLISHED Published: 2025-09-05T17:27:18.719Z Last Updated: 2025-09-05T17:27:18.719Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list In shrink_folio_list(), the hwpoisoned folio may be large folio, which can't be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one() must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then retry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache. Since UCE
vmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache. Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again. This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows: cpu0 cpu1 shrink_folio_list memory_failure TestSetPageHWPoison unmap_poisoned_folio --> trigger BUG_ON due to unmap_poisoned_folio couldn't handle large folio [tujinjiang@huawei.com: add comment to unmap_poisoned_folio()] References: - https://git.kernel.org/stable/c
large folio [tujinjiang@huawei.com: add comment to unmap_poisoned_folio()] References: - https://git.kernel.org/stable/c/656eaddbc952e1baae2f69281c22debe22140312 - https://git.kernel.org/stable/c/c1101113d45838a823188ae25c61af97552a28ae - https://git.kernel.org/stable/c/9f1e8cd0b7c4c944e9921b52a6661b5eda2705ab
CVE ID: CVE-2025-39726 State: PUBLISHED Published: 2025-09-05T17:27:19.818Z Last Updated: 2025-09-05T17:27:19.818Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as see
ei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does
me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one comman
ndicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences. References: - https://git.kernel.org/stable/c/faf44487dfc80817f178dc8de7a0b73f960d019b - https://git.kernel.org/stable/c/1194ad0d44d66b273a02a3a22882dc863a68d764 - https://git.kernel.org/stable/c/fafaa4982bedb5532f5952000f714a3e63023f40 - https://git.kernel.org/stable/c/897e8601b9cff1d054cdd53047f568b0e19957
able/c/fafaa4982bedb5532f5952000f714a3e63023f40 - https://git.kernel.org/stable/c/897e8601b9cff1d054cdd53047f568b0e1995726
CVE ID: CVE-2025-39727 State: PUBLISHED Published: 2025-09-07T15:16:17.986Z Last Updated: 2025-09-29T05:58:13.176Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix potential buffer overflow in setup_clusters() In setup_swap_map(), we only ensure badpages are in range (0, last_page]. As maxpages might be < last_page, setup_clusters() will encounter a buffer overflow when a badpage is >= maxpages. Only call inc_cluster_info_page() for badpage which is < maxpages to fix the issue. References: - https://git.kernel.org/stable/c/91b370800b3f2b3dda244c0ab06719c4971190a5 - https://git.kernel.org/stable/c/9b01ada580ee84fb319
//git.kernel.org/stable/c/91b370800b3f2b3dda244c0ab06719c4971190a5 - https://git.kernel.org/stable/c/9b01ada580ee84fb319e7ecb5fb5b1f54a9eb799 - https://git.kernel.org/stable/c/815c528b13f2bb9b3130c13bedeabf2351a68129 - https://git.kernel.org/stable/c/152c1339dc13ad46f1b136e8693de15980750835
CVE ID: CVE-2025-39728 State: PUBLISHED Published: 2025-04-18T07:01:35.818Z Last Updated: 2025-11-03T19:58:43.347Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: samsung: Fix UBSAN panic in samsung_clk_init() With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to dereferencing `ctx->clk_data.hws` before setting `ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP <snip> Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_in
clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ... Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/00307934eb94aaa0a99addfb37b9fe206f945004 - https://git.kernel.org/stable/c/d974e177369c034984cece9d7d4fada9f8b9c740 - https://git.kernel.org/stable/c/0fef48f4a70e45a93e73c39023c3a6ea624714d6 - https://git.kernel.org/stable/c/4d29a6dcb51e346595a15b49693eeb728925ca43 - https://git.kernel.org/stable/c/24307866e0ac0a5ddb462e766ceda5e27a6fbbe3 - https://git.kernel.org/stable/c/a1500b98cd81a32fdfb9bc63c33bb9f0c2a0a1bf - https://git.ker
a5ddb462e766ceda5e27a6fbbe3 - https://git.kernel.org/stable/c/a1500b98cd81a32fdfb9bc63c33bb9f0c2a0a1bf - https://git.kernel.org/stable/c/157de9e48007a20c65d02fc0229a16f38134a72d - https://git.kernel.org/stable/c/d19d7345a7bcdb083b65568a11b11adffe0687af
CVE ID: CVE-2025-39729 State: PUBLISHED Published: 2025-09-07T15:16:18.724Z Last Updated: 2025-09-29T05:58:14.417Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix dereferencing uninitialized error pointer Fix below smatch warnings: drivers/crypto/ccp/sev-dev.c:1312 __sev_platform_init_locked() error: we previously assumed 'error' could be null References: - https://git.kernel.org/stable/c/841634e1fdc2bdf35ab851fc279fd3bedcdf5e93 - https://git.kernel.org/stable/c/0fa766726c091ff0ec7d26874f6e4724d23ecb0e
CVE ID: CVE-2025-39730 State: PUBLISHED Published: 2025-09-07T15:16:19.377Z Last Updated: 2025-11-03T17:42:48.789Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() The function needs to check the minimal filehandle length before it can access the embedded filehandle. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7f8eca87fef7519e9c41f3258f25ebc2752247ee - https://git.kernel.org/stable/c/cb09afa0948d96b1e385d609ed044bb1aa043536 - https://git.kernel.org/stable/c/3570ef5c31314c13274c935a20b91768ab5bf412 - https://git.kernel.or
5d609ed044bb1aa043536 - https://git.kernel.org/stable/c/3570ef5c31314c13274c935a20b91768ab5bf412 - https://git.kernel.org/stable/c/763810bb883cb4de412a72f338d80947d97df67b - https://git.kernel.org/stable/c/12ad3def2e5e0b120e3d0cb6ce8b7b796819ad40 - https://git.kernel.org/stable/c/2ad40b7992aa26bc631afc1a995b0e3ddc30de3f - https://git.kernel.org/stable/c/b7f7866932466332a2528fda099000b035303485 - https://git.kernel.org/stable/c/7dd36f7477d1e03a1fcf8d13531ca326c4fb599f - https://git.kernel.org/stable/c/ef93a685e01a281b5e2a25ce4e3428cf9371a205
CVE ID: CVE-2025-39731 State: PUBLISHED Published: 2025-09-07T15:16:20.023Z Last Updated: 2025-11-03T17:42:49.723Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: vm_unmap_ram() may be called from an invalid context When testing F2FS with xfstests using UFS backed virtual disks the kernel complains sometimes that f2fs_release_decomp_mem() calls vm_unmap_ram() from an invalid context. Example trace from f2fs/007 test: f2fs/007 5s ... [12:59:38][ 8.902525] run fstests f2fs/007 [ 11.468026] BUG: sleeping function called from invalid context at mm/vmalloc.c:2978 [ 11.471849] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pi
ction called from invalid context at mm/vmalloc.c:2978 [ 11.471849] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 68, name: irq/22-ufshcd [ 11.475357] preempt_count: 1, expected: 0 [ 11.476970] RCU nest depth: 0, expected: 0 [ 11.478531] CPU: 0 UID: 0 PID: 68 Comm: irq/22-ufshcd Tainted: G W 6.16.0-rc5-xfstests-ufs-g40f92e79b0aa #9 PREEMPT(none) [ 11.478535] Tainted: [W]=WARN [ 11.478536] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 11.478537] Call Trace: [ 11.478543] <TASK> [ 11.478545] dump_stack_lvl+0x4e/0x70 [ 11.478554] __might_resched.cold+0xaf/0xbe [ 11.478557] vm_unmap_ram+0x21/0xb0 [ 11.478560] f2fs_release_decomp_mem+0x59/0x8
478554] __might_resched.cold+0xaf/0xbe [ 11.478557] vm_unmap_ram+0x21/0xb0 [ 11.478560] f2fs_release_decomp_mem+0x59/0x80 [ 11.478563] f2fs_free_dic+0x18/0x1a0 [ 11.478565] f2fs_finish_read_bio+0xd7/0x290 [ 11.478570] blk_update_request+0xec/0x3b0 [ 11.478574] ? sbitmap_queue_clear+0x3b/0x60 [ 11.478576] scsi_end_request+0x27/0x1a0 [ 11.478582] scsi_io_completion+0x40/0x300 [ 11.478583] ufshcd_mcq_poll_cqe_lock+0xa3/0xe0 [ 11.478588] ufshcd_sl_intr+0x194/0x1f0 [ 11.478592] ufshcd_threaded_intr+0x68/0xb0 [ 11.478594] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478599] irq_thread_fn+0x20/0x60 [ 11.478602] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478603] irq_thread+0xb9/0x180 [ 11.478605] ? __pfx_irq_thre
+0x20/0x60 [ 11.478602] ? __pfx_irq_thread_fn+0x10/0x10 [ 11.478603] irq_thread+0xb9/0x180 [ 11.478605] ? __pfx_irq_thread_dtor+0x10/0x10 [ 11.478607] ? __pfx_irq_thread+0x10/0x10 [ 11.478609] kthread+0x10a/0x230 [ 11.478614] ? __pfx_kthread+0x10/0x10 [ 11.478615] ret_from_fork+0x7e/0xd0 [ 11.478619] ? __pfx_kthread+0x10/0x10 [ 11.478621] ret_from_fork_asm+0x1a/0x30 [ 11.478623] </TASK> This patch modifies in_task() check inside f2fs_read_end_io() to also check if interrupts are disabled. This ensures that pages are unmapped asynchronously in an interrupt handler. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/eb69e69a5ae6c8350957893b5f68bd55
l Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/eb69e69a5ae6c8350957893b5f68bd55b1565fb2 - https://git.kernel.org/stable/c/1023836d1b9465593c8746f97d608da32958785f - https://git.kernel.org/stable/c/0fe7976b62546f1e95eebfe9879925e9aa22b7a8 - https://git.kernel.org/stable/c/411e00f44e2e1a7fdb526013b25a7f0ed22a0947 - https://git.kernel.org/stable/c/18eea36f4f460ead3750ed4afe5496f7ce55f99e - https://git.kernel.org/stable/c/08a7efc5b02a0620ae16aa9584060e980a69cb55
CVE ID: CVE-2025-39732 State: PUBLISHED Published: 2025-09-07T15:16:20.684Z Last Updated: 2025-09-29T05:58:18.159Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to ieee80211_iterate_stations_atomic(). Note in this case the iterator is required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does not follow it as it might sleep. Consequently below warning is seen: BUG: sleeping function called from invalid context at wmi.c:304 Call Trace: <TASK> dump_stack_lvl __might_resched.cold at
UG: sleeping function called from invalid context at wmi.c:304 Call Trace: <TASK> dump_stack_lvl __might_resched.cold ath11k_wmi_cmd_send ath11k_wmi_set_peer_param ath11k_mac_disable_peer_fixed_rate ieee80211_iterate_stations_atomic ath11k_mac_op_set_bitrate_mask.cold Change to ieee80211_iterate_stations_mtx() to fix this issue. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 References: - https://git.kernel.org/stable/c/9c0e3144924c7db701575a73af341d33184afeaf - https://git.kernel.org/stable/c/7d4d0db0dc9424de2bdc0b45e919e4892603356f - https://git.kernel.org/stable/c/6bdef22d540258ca06f079f7b6ae100669a19b47 - https://git.kernel.org/stable/c/65c12b104
f - https://git.kernel.org/stable/c/6bdef22d540258ca06f079f7b6ae100669a19b47 - https://git.kernel.org/stable/c/65c12b104cb942d588a1a093acc4537fb3d3b129
CVE ID: CVE-2025-39733 State: PUBLISHED Published: 2025-09-07T15:16:21.340Z Last Updated: 2025-09-29T05:58:19.402Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: team: replace team lock with rtnl lock syszbot reports various ordering issues for lower instance locks and team lock. Switch to using rtnl lock for protecting team device, similar to bonding. Based on the patch by Tetsuo Handa. References: - https://git.kernel.org/stable/c/556a4337ba3e9a70e1e3a428e8465c3ea3c4aa41 - https://git.kernel.org/stable/c/53edc761c9911f597b6d701e846f6e84f15eaa6d - https://git.kernel.org/stable/c/bfb4fb77f9a8ce33ce357224569eae5564eec573