Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE Program Container: References: - https://git.kernel.org/stable/c/e2c8a3c0388aef6bfc4aabfba07bc7dff16eea80 - https://git.kernel.org/stable/c/ec6392061de6681148b63ee6c8744da833498cdd - https://git.kernel.org/stable/c/e01851f6e9a665a6011b14714b271d3e6b0b8d32 - https://git.kernel.org/stable/c/6e3b09402cc6c3e3474fa548e8adf6897dda05de - https://git.kernel.org/stable/c/737bb912ebbe4571195c56eba557c4d7315b26fb
CVE ID: CVE-2025-38513 State: PUBLISHED Published: 2025-08-16T10:55:00.254Z Last Updated: 2025-11-03T17:39:16.277Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev() There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For example, the following is possible: T0 T1 zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; i<position; i++) skb = __skb_dequeue(q) if (mac->type == NL80211_IFTYPE_AP) skb = __skb_dequeue(q);
_len(q) */ for (i=1; i<position; i++) skb = __skb_dequeue(q) if (mac->type == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULL Since there is a small gap between checking skb queue length and skb being unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL. Then the pointer is passed to zd_mac_tx_status() where it is dereferenced. In order to avoid potential NULL pointer dereference due to situations like above, check if skb is not NULL before passing it to zd_mac_tx_status(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Additional Analyst Notes: - CVE Program Container: References: - https:/
ification Center (linuxtesting.org) with SVACE. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c1958270de947604cc6de05fc96dbba256b49cf0 - https://git.kernel.org/stable/c/014c34dc132015c4f918ada4982e952947ac1047 - https://git.kernel.org/stable/c/b24f65c184540dfb967479320ecf7e8c2e9220dc - https://git.kernel.org/stable/c/adf08c96b963c7cd7ec1ee1c0c556228d9bedaae - https://git.kernel.org/stable/c/5420de65efbeb6503bcf1d43451c9df67ad60298 - https://git.kernel.org/stable/c/fcd9c923b58e86501450b9b442ccc7ce4a8d0fda - https://git.kernel.org/stable/c/602b4eb2f25668de15de69860ec99caf65b3684d - https://git.kernel.org/stable/c/74b1ec9f5d627d2bdd5e5b6f3f81c2
l.org/stable/c/602b4eb2f25668de15de69860ec99caf65b3684d - https://git.kernel.org/stable/c/74b1ec9f5d627d2bdd5e5b6f3f81c23317657023
CVE ID: CVE-2025-38514 State: PUBLISHED Published: 2025-08-16T10:55:01.150Z Last Updated: 2025-11-03T17:39:18.150Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix oops due to non-existence of prealloc backlog struct If an AF_RXRPC service socket is opened and bound, but calls are preallocated, then rxrpc_alloc_incoming_call() will oops because the rxrpc_backlog struct doesn't get allocated until the first preallocation is made. Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no backlog struct. This will cause the incoming call to be aborted. Additional Analyst Notes: - CVE Program Container: Re
o backlog struct. This will cause the incoming call to be aborted. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/bf0ca6a1bc4fb904b598137c6718785a107e3adf - https://git.kernel.org/stable/c/f7afb3ff01c42c49e8a143cdce400b95844bb506 - https://git.kernel.org/stable/c/f5e72b7824d08c206ce106d30cb37c4642900ccc - https://git.kernel.org/stable/c/0eef29385d715d4c7fd707b18d4a9b76c76dd5e6 - https://git.kernel.org/stable/c/efc1b2b7c1a308b60df8f36bc2d7ce16d3999364 - https://git.kernel.org/stable/c/d1ff5f9d2c5405681457262e23c720b08977c11f - https://git.kernel.org/stable/c/2c2e9ebeb036f9b1b09325ec5cfdfe0e78f357c3 - https://git.kernel.org/stable/c/880a88f318c
- https://git.kernel.org/stable/c/2c2e9ebeb036f9b1b09325ec5cfdfe0e78f357c3 - https://git.kernel.org/stable/c/880a88f318cf1d2a0f4c0a7ff7b07e2062b434a4
CVE ID: CVE-2025-38515 State: PUBLISHED Published: 2025-08-16T10:55:02.173Z Last Updated: 2025-11-03T17:39:20.099Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/sched: Increment job count before swapping tail spsc queue A small race exists between spsc_queue_push and the run-job worker, in which spsc_queue_push may return not-first while the run-job worker has already idled due to the job count being zero. If this race occurs, job scheduling stops, leading to hangs while waiting on the job’s DMA fences. Seal this race by incrementing the job count before appending to the SPSC queue. This race was observed on a drm-tip 6.16
eal this race by incrementing the job count before appending to the SPSC queue. This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in an SVM test case. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/549a9c78c3ea6807d0dc4162a4f5ba59f217d5a0 - https://git.kernel.org/stable/c/e62f51d0ec8a9baf324caf9a564f8e318d36a551 - https://git.kernel.org/stable/c/ef841f8e4e1ff67817ca899bedc5ebb00847c0a7 - https://git.kernel.org/stable/c/f9a4f28a4fc4ee453a92a9abbe36e26224d17749 - https://git.kernel.org/stable/c/c64f5310530baf75328292f9b9f3f2961d185183 - https://git.kernel.org/stable/c/e2d6547dc8b9b332f9bc00875197287a6a4db65a - https://git.ke
af75328292f9b9f3f2961d185183 - https://git.kernel.org/stable/c/e2d6547dc8b9b332f9bc00875197287a6a4db65a - https://git.kernel.org/stable/c/ef58a95457466849fa7b31fd3953801a5af0f58b - https://git.kernel.org/stable/c/8af39ec5cf2be522c8eb43a3d8005ed59e4daaee
CVE ID: CVE-2025-38516 State: PUBLISHED Published: 2025-08-16T10:55:03.161Z Last Updated: 2025-11-03T17:39:22.028Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pinctrl: qcom: msm: mark certain pins as invalid for interrupts On some platforms, the UFS-reset pin has no interrupt logic in TLMM but is nevertheless registered as a GPIO in the kernel. This enables the user-space to trigger a BUG() in the pinctrl-msm driver by running, for example: `gpiomon -c 0 113` on RB2. The exact culprit is requesting pins whose intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially
se intr_detection_width setting is not 1 or 2 for interrupts. This hits a BUG() in msm_gpio_irq_set_type(). Potentially crashing the kernel due to an invalid request from user-space is not optimal, so let's go through the pins and mark those that would fail the check as invalid for the irq chip as we should not even register them as available irqs. This function can be extended if we determine that there are more corner-cases like this. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6a89563ccf9cd0d745e2291302878a061508573f - https://git.kernel.org/stable/c/3f8fc02c2582c1dfad1785e9c7bc8b4e1521af0a - https://git.kernel.org/stable/c/cb4b08a095b1
https://git.kernel.org/stable/c/3f8fc02c2582c1dfad1785e9c7bc8b4e1521af0a - https://git.kernel.org/stable/c/cb4b08a095b1fa4b3fca782757517e4e9a917d8e - https://git.kernel.org/stable/c/cc145e02d6b8494c48f91958d52fa76b7e577f7b - https://git.kernel.org/stable/c/1d57f7132662e96aace3b8a000616efde289aae1 - https://git.kernel.org/stable/c/275605a8b48002fe98675a5c06f3e39c09067ff2 - https://git.kernel.org/stable/c/97c9c7daeeb00c6e1d5e84084041f79c2d2dce22 - https://git.kernel.org/stable/c/93712205ce2f1fb047739494c0399a26ea4f0890
CVE ID: CVE-2025-38517 State: PUBLISHED Published: 2025-08-16T10:55:04.217Z Last Updated: 2025-08-16T10:55:04.217Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users() alloc_tag_top_users() attempts to lock alloc_tag_cttype->mod_lock even when the alloc_tag_cttype is not allocated because: 1) alloc tagging is disabled because mem profiling is disabled (!alloc_tag_cttype) 2) alloc tagging is enabled, but not yet initialized (!alloc_tag_cttype) 3) alloc tagging is enabled, but failed initialization (!alloc_tag_cttype or IS_ERR(alloc_tag_cttype)) In all cases, allo
) alloc tagging is enabled, but failed initialization (!alloc_tag_cttype or IS_ERR(alloc_tag_cttype)) In all cases, alloc_tag_cttype is not allocated, and therefore alloc_tag_top_users() should not attempt to acquire the semaphore. This leads to a crash on memory allocation failure by attempting to acquire a non-existent semaphore: Oops: general protection fault, probably for non-canonical address 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df] CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G D 6.16.0-rc2 #1 VOLUNTARY Tainted: [D]=DIE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
VOLUNTARY Tainted: [D]=DIE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:down_read_trylock+0xaa/0x3b0 Code: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016 RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000 RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000000000070 RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1 R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37 R13: 00000000003fff7b R14: ffff8
R09: ffffed107dde49d1 R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37 R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000 FS: 00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0 Call Trace: <TASK> codetag_trylock_module_list+0xd/0x20 alloc_tag_top_users+0x369/0x4b0 __show_mem+0x1cd/0x6e0 warn_alloc+0x2b1/0x390 __alloc_frozen_pages_noprof+0x12b9/0x21a0 alloc_pages_mpol+0x135/0x3e0 alloc_slab_page+0x82/0xe0 new_slab+0x212/0x240 ___slab_alloc+0x82a/0xe00 </TASK> As David Wang points out, this issue became easier to trigger after c
slab+0x212/0x240 ___slab_alloc+0x82a/0xe00 </TASK> As David Wang points out, this issue became easier to trigger after commit 780138b12381 ("alloc_tag: check mem_profiling_support in alloc_tag_init"). Before the commit, the issue occurred only when it failed to allocate and initialize alloc_tag_cttype or if a memory allocation fails before alloc_tag_init() is called. After the commit, it can be easily triggered when memory profiling is compiled but disabled at boot. To properly determine whether alloc_tag_init() has been called and its data structures initialized, verify that alloc_tag_cttype is a valid pointer before acquiring the semaphore. If the variable is NULL or an error value, it has
at alloc_tag_cttype is a valid pointer before acquiring the semaphore. If the variable is NULL or an error value, it has not been properly initialized. In such a case, just skip and do not attempt to acquire the semaphore. [harry.yoo@oracle.com: v3] References: - https://git.kernel.org/stable/c/febc0b5dbabda414565bdfaaaa59d26f787d5fe7 - https://git.kernel.org/stable/c/22bf79c0c2301b6e15a688220284b147774d277e - https://git.kernel.org/stable/c/99af22cd34688cc0d535a1919e0bea4cbc6c1ea1
CVE ID: CVE-2025-38518 State: PUBLISHED Published: 2025-08-16T10:55:05.039Z Last Updated: 2025-08-16T10:55:05.039Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Disable INVLPGB on Zen2 AMD Cyan Skillfish (Family 17h, Model 47h, Stepping 0h) has an issue that causes system oopses and panics when performing TLB flush using INVLPGB. However, the problem is that that machine has misconfigured CPUID and should not report the INVLPGB bit in the first place. So zap the kernel's representation of the flag so that nothing gets confused. [ bp: Massage. ] References: - https://git.kernel.org/stable/c/357f121517924e3ec3021f9d
g so that nothing gets confused. [ bp: Massage. ] References: - https://git.kernel.org/stable/c/357f121517924e3ec3021f9d0dd0189adcd09867 - https://git.kernel.org/stable/c/a74bb5f202dabddfea96abc1328fcedae8aa140a
CVE ID: CVE-2025-38519 State: PUBLISHED Published: 2025-08-16T10:55:06.083Z Last Updated: 2025-08-16T10:55:06.083Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/damon: fix divide by zero in damon_get_intervals_score() The current implementation allows having zero size regions with no special reasons, but damon_get_intervals_score() gets crashed by divide by zero when the region size is zero. [ 29.403950] Oops: divide error: 0000 [#1] SMP NOPTI This patch fixes the bug, but does not disallow zero size regions to keep the backward compatibility since disallowing zero size regions might be a breaking change for some users. In
ns to keep the backward compatibility since disallowing zero size regions might be a breaking change for some users. In addition, the same crash can happen when intervals_goal.access_bp is zero so this should be fixed in stable trees as well. References: - https://git.kernel.org/stable/c/ca4bb9ac706f05ead8ac1cce7b8245fc0645a687 - https://git.kernel.org/stable/c/bd225b9591442065beb876da72656f4a2d627d03
CVE ID: CVE-2025-38520 State: PUBLISHED Published: 2025-08-16T10:55:07.114Z Last Updated: 2025-11-03T17:39:22.959Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Don't call mmput from MMU notifier callback If the process is exiting, the mmput inside mmu notifier callback from compactd or fork or numa balancing could release the last reference of mm struct to call exit_mmap and free_pgtable, this triggers deadlock with below backtrace. The deadlock will leak kfd process as mmu notifier release is not called and cause VRAM leaking. The fix is to take mm reference mmget_non_zero when adding prange to the deferred list
t called and cause VRAM leaking. The fix is to take mm reference mmget_non_zero when adding prange to the deferred list to pair with mmput in deferred list work. If prange split and add into pchild list, the pchild work_item.mm is not used, so remove the mm parameter from svm_range_unmap_split and svm_range_add_child. The backtrace of hung task: INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalid
t+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x31
__handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu] (cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7) Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c1
f855f3dfff87e77bec7) Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c1bde9d48e09933c361521720f77a8072083c83a - https://git.kernel.org/stable/c/145a56bd68f4bff098d59fbc7c263d20dfef4fc4 - https://git.kernel.org/stable/c/e90ee15ce28c61f6d83a0511c3e02e2662478350 - https://git.kernel.org/stable/c/a7eb0a25010a674c8fdfbece38353ef7be8c5834 - https://git.kernel.org/stable/c/cf234231fcbc7d391e2135b9518613218cc5347f
CVE ID: CVE-2025-38521 State: PUBLISHED Published: 2025-08-16T10:55:08.373Z Last Updated: 2025-08-16T10:55:08.373Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix kernel crash when hard resetting the GPU The GPU hard reset sequence calls pm_runtime_force_suspend() and pm_runtime_force_resume(), which according to their documentation should only be used during system-wide PM transitions to sleep states. The main issue though is that depending on some internal runtime PM state as seen by pm_runtime_force_suspend() (whether the usage count is <= 1), pm_runtime_force_resume() might not resume the device unless n
untime_force_suspend() (whether the usage count is <= 1), pm_runtime_force_resume() might not resume the device unless needed. If that happens, the runtime PM resume callback pvr_power_device_resume() is not called, the GPU clocks are not re-enabled, and the kernel crashes on the next attempt to access GPU registers as part of the power-on sequence. Replace calls to pm_runtime_force_suspend() and pm_runtime_force_resume() with direct calls to the driver's runtime PM callbacks, pvr_power_device_suspend() and pvr_power_device_resume(), to ensure clocks are re-enabled and avoid the kernel crash. References: - https://git.kernel.org/stable/c/9f852d301f642223c4798f3c13ba15e91165d078 - https://git
d the kernel crash. References: - https://git.kernel.org/stable/c/9f852d301f642223c4798f3c13ba15e91165d078 - https://git.kernel.org/stable/c/e066cc6e0f094ca2120f1928d126d56f686cd73e - https://git.kernel.org/stable/c/d38376b3ee48d073c64e75e150510d7e6b4b04f7
CVE ID: CVE-2025-38522 State: PUBLISHED Published: 2025-08-16T11:12:11.304Z Last Updated: 2025-08-16T11:12:11.304Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched/ext: Prevent update_locked_rq() calls with NULL rq Avoid invoking update_locked_rq() when the runqueue (rq) pointer is NULL in the SCX_CALL_OP and SCX_CALL_OP_RET macros. Previously, calling update_locked_rq(NULL) with preemption enabled could trigger the following warning: BUG: using __this_cpu_write() in preemptible [00000000] This happens because __this_cpu_write() is unsafe to use in preemptible context. rq is NULL when an ops invoked from an unlocked context
ause __this_cpu_write() is unsafe to use in preemptible context. rq is NULL when an ops invoked from an unlocked context. In such cases, we don't need to store any rq, since the value should already be NULL (unlocked). Ensure that update_locked_rq() is only called when rq is non-NULL, preventing calling __this_cpu_write() on preemptible context. References: - https://git.kernel.org/stable/c/237c43037b336e36a49eb9f2daac1c7719ec7f8b - https://git.kernel.org/stable/c/e14fd98c6d66cb76694b12c05768e4f9e8c95664
CVE ID: CVE-2025-38523 State: PUBLISHED Published: 2025-08-16T11:12:17.254Z Last Updated: 2025-08-16T11:12:17.254Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: Fix the smbd_response slab to allow usercopy The handling of received data in the smbdirect client code involves using copy_to_iter() to copy data from the smbd_reponse struct's packet trailer to a folioq buffer provided by netfslib that encapsulates a chunk of pagecache. If, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks then performed in copy_to_iter() oopsing with something like the following: CIFS: Attempting to mount //172.31.9.1/test CI
en performed in copy_to_iter() oopsing with something like the following: CIFS: Attempting to mount //172.31.9.1/test CIFS: VFS: RDMA transport established usercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_0000000091e24ea1' (offset 81, size 63)! ------------[ cut here ]------------ kernel BUG at mm/usercopy.c:102! ... RIP: 0010:usercopy_abort+0x6c/0x80 ... Call Trace: <TASK> __check_heap_object+0xe3/0x120 __check_object_size+0x4dc/0x6d0 smbd_recv+0x77f/0xfe0 [cifs] cifs_readv_from_socket+0x276/0x8f0 [cifs] cifs_read_from_socket+0xcd/0x120 [cifs] cifs_demultiplex_thread+0x7e9/0x2d50 [cifs] kthread+0x396/0x830 ret_from_fork+0x2b8/0x3b0 ret_from_fork_asm+0x1a/0x3
fs] cifs_demultiplex_thread+0x7e9/0x2d50 [cifs] kthread+0x396/0x830 ret_from_fork+0x2b8/0x3b0 ret_from_fork_asm+0x1a/0x30 The problem is that the smbd_response slab's packet field isn't marked as being permitted for usercopy. Fix this by passing parameters to kmem_slab_create() to indicate that copy_to_iter() is permitted from the packet region of the smbd_response slab objects, less the header space. References: - https://git.kernel.org/stable/c/87dcc7e33fc3dcb8ed32333cec016528b5bb6ce4 - https://git.kernel.org/stable/c/f0dd353d47f7051afa98c6c60c7486831eb1a410 - https://git.kernel.org/stable/c/43e7e284fc77b710d899569360ea46fa3374ae22
CVE ID: CVE-2025-38524 State: PUBLISHED Published: 2025-08-16T11:12:18.314Z Last Updated: 2025-08-16T11:12:18.314Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recv-recv race of completed call If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the c
call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again. In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message). The first thread will return okay, but then the second thread will wake up holding the user_mutex a
he control message). The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474! Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale. References: - https://git.kernel.org/stable/c/7692bde890061797f3dece0148d7859e85c55778 - https://git.kernel.org/stable/c/839fe96c15209dc2255c064bb44b636efe04f032 - https://git.kernel.org/stable/c/6c75a97a32a5fa2060c3dd30207e63b6914b606d - https://git.kernel.org/stable/c/962fb1f651c2cf
ttps://git.kernel.org/stable/c/6c75a97a32a5fa2060c3dd30207e63b6914b606d - https://git.kernel.org/stable/c/962fb1f651c2cf2083e0c3ef53ba69e3b96d3fbc