Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-21844 State: PUBLISHED Published: 2025-03-12T09:42:00.435Z Last Updated: 2025-11-03T19:38:00.594Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: Add check for next_buffer in receive_encrypted_standard() Add check for the return value of cifs_buf_get() and cifs_small_buf_get() in receive_encrypted_standard() to prevent null pointer dereference. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f277e479eea3d1aa18bc712abe1d2bf3dece2e30 - https://git.kernel.org/stable/c/f618aeb6cad2307e48a641379db610abcf593edf - https://git.kernel.
8bc712abe1d2bf3dece2e30 - https://git.kernel.org/stable/c/f618aeb6cad2307e48a641379db610abcf593edf - https://git.kernel.org/stable/c/24e8e4523d3071bc5143b0db9127d511489f7b3b - https://git.kernel.org/stable/c/9e5d99a4cf2e23c716b44862975548415fae5391 - https://git.kernel.org/stable/c/a9b0b4b29877cb4dc5d0842b59b5ccbacddb85bd - https://git.kernel.org/stable/c/554736b583f529ee159aa95af9a0cbc12b5ffc96 - https://git.kernel.org/stable/c/860ca5e50f73c2a1cef7eefc9d39d04e275417f7
CVE ID: CVE-2025-21845 State: PUBLISHED Published: 2025-03-12T09:42:01.252Z Last Updated: 2025-10-01T19:36:34.588Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: sst: Fix SST write failure 'commit 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation to `sst_nor_write_data()`")' introduced a bug where only one byte of data is written, regardless of the number of bytes passed to sst_nor_write_data(), causing a kernel crash during the write operation. Ensure the correct number of bytes are written as passed to sst_nor_write_data(). Call trace: [ 57.400180] ------------[ cut here ]------------ [ 57.4048
s are written as passed to sst_nor_write_data(). Call trace: [ 57.400180] ------------[ cut here ]------------ [ 57.404842] While writing 2 byte written 1 bytes [ 57.409493] WARNING: CPU: 0 PID: 737 at drivers/mtd/spi-nor/sst.c:187 sst_nor_write_data+0x6c/0x74 [ 57.418464] Modules linked in: [ 57.421517] CPU: 0 UID: 0 PID: 737 Comm: mtd_debug Not tainted 6.12.0-g5ad04afd91f9 #30 [ 57.429517] Hardware name: Xilinx Versal A2197 Processor board revA - x-prc-02 revA (DT) [ 57.437600] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 57.444557] pc : sst_nor_write_data+0x6c/0x74 [ 57.448911] lr : sst_nor_write_data+0x6c/0x74 [ 57.453264] sp : ffff80008232bb40 [ 57.456570] x29: ffff
_data+0x6c/0x74 [ 57.448911] lr : sst_nor_write_data+0x6c/0x74 [ 57.453264] sp : ffff80008232bb40 [ 57.456570] x29: ffff80008232bb40 x28: 0000000000010000 x27: 0000000000000001 [ 57.463708] x26: 000000000000ffff x25: 0000000000000000 x24: 0000000000000000 [ 57.470843] x23: 0000000000010000 x22: ffff80008232bbf0 x21: ffff000816230000 [ 57.477978] x20: ffff0008056c0080 x19: 0000000000000002 x18: 0000000000000006 [ 57.485112] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008232b580 [ 57.492246] x14: 0000000000000000 x13: ffff8000816d1530 x12: 00000000000004a4 [ 57.499380] x11: 000000000000018c x10: ffff8000816fd530 x9 : ffff8000816d1530 [ 57.506515] x8 : 00000000fffff7ff x7 : ffff80008
380] x11: 000000000000018c x10: ffff8000816fd530 x9 : ffff8000816d1530 [ 57.506515] x8 : 00000000fffff7ff x7 : ffff8000816fd530 x6 : 0000000000000001 [ 57.513649] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 57.520782] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008049b0000 [ 57.527916] Call trace: [ 57.530354] sst_nor_write_data+0x6c/0x74 [ 57.534361] sst_nor_write+0xb4/0x18c [ 57.538019] mtd_write_oob_std+0x7c/0x88 [ 57.541941] mtd_write_oob+0x70/0xbc [ 57.545511] mtd_write+0x68/0xa8 [ 57.548733] mtdchar_write+0x10c/0x290 [ 57.552477] vfs_write+0xb4/0x3a8 [ 57.555791] ksys_write+0x74/0x10c [ 57.559189] __arm64_sys_write+0x1c/0x28 [ 57.563109] invoke_syscall
write+0xb4/0x3a8 [ 57.555791] ksys_write+0x74/0x10c [ 57.559189] __arm64_sys_write+0x1c/0x28 [ 57.563109] invoke_syscall+0x54/0x11c [ 57.566856] el0_svc_common.constprop.0+0xc0/0xe0 [ 57.571557] do_el0_svc+0x1c/0x28 [ 57.574868] el0_svc+0x30/0xcc [ 57.577921] el0t_64_sync_handler+0x120/0x12c [ 57.582276] el0t_64_sync+0x190/0x194 [ 57.585933] ---[ end trace 0000000000000000 ]--- [pratyush@kernel.org: add Cc stable tag] Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/bb1accc7e0f688886f0c634f2e878b8ac4ee6a58 - https://git.kernel.org/stable/c/9553391f32f8c43e12fc7c04e1035160b5ea20bf - https://git.kernel.org/stable/c/539bd20352832b9244238a055eb169c
.org/stable/c/9553391f32f8c43e12fc7c04e1035160b5ea20bf - https://git.kernel.org/stable/c/539bd20352832b9244238a055eb169ccf1c41ff6
CVE ID: CVE-2025-21846 State: PUBLISHED Published: 2025-03-12T09:42:02.635Z Last Updated: 2025-11-03T19:38:03.560Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so t
xited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/8acbf4a88c6a98c8ed00afd1a7d1abcca9b4735e - https://git.kernel.org/stable/c/b03782ae707cc45e65242c7cddd8e28f1c22cde5 - https://git.kernel.org/stable/c/5d5b936cfa4b0d5670ca7420ef165a074bc008eb - https://git.kernel.org/stable/c/5ee8da9bea70dda492d61f075658
nel.org/stable/c/5d5b936cfa4b0d5670ca7420ef165a074bc008eb - https://git.kernel.org/stable/c/5ee8da9bea70dda492d61f075658939af33d8410 - https://git.kernel.org/stable/c/5c928e14a2ccd99462f2351ead627b58075bb736 - https://git.kernel.org/stable/c/5a59ced8ffc71973d42c82484a719c8f6ac8f7f7 - https://git.kernel.org/stable/c/a8136afca090412a36429cb6c2543c714d9c0f84 - https://git.kernel.org/stable/c/56d5f3eba3f5de0efdd556de4ef381e109b973a9
CVE ID: CVE-2025-21847 State: PUBLISHED Published: 2025-03-12T09:42:03.568Z Last Updated: 2025-10-01T19:26:39.271Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data() The nullity of sps->cstream should be checked similarly as it is done in sof_set_stream_data_offset() function. Assuming that it is not NULL if sps->stream is NULL is incorrect and can lead to NULL pointer dereference. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2b3878baf90918a361a3dfd3513025100b1b40b6 - https://git.kernel.org/stable/c/62ab1ae5511
- https://git.kernel.org/stable/c/2b3878baf90918a361a3dfd3513025100b1b40b6 - https://git.kernel.org/stable/c/62ab1ae5511c59b5f0bf550136ff321331adca9f - https://git.kernel.org/stable/c/6c18f5eb2043ebf4674c08a9690218dc818a11ab - https://git.kernel.org/stable/c/d8d99c3b5c485f339864aeaa29f76269cc0ea975
CVE ID: CVE-2025-21848 State: PUBLISHED Published: 2025-03-12T09:42:04.263Z Last Updated: 2025-11-03T19:38:06.353Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d64c6ca420019712e194fe095b55f87363e22a9a - https://git.kernel.org/stable/c/e976ea6c5e1b005c64467cbf94a8577aae9c7d81 - https://git.kernel.org/stable/c/924b239f9704566e0d86abd894d2d64b
org/stable/c/e976ea6c5e1b005c64467cbf94a8577aae9c7d81 - https://git.kernel.org/stable/c/924b239f9704566e0d86abd894d2d64bd73c11eb - https://git.kernel.org/stable/c/1358d8e07afdf21d49ca6f00c56048442977e00a - https://git.kernel.org/stable/c/29ccb1e4040da6ff02b7e64efaa2f8e6bf06020d - https://git.kernel.org/stable/c/897c32cd763fd11d0b6ed024c52f44d2475bb820 - https://git.kernel.org/stable/c/bd97f60750bb581f07051f98e31dfda59d3a783b - https://git.kernel.org/stable/c/878e7b11736e062514e58f3b445ff343e6705537
CVE ID: CVE-2025-21849 State: PUBLISHED Published: 2025-03-12T09:42:04.946Z Last Updated: 2025-10-01T19:26:39.006Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Use spin_lock_irqsave() in interruptible context spin_lock/unlock() functions used in interrupt contexts could result in a deadlock, as seen in GitLab issue #13399, which occurs when interrupt comes in while holding a lock. Try to remedy the problem by saving irq state before spin lock acquisition. v2: add irqs' state save/restore calls to all locks/unlocks in signal_irq_work() execution (Maciej) v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() ins
o all locks/unlocks in signal_irq_work() execution (Maciej) v3: use with spin_lock_irqsave() in guc_lrc_desc_unpin() instead of other lock/unlock calls and add Fixes and Cc tags (Tvrtko); change title and commit message (cherry picked from commit c088387ddd6482b40f21ccf23db1125e8fa4af7e) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2bf1f4c129db7a10920655b000f0292f1ee509c2 - https://git.kernel.org/stable/c/47ae46ac5407646420e06b78e0dad331e56a4bb4 - https://git.kernel.org/stable/c/e49477f7f78598295551d486ecc7f020d796432e
CVE ID: CVE-2025-21850 State: PUBLISHED Published: 2025-03-12T09:42:05.761Z Last Updated: 2025-10-01T19:26:38.884Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvmet: Fix crash when a namespace is disabled The namespace percpu counter protects pending I/O, and we can only safely diable the namespace once the counter drop to zero. Otherwise we end up with a crash when running blktests/nvme/058 (eg for loop transport): [ 2352.930426] [ T53909] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI [ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x000000000
0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI [ 2352.930431] [ T53909] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 2352.930434] [ T53909] CPU: 3 UID: 0 PID: 53909 Comm: kworker/u16:5 Tainted: G W 6.13.0-rc6 #232 [ 2352.930438] [ T53909] Tainted: [W]=WARN [ 2352.930440] [ T53909] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 2352.930443] [ T53909] Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] [ 2352.930449] [ T53909] RIP: 0010:blkcg_set_ioprio+0x44/0x180 as the queue is already torn down when calling submit_bio(); So we need to init the percpu counter in nvmet_ns_enable(), and wait for it to drop to zero in n
n calling submit_bio(); So we need to init the percpu counter in nvmet_ns_enable(), and wait for it to drop to zero in nvmet_ns_disable() to avoid having I/O pending after the namespace has been disabled. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cc0607594f6813342b27c752c6fb6f6eb9980cb5 - https://git.kernel.org/stable/c/4082326807072b71496501b6a0c55ffe8d5092a5
CVE ID: CVE-2025-21851 State: PUBLISHED Published: 2025-03-12T09:42:06.480Z Last Updated: 2025-10-01T19:26:38.747Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix softlockup in arena_map_free on 64k page kernel On an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y, arena_htab tests cause a segmentation fault and soft lockup. The same failure is not observed with 4k pages on aarch64. It turns out arena_map_free() is calling apply_to_existing_page_range() with the address returned by bpf_arena_get_kern_vm_start(). If this address is not page-aligned the code ends up calling apply_to_pte_range() with that unaligned address cau
art(). If this address is not page-aligned the code ends up calling apply_to_pte_range() with that unaligned address causing soft lockup. Fix it by round up GUARD_SZ to PAGE_SIZE << 1 so that the division by 2 in bpf_arena_get_kern_vm_start() returns a page-aligned value. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/c1f3f3892d4526f18aaeffdb6068ce861e793ee3 - https://git.kernel.org/stable/c/787d556a3de447e70964a4bdeba9196f62a62b1e - https://git.kernel.org/stable/c/517e8a7835e8cfb398a0aeb0133de50e31cae32b
CVE ID: CVE-2025-21852 State: PUBLISHED Published: 2025-03-12T09:42:07.175Z Last Updated: 2025-10-01T19:26:38.622Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: Add rx_skb of kfree_skb to raw_tp_null_args[]. Yan Zhai reported a BPF prog could trigger a null-ptr-deref [0] in trace_kfree_skb if the prog does not check if rx_sk is NULL. Commit c53795d48ee8 ("net: add rx_sk to trace_kfree_skb") added rx_sk to trace_kfree_skb, but rx_sk is optional and could be NULL. Let's add kfree_skb to raw_tp_null_args[] to let the BPF verifier validate such a prog and prevent the issue. Now we fail to load such a prog: libbpf: prog 'drop'
to let the BPF verifier validate such a prog and prevent the issue. Now we fail to load such a prog: libbpf: prog 'drop': -- BEGIN PROG LOAD LOG -- 0: R1=ctx() R10=fp0 ; int BPF_PROG(drop, struct sk_buff *skb, void *location, @ kfree_skb_sk_null.bpf.c:21 0: (79) r3 = *(u64 *)(r1 +24) func 'kfree_skb' arg3 has btf_id 5253 type STRUCT 'sock' 1: R1=ctx() R3_w=trusted_ptr_or_null_sock(id=1) ; bpf_printk("sk: %d, %d\n", sk, sk->__sk_common.skc_family); @ kfree_skb_sk_null.bpf.c:24 1: (69) r4 = *(u16 *)(r3 +16) R3 invalid mem access 'trusted_ptr_or_null_' processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 -- END PROG LOAD LOG -- Note this fix requires
1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 -- END PROG LOAD LOG -- Note this fix requires commit 838a10bd2ebf ("bpf: Augment raw_tp arguments with PTR_MAYBE_NULL"). [0]: BUG: kernel NULL pointer dereference, address: 0000000000000010 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 PREEMPT SMP RIP: 0010:bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x148/0x420 ? search_bpf_extables+0x5b/0x70 ? fixup_exception+0x27/0x2c0 ? exc_page_fault+0x75/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d bpf_trace_run4+0x68/0xd0 ? unix_stream_connect+
asm_exc_page_fault+0x22/0x30 ? bpf_prog_5e21a6db8fcff1aa_drop+0x10/0x2d bpf_trace_run4+0x68/0xd0 ? unix_stream_connect+0x1f4/0x6f0 sk_skb_reason_drop+0x90/0x120 unix_stream_connect+0x1f4/0x6f0 __sys_connect+0x7f/0xb0 __x64_sys_connect+0x14/0x20 do_syscall_64+0x47/0xc30 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f579afacd0a66971fc8481f30d2d377e230a8342 - https://git.kernel.org/stable/c/4dba79c1e7aad6620bbb707b6c4459380fd90860 - https://git.kernel.org/stable/c/5da7e15fb5a12e78de974d8908f348e279922ce9
CVE ID: CVE-2025-21853 State: PUBLISHED Published: 2025-03-12T09:42:07.871Z Last Updated: 2025-11-03T19:38:09.374Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: avoid holding freeze_mutex during mmap operation We use map->freeze_mutex to prevent races between map_freeze() and memory mapping BPF map contents with writable permissions. The way we naively do this means we'll hold freeze_mutex for entire duration of all the mm and VMA manipulations, which is completely unnecessary. This can potentially also lead to deadlocks, as reported by syzbot in [0]. So, instead, hold freeze_mutex only during writeability checks, bump (p
lead to deadlocks, as reported by syzbot in [0]. So, instead, hold freeze_mutex only during writeability checks, bump (proactively) "write active" count for the map, unlock the mutex and proceed with mmap logic. And only if something went wrong during mmap logic, then undo that "write active" counter increment. [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/ Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2ce31c97c219b4fe797749f950274f246eb88c49 - https://git.kernel.org/stable/c/0d90d9e154144a3a80e9fc0eb9b21b7fc990f68f - https://git.kernel.org/stable/c/4759acbd44d24a69b7b14848012ec4201d6c5501 - https://git.kernel.
0e9fc0eb9b21b7fc990f68f - https://git.kernel.org/stable/c/4759acbd44d24a69b7b14848012ec4201d6c5501 - https://git.kernel.org/stable/c/29cfda62ab4d92ab94123813db49ab76c1e61b29 - https://git.kernel.org/stable/c/d95607a5f2f9bb08194c9deaf4a5f3e8ba59a9d4 - https://git.kernel.org/stable/c/271e49f8a58edba65bc2b1250a0abaa98c4bfdbe - https://git.kernel.org/stable/c/bc27c52eea189e8f7492d40739b7746d67b65beb
CVE ID: CVE-2025-21854 State: PUBLISHED Published: 2025-03-12T09:42:08.556Z Last Updated: 2025-10-01T19:26:38.493Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sockmap, vsock: For connectible sockets allow only connected sockmap expects all vsocks to have a transport assigned, which is expressed in vsock_proto::psock_update_sk_prot(). However, there is an edge case where an unconnected (connectible) socket may lose its previously assigned transport. This is handled with a NULL check in the vsock/BPF recv path. Another design detail is that listening vsocks are not supposed to have any transport assigned at all. Which implies
h. Another design detail is that listening vsocks are not supposed to have any transport assigned at all. Which implies they are not supported by the sockmap. But this is complicated by the fact that a socket, before switching to TCP_LISTEN, may have had some transport assigned during a failed connect() attempt. Hence, we may end up with a listening vsock in a sockmap, which blows up quickly: KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127] CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+ Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:vsock_read_skb+0x4b/0x90 Call Trace: sk_psock_verdict_data_ready+0xa4/0x2e0 virtio_transport_recv_pkt+0x1ca8/0x2a
: 0010:vsock_read_skb+0x4b/0x90 Call Trace: sk_psock_verdict_data_ready+0xa4/0x2e0 virtio_transport_recv_pkt+0x1ca8/0x2acc vsock_loopback_work+0x27d/0x3f0 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x35a/0x700 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 For connectible sockets, instead of relying solely on the state of vsk->transport, tell sockmap to only allow those representing established connections. This aligns with the behaviour for AF_INET and AF_UNIX. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cc9a7832ede53ade1ba9991f0e27314caa4029d8 - https://git.kernel.org/stable/c/22b683217ad2112791a708693cb236507ab
/stable/c/cc9a7832ede53ade1ba9991f0e27314caa4029d8 - https://git.kernel.org/stable/c/22b683217ad2112791a708693cb236507abd637a - https://git.kernel.org/stable/c/f7b473e35986835cc2813fef7b9d40336a09247e - https://git.kernel.org/stable/c/8fb5bb169d17cdd12c2dcc2e96830ed487d77a0f
CVE ID: CVE-2025-21855 State: PUBLISHED Published: 2025-03-12T09:42:09.251Z Last Updated: 2025-11-03T19:38:10.767Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Don't reference skb after sending to VIOS Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb. It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free: ======
tween reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014b
ad4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224 ================================================================== Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References
================================= Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/501ac6a7e21b82e05207c6b4449812d82820f306 - https://git.kernel.org/stable/c/093b0e5c90592773863f300b908b741622eef597 - https://git.kernel.org/stable/c/25dddd01dcc8ef3acff964dbb32eeb0d89f098e9 - https://git.kernel.org/stable/c/abaff2717470e4b5b7c0c3a90e128b211a23da09 - https://git.kernel.org/stable/c/bdf5d13aa05ec314d4385b31ac974d6c7e0997c9
CVE ID: CVE-2025-21856 State: PUBLISHED Published: 2025-03-12T09:42:09.929Z Last Updated: 2025-10-01T19:26:38.355Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390/ism: add release function for struct device According to device_release() in /drivers/base/core.c, a device without a release function is a broken device and must be fixed. The current code directly frees the device after calling device_add() without waiting for other kernel parts to release their references. Thus, a reference could still be held to a struct device, e.g., by sysfs, leading to potential use-after-free issues if a proper release function is not set.
to a struct device, e.g., by sysfs, leading to potential use-after-free issues if a proper release function is not set. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/940d15254d2216b585558bcf36312da50074e711 - https://git.kernel.org/stable/c/0505ff2936f166405d81d0d454a81d9c14124344 - https://git.kernel.org/stable/c/e26e8ac27351f457091459a0a355bacd06d5bb2b - https://git.kernel.org/stable/c/915e34d5ad35a6a9e56113f852ade4a730fb88f0