Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
k/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 4
0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969 RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268 </TASK> Additional Analyst Notes: - CVE Program Container: Refer
00000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268 </TASK> Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2919297b18e5a5fb7e643f9e32c12c0b17cce1be - https://git.kernel.org/stable/c/36af82f25fbdcd719eb947c15ea874bf80bcf229 - https://git.kernel.org/stable/c/d8cd847fb8626872631cc22d44be5127b4ebfb74 - https://git.kernel.org/stable/c/49b8a9d7d44401a186e20b1aaf591d2e62727aeb - https://git.kernel.org/stable/c/a060781640012d5d5105072f4c44ed6ad6830ef9 - https://git.kernel.org/stable/c/517bc6836ee9fcffe2539f6f6aa3fdd9c7a7ae73 - https://git.kernel.org/stable/c/f19cbd84e645e39bc3228e1191bb151ef0ffac8c - https://git.kernel.org/stable/c/6dbb0d97c50960
ttps://git.kernel.org/stable/c/f19cbd84e645e39bc3228e1191bb151ef0ffac8c - https://git.kernel.org/stable/c/6dbb0d97c5096072c78a6abffe393584e57ae945
CVE ID: CVE-2025-38325 State: PUBLISHED Published: 2025-07-10T08:14:59.544Z Last Updated: 2025-08-09T14:20:15.334Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: add free_transport ops in ksmbd connection free_transport function for tcp connection can be called from smbdirect. It will cause kernel oops. This patch add free_transport ops in ksmbd connection, and add each free_transports for tcp and smbdirect. References: - https://git.kernel.org/stable/c/52f5a52dc17a4a7b4363ac03fe2c4ef26f020dc6 - https://git.kernel.org/stable/c/3890da762a66191c440b0bd6e3ee45501edbb0c1 - https://git.kernel.org/stable/c/3f3aae77280aad9f5acc
/git.kernel.org/stable/c/3890da762a66191c440b0bd6e3ee45501edbb0c1 - https://git.kernel.org/stable/c/3f3aae77280aad9f5acc6709c596148966f765c7 - https://git.kernel.org/stable/c/a89f5fae998bdc4d0505306f93844c9ae059d50c
CVE ID: CVE-2025-38326 State: PUBLISHED Published: 2025-07-10T08:15:00.752Z Last Updated: 2025-11-03T17:36:37.143Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: aoe: clean device rq_list in aoedev_downdev() An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue(). Additiona
hose requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ed52e9652ba41d362e9ec923077f6da23336f269 - https://git.kernel.org/stable/c/64fc0bad62ed38874131dd0337d844a43bd1017e - https://git.kernel.org/stable/c/ef0b5bbbed7f220db2e9c73428f9a36e8dfc69ca - https://git.kernel.org/stable/c/531aef4a1accb13b21a3b82ec29955f4733367d5 - https://git.kernel.org/stable/c/8662ac79a63488e279b91c12a72b02bc0dc49f7b - https://git.kernel.org/stable/c/fa2a79f0da92614c5dc45c8b3d2638681c7734ee - https://git.kernel.org/stable/c/00be74e1470af292c37a438b8e69dee47dcbf481 -
/c/fa2a79f0da92614c5dc45c8b3d2638681c7734ee - https://git.kernel.org/stable/c/00be74e1470af292c37a438b8e69dee47dcbf481 - https://git.kernel.org/stable/c/7f90d45e57cb2ef1f0adcaf925ddffdfc5e680ca
CVE ID: CVE-2025-38327 State: PUBLISHED Published: 2025-07-10T08:15:01.577Z Last Updated: 2025-07-28T04:18:52.783Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fgraph: Do not enable function_graph tracer when setting funcgraph-args When setting the funcgraph-args option when function graph tracer is net enabled, it incorrectly enables it. Worse, it unregisters itself when it was never registered. Then when it gets enabled again, it will register itself a second time causing a WARNing. ~# echo 1 > /sys/kernel/tracing/options/funcgraph-args ~# head -20 /sys/kernel/tracing/trace # tracer: nop # # entries-in-buffer/entries-writte
/tracing/options/funcgraph-args ~# head -20 /sys/kernel/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 813/26317372 #P:8 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | <idle>-0 [007] d..4. 358.966010: 7) 1.692 us | fetch_next_timer_interrupt(basej=4294981640, basem=357956000000, base_local=0xffff88823c3ae040, base_global=0xffff88823c3af300, tevt=0xffff888100e47cb8); <idle>-0 [007] d..4. 358.966012: 7) | tmigr_cpu_deactivate(nextexp=357988000000) { <idle>-0 [007] d..4. 358.966013: 7) | _raw_spin_lock(lock
358.966012: 7) | tmigr_cpu_deactivate(nextexp=357988000000) { <idle>-0 [007] d..4. 358.966013: 7) | _raw_spin_lock(lock=0xffff88823c3b2320) { <idle>-0 [007] d..4. 358.966014: 7) 0.981 us | preempt_count_add(val=1); <idle>-0 [007] d..5. 358.966017: 7) 1.058 us | do_raw_spin_lock(lock=0xffff88823c3b2320); <idle>-0 [007] d..4. 358.966019: 7) 5.824 us | } <idle>-0 [007] d..5. 358.966021: 7) | tmigr_inactive_up(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) { <idle>-0 [007] d..5. 358.966022: 7) | tmigr_update_events(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) { Notice the "tracer: nop" at the top there. The current tracer is the "nop" tracer, but the content is o
f888100e47bc0) { Notice the "tracer: nop" at the top there. The current tracer is the "nop" tracer, but the content is obviously the function graph tracer. Enabling function graph tracing will cause it to register again and trigger a warning in the accounting: ~# echo function_graph > /sys/kernel/tracing/current_tracer -bash: echo: write error: Device or resource busy With the dmesg of: ------------[ cut here ]------------ WARNING: CPU: 7 PID: 1095 at kernel/trace/ftrace.c:3509 ftrace_startup_subops+0xc1e/0x1000 Modules linked in: kvm_intel kvm irqbypass CPU: 7 UID: 0 PID: 1095 Comm: bash Not tainted 6.16.0-rc2-test-00006-gea03de4105d3 #24 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9,
1095 Comm: bash Not tainted 6.16.0-rc2-test-00006-gea03de4105d3 #24 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ftrace_startup_subops+0xc1e/0x1000 Code: 48 b8 22 01 00 00 00 00 ad de 49 89 84 24 88 01 00 00 8b 44 24 08 89 04 24 e9 c3 f7 ff ff c7 04 24 ed ff ff ff e9 b7 f7 ff ff <0f> 0b c7 04 24 f0 ff ff ff e9 a9 f7 ff ff c7 04 24 f4 ff ff ff e9 RSP: 0018:ffff888133cff948 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 1ffff1102679ff31 RCX: 0000000000000000 RDX: 1ffffffff0b27a60 RSI: ffffffff8593d2f0 RDI: ffffffff85941140 RBP: 00000000000c2041 R08: ffffffffffffffff R09: ffffed1020240221 R10: ffff88810120110f R11: ffffed1020240214 R1
5941140 RBP: 00000000000c2041 R08: ffffffffffffffff R09: ffffed1020240221 R10: ffff88810120110f R11: ffffed1020240214 R12: ffffffff8593d2f0 R13: ffffffff8593d300 R14: ffffffff85941140 R15: ffffffff85631100 FS: 00007f7ec6f28740(0000) GS:ffff8882b5251000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7ec6f181c0 CR3: 000000012f1d0005 CR4: 0000000000172ef0 Call Trace: <TASK> ? __pfx_ftrace_startup_subops+0x10/0x10 ? find_held_lock+0x2b/0x80 ? ftrace_stub_direct_tramp+0x10/0x10 ? ftrace_stub_direct_tramp+0x10/0x10 ? trace_preempt_on+0xd0/0x110 ? __pfx_trace_graph_entry_args+0x10/ ---truncated--- References: - https://git.kernel.org/stable/c/300dedd9fe182d
/0x110 ? __pfx_trace_graph_entry_args+0x10/ ---truncated--- References: - https://git.kernel.org/stable/c/300dedd9fe182d4c7424550d81cee595994486d1 - https://git.kernel.org/stable/c/327e28664307d49ce3fa71ba30dcc0007c270974
CVE ID: CVE-2025-38328 State: PUBLISHED Published: 2025-07-10T08:15:02.296Z Last Updated: 2025-11-03T17:36:39.057Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jffs2: check jffs2_prealloc_raw_node_refs() result in few other places Fuzzing hit another invalid pointer dereference due to the lack of checking whether jffs2_prealloc_raw_node_refs() completed successfully. Subsequent logic implies that the node refs have been allocated. Handle that. The code is ready for propagating the error upwards. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-s
ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600 Call Trace: jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline] jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347 __generic_file_write_ite
_write_end+0x712/0x1110 fs/jffs2/file.c:302 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497 call_write_iter include/linux/fs.h:2039 [inline] do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740 do_iter_write+0x18c/0x710 fs/read_write.c:866 vfs_writev+0x1db/0x6a0 fs/read_write.c:939 do_pwritev fs/read_write.c:1036 [inline] __do_sys_pwritev fs/read_write.c:1083 [inline] __se_sys_pwritev fs/read_write.c:1078 [inline] __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verificatio
8 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7e860296d7808de1db175c1eda29f94a2955dcc4 - https://git.kernel.org/stable/c/d96e6451a8d0fe62492d4cc942d695772293c05a - https://git.kernel.org/stable/c/f41c625328777f9ad572901ba0b0065bb9c9c1da - https://git.kernel.org/stable/c/38d767fb4a7766ec2058f97787e4c6e8d10343d6 - https://git.kernel.org/stable/c/cd42ddddd70abc7127c12b96c8c85dbd080ea56f - https://git.kernel.org/stable/c/d1b81776f337a9b997f797c70ac0a26d838a2168 - https://git.kernel.or
12b96c8c85dbd080ea56f - https://git.kernel.org/stable/c/d1b81776f337a9b997f797c70ac0a26d838a2168 - https://git.kernel.org/stable/c/042fa922c84b5080401bcd8897d4ac4919d15075 - https://git.kernel.org/stable/c/2b6d96503255a3ed676cd70f8368870c6d6a25c6
CVE ID: CVE-2025-38329 State: PUBLISHED Published: 2025-07-10T08:15:02.930Z Last Updated: 2025-07-28T04:18:56.065Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Fix OOB memory read access in KUnit test (wmfw info) KASAN reported out of bounds access - cs_dsp_mock_wmfw_add_info(), because the source string length was rounded up to the allocation size. References: - https://git.kernel.org/stable/c/0000a2303ba78b6424ff15b5085b5f5098750a2e - https://git.kernel.org/stable/c/d979b783d61f7f1f95664031b71a33afc74627b2
CVE ID: CVE-2025-38330 State: PUBLISHED Published: 2025-07-10T08:15:03.579Z Last Updated: 2025-07-28T04:19:02.942Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Fix OOB memory read access in KUnit test (ctl cache) KASAN reported out of bounds access - cs_dsp_ctl_cache_init_multiple_offsets(). The code uses mock_coeff_template.length_bytes (4 bytes) for register value allocations. But later, this length is set to 8 bytes which causes test code failures. As fix, just remove the lenght override, keeping the original value 4 for all operations. References: - https://git.kernel.org/stable/c/e3dafc64b90546eb769f333
, keeping the original value 4 for all operations. References: - https://git.kernel.org/stable/c/e3dafc64b90546eb769f33333afabd9e3e915757 - https://git.kernel.org/stable/c/f4ba2ea57da51d616b689c4b8826c517ff5a8523
CVE ID: CVE-2025-38331 State: PUBLISHED Published: 2025-07-10T08:15:04.436Z Last Updated: 2025-11-03T17:36:39.991Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Use TOE/TSO on all TCP It is desireable to push the hardware accelerator to also process non-segmented TCP frames: we pass the skb->len to the "TOE/TSO" offloader and it will handle them. Without this quirk the driver becomes unstable and lock up and and crash. I do not know exactly why, but it is probably due to the TOE (TCP offload engine) feature that is coupled with the segmentation feature - it is not possible to turn one part off and not t
ffload engine) feature that is coupled with the segmentation feature - it is not possible to turn one part off and not the other, either both TOE and TSO are active, or neither of them. Not having the TOE part active seems detrimental, as if that hardware feature is not really supposed to be turned off. The datasheet says: "Based on packet parsing and TCP connection/NAT table lookup results, the NetEngine puts the packets belonging to the same TCP connection to the same queue for the software to process. The NetEngine puts incoming packets to the buffer or series of buffers for a jumbo packet. With this hardware acceleration, IP/TCP header parsing, checksum validation and connection lookup a
for a jumbo packet. With this hardware acceleration, IP/TCP header parsing, checksum validation and connection lookup are offloaded from the software processing." After numerous tests with the hardware locking up after something between minutes and hours depending on load using iperf3 I have concluded this is necessary to stabilize the hardware. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/1b503b790109d19710ec83c589c3ee59e95347ec - https://git.kernel.org/stable/c/a37888a435b0737128d2d9c6f67b8d608f83df7a - https://git.kernel.org/stable/c/2bd434bb0eeb680c2b3dd6c68ca319b30cb8d47f - https://git.kernel.org/stable/c/ebe12e232f1d58ebb4b53b6d91499
el.org/stable/c/2bd434bb0eeb680c2b3dd6c68ca319b30cb8d47f - https://git.kernel.org/stable/c/ebe12e232f1d58ebb4b53b6d9149962b707bed91 - https://git.kernel.org/stable/c/6a07e3af4973402fa199a80036c10060b922c92c
CVE ID: CVE-2025-38332 State: PUBLISHED Published: 2025-07-10T08:15:05.102Z Last Updated: 2025-11-03T17:36:41.860Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Use memcpy() for BIOS version The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in. Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated. BIOSVersion is only used for the lpfc_printf_log() which expects a properly terminated string. Additional Analyst Notes: - CVE Program
only used for the lpfc_printf_log() which expects a properly terminated string. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ac7bfaa099ec3e4d7dfd0ab9726fc3bc7911365d - https://git.kernel.org/stable/c/b699bda5db818b684ff62d140defd6394f38f3d6 - https://git.kernel.org/stable/c/d34f2384d6df11a6c67039b612c2437f46e587e8 - https://git.kernel.org/stable/c/75ea8375c5a83f46c47bfb3de6217c7589a8df93 - https://git.kernel.org/stable/c/34c0a670556b24d36c9f8934227edb819ca5609e - https://git.kernel.org/stable/c/2f63bf0d2b146956a2f2ff3b25cee71019e64561 - https://git.kernel.org/stable/c/003baa7a1a152576d744bd655820449bbdb0248e - https://git.kernel.org/stable/
e71019e64561 - https://git.kernel.org/stable/c/003baa7a1a152576d744bd655820449bbdb0248e - https://git.kernel.org/stable/c/ae82eaf4aeea060bb736c3e20c0568b67c701d7d
CVE ID: CVE-2025-38333 State: PUBLISHED Published: 2025-07-10T08:15:05.768Z Last Updated: 2025-07-28T04:19:07.525Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to bail out in get_new_segment() ------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thre
node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20 get_new_segment() detects inconsistent status in between free_segmap and free_secmap, let's record such error into super block, and bail out get_new_segment() instead of continue using the segment. References: - https://git.kernel.org/stable/c/f0023d7a2a86999c8e1300e911d92f995a5310a8 - https://git.kernel.org/stable/c/ca860f507a61c7c3d4dde47b830a5c0d555cf83c - https://git.kernel.org/stable/c/bb5eb8a5b222fa5092f60d5555867a05ebc3bdf2
CVE ID: CVE-2025-38334 State: PUBLISHED Published: 2025-07-10T08:15:06.380Z Last Updated: 2025-11-03T17:36:42.808Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Prevent attempts to reclaim poisoned pages TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages. The longer story: Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_l
s used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched. epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic. Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations ca
ncluding "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time. Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming. Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths. The affected EPC page is not added to &node->sgx_
so work but I assume it's better to add code in the less likely paths. The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a "TBD" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply. This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even *insid
previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even *inside* a microcode operation (actually easy to trigger due to the amount of time spent in them.) The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/00a88e9ea1b170d579c56327c38f7e8cf689df87 - https://git.kernel.org/stable/c/62b62a2a6dc51ed6e8e334861f04220c9cf8106a - https://git.kernel.org/stable/c/dc5de5bd6deabd327ced2b2b1d0b4f14cd146afe - https://git.kern
d6e8e334861f04220c9cf8106a - https://git.kernel.org/stable/c/dc5de5bd6deabd327ced2b2b1d0b4f14cd146afe - https://git.kernel.org/stable/c/31dcbac94bfeabb86bf85b0c36803fdd6536437b - https://git.kernel.org/stable/c/ed16618c380c32c68c06186d0ccbb0d5e0586e59
CVE ID: CVE-2025-38335 State: PUBLISHED Published: 2025-07-10T08:15:07.063Z Last Updated: 2025-11-03T17:36:43.814Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in hard irq context, but the input_event() takes a spin_lock, which isn't allowed there as it is converted to a rt_spin_lock(). [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_re
8 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209] rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257] hrtimer_interrupt+0xe4/0x240 [ 4054.290269] arch_timer_handler_phys+0x2c/0x44 [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58 [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316] gic_handle_irq+0x44/0xcc Considering the gpio_keys_irq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requ