Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
/options.c:982 [inline] RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:
0 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: <IRQ> tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432 tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975 tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166 tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925 tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363 ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233 NF_HOOK incl
_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:469 [inline] ip_rcv_finish net/ipv4/ip_input.c:447 [inline] NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975 __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi
/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi_poll net/core/dev.c:7517 [inline] net_rx_action+0xb44/0x1010 net/core/dev.c:7644 handle_softirqs+0x1d0/0x770 kernel/softirq.c:579 do_softirq+0x3f/0x90 kernel/softirq.c:480 </IRQ> <TASK> __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407 local_bh_enable include/linux/bottom_half.h:33 [inline] inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524 mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcp_check_listen_stop net/mptcp/mib.h:118 [inline] __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140 net/mptcp/protoc
net/mptcp/mib.h:118 [inline] __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066 inet_release+0xed/0x200 net/ipv4/af_inet.c:435 inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x402/0xb70 fs/file_table.c:465 task_work_run+0x150/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xd4 ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5586518bec27666c747cd52aabb62d485686d0bf - https://git.kernel.org/stable/c/75a4c9ab8a7af0d76b31cc
it.kernel.org/stable/c/5586518bec27666c747cd52aabb62d485686d0bf - https://git.kernel.org/stable/c/75a4c9ab8a7af0d76b31ccd1188ed178c38b35d2 - https://git.kernel.org/stable/c/54999dea879fecb761225e28f274b40662918c30 - https://git.kernel.org/stable/c/1d82a8fe6ee4afdc92f4e8808c9dad2a6095bbc5 - https://git.kernel.org/stable/c/f8a1d9b18c5efc76784f5a326e905f641f839894
CVE ID: CVE-2025-38492 State: PUBLISHED Published: 2025-07-28T11:22:01.017Z Last Updated: 2025-07-28T11:22:01.017Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfs: Fix race between cache write completion and ALL_QUEUED being set When netfslib is issuing subrequests, the subrequests start processing immediately and may complete before we reach the end of the issuing function. At the end of the issuing function we set NETFS_RREQ_ALL_QUEUED to indicate to the collector that we aren't going to issue any more subreqs and that it can do the final notifications and cleanup. Now, this isn't a problem if the request is synchronous
subreqs and that it can do the final notifications and cleanup. Now, this isn't a problem if the request is synchronous (NETFS_RREQ_OFFLOAD_COLLECTION is unset) as the result collection will be done in-thread and we're guaranteed an opportunity to run the collector. However, if the request is asynchronous, collection is primarily triggered by the termination of subrequests queuing it on a workqueue. Now, a race can occur here if the app thread sets ALL_QUEUED after the last subrequest terminates. This can happen most easily with the copy2cache code (as used by Ceph) where, in the collection routine of a read request, an asynchronous write request is spawned to copy data to the cache. Folios
in the collection routine of a read request, an asynchronous write request is spawned to copy data to the cache. Folios are added to the write request as they're unlocked, but there may be a delay before ALL_QUEUED is set as the write subrequests may complete before we get there. If all the write subreqs have finished by the ALL_QUEUED point, no further events happen and the collection never happens, leaving the request hanging. Fix this by queuing the collector after setting ALL_QUEUED. This is a bit heavy-handed and it may be sufficient to do it only if there are no extant subreqs. Also add a tracepoint to cross-reference both requests in a copy-to-request operation and add a trace to the
t subreqs. Also add a tracepoint to cross-reference both requests in a copy-to-request operation and add a trace to the netfs_rreq tracepoint to indicate the setting of ALL_QUEUED. References: - https://git.kernel.org/stable/c/110188a13c4853bd4c342e600ced4dfd26c3feb5 - https://git.kernel.org/stable/c/89635eae076cd8eaa5cb752f66538c9dc6c9fdc3
CVE ID: CVE-2025-38493 State: PUBLISHED Published: 2025-07-28T11:22:02.000Z Last Updated: 2025-07-28T11:22:02.000Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing/osnoise: Fix crash in timerlat_dump_stack() We have observed kernel panics when using timerlat with stack saving, with the following dmesg output: memcpy: detected buffer overflow: 88 byte write of buffer size 0 WARNING: CPU: 2 PID: 8153 at lib/string_helpers.c:1032 __fortify_report+0x55/0xa0 CPU: 2 UID: 0 PID: 8153 Comm: timerlatu/2 Kdump: loaded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: <TASK> ? trace_buffer_lock_reserve+0x2a/0x60 __fort
aded Not tainted 6.15.3-200.fc42.x86_64 #1 PREEMPT(lazy) Call Trace: <TASK> ? trace_buffer_lock_reserve+0x2a/0x60 __fortify_panic+0xd/0xf __timerlat_dump_stack.cold+0xd/0xd timerlat_dump_stack.part.0+0x47/0x80 timerlat_fd_read+0x36d/0x390 vfs_read+0xe2/0x390 ? syscall_exit_to_user_mode+0x1d5/0x210 ksys_read+0x73/0xe0 do_syscall_64+0x7b/0x160 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e __timerlat_dump_stack() constructs the ftrace stack entry like this: struct stack_entry *entry; ... memcpy(&entry->caller, fstack->calls, size); entry->size = fstack->nr_entries; Since commit e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure"), struct
nr_entries; Since commit e7186af7fb26 ("tracing: Add back FORTIFY_SOURCE logic to kernel_stack event structure"), struct stack_entry marks its caller field with __counted_by(size). At the time of the memcpy, entry->size contains garbage from the ringbuffer, which under some circumstances is zero, triggering a kernel panic by buffer overflow. Populate the size field before the memcpy so that the out-of-bounds check knows the correct size. This is analogous to __ftrace_trace_stack(). References: - https://git.kernel.org/stable/c/823d798900481875ba6c68217af028c5ffd2976b - https://git.kernel.org/stable/c/7bb9ea515cda027c9e717e27fefcf34f092e7c41 - https://git.kernel.org/stable/c/fbf90f5aa7ac7cddc
s://git.kernel.org/stable/c/7bb9ea515cda027c9e717e27fefcf34f092e7c41 - https://git.kernel.org/stable/c/fbf90f5aa7ac7cddc69148a71d58f12c8709ce2b - https://git.kernel.org/stable/c/85a3bce695b361d85fc528e6fbb33e4c8089c806
CVE ID: CVE-2025-38494 State: PUBLISHED Published: 2025-07-28T11:22:03.180Z Last Updated: 2025-11-03T17:39:01.805Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: core: do not bypass hid_hw_raw_request hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/dd8e8314f2ce225dade5248dcfb9e2ac0edda624 - https://git.kernel.org/stable/c/40e25aa7e4e0f2440c73a683ee448e41c7c344ed - htt
d8e8314f2ce225dade5248dcfb9e2ac0edda624 - https://git.kernel.org/stable/c/40e25aa7e4e0f2440c73a683ee448e41c7c344ed - https://git.kernel.org/stable/c/f10923b8d32a473b229477b63f23bbd72b1e9910 - https://git.kernel.org/stable/c/a62a895edb2bfebffa865b5129a66e3b4287f34f - https://git.kernel.org/stable/c/0e5017d84d650ca0eeaf4a3fe9264c5dbc886b81 - https://git.kernel.org/stable/c/d18f63e848840100dbc351a82e7042eac5a28cf5 - https://git.kernel.org/stable/c/19d1314d46c0d8a5c08ab53ddeb62280c77698c0 - https://git.kernel.org/stable/c/c2ca42f190b6714d6c481dfd3d9b62ea091c946b
CVE ID: CVE-2025-38495 State: PUBLISHED Published: 2025-07-28T11:22:04.169Z Last Updated: 2025-11-03T17:39:03.891Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: core: ensure the allocated report buffer can contain the reserved report ID When the report ID is not used, the low level transport drivers expect the first byte to be 0. However, currently the allocated buffer not account for that extra byte, meaning that instead of having 8 guaranteed bytes for implement to be working, we only have 7. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7228e36c7875e4b035374cf68ca5e44d
l Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7228e36c7875e4b035374cf68ca5e44dffa596b2 - https://git.kernel.org/stable/c/9f2892f7233a8f1320fe671d0f95f122191bfbcd - https://git.kernel.org/stable/c/7fa83d0043370003e9a0b46ab7ae8f53b00fab06 - https://git.kernel.org/stable/c/d3ed1d84a84538a39b3eb2055d6a97a936c108f2 - https://git.kernel.org/stable/c/fcda39a9c5b834346088c14b1374336b079466c1 - https://git.kernel.org/stable/c/a262370f385e53ff7470efdcdaf40468e5756717 - https://git.kernel.org/stable/c/a47d9d9895bad9ce0e840a39836f19ca0b2a343a - https://git.kernel.org/stable/c/4f15ee98304b96e164ff2340e1dfd6181c3f42aa
CVE ID: CVE-2025-38496 State: PUBLISHED Published: 2025-07-28T11:22:05.091Z Last Updated: 2025-07-28T11:22:05.091Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm-bufio: fix sched in atomic context If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP is enabled for dm-bufio. However, when bufio tries to evict buffers, there is a chance to trigger scheduling in spin_lock_bh, the following warning is hit: BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth
tomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT
at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dm_bufio_cache do_global_cleanup Call Trace: <TASK> dump_stack_lvl+0x53/0x70 __might_resched+0x360/0x4e0 do_global_cleanup+0x2f5/0x710 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0xf3/0x1b0 ret_from_fork_asm+0x1a/0x30 </TASK> That can be reproduced by: veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -
ata-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 <data_blocks> 1 sha256 <root_hash> <salt> 1 try_verify_in_tasklet" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes [read files in /mnt] References: - https://git.kernel.org/stable/c/469a39a33a9934af157299bf11c58f6e6cb53f85 - https://git.kernel.org/stable/c/68860d1ade385eef9fcdbf6552f061283091fdb8 - https://git.kernel.org/stable/c/3edfdb1d4ef81320dae0caa40bc24baf8c1bbb86 - https://git.kernel.org/stable/c/b1bf1a782fdf5c482215c0c661b5da98b8e75773
CVE ID: CVE-2025-38497 State: PUBLISHED Published: 2025-07-28T11:22:05.855Z Last Updated: 2025-11-03T17:39:05.811Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Fix OOB read on empty string write When writing an empty string to either 'qw_sign' or 'landingPage' sysfs attributes, the store functions attempt to access page[l - 1] before validating that the length 'l' is greater than zero. This patch fixes the vulnerability by adding a check at the beginning of os_desc_qw_sign_store() and webusb_landingPage_store() to handle the zero-length input case gracefully by returning immediately. Additional Analyst
webusb_landingPage_store() to handle the zero-length input case gracefully by returning immediately. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/78b41148cfea2a3f04d87adf3a71b21735820a37 - https://git.kernel.org/stable/c/d68b7c8fefbaeae8f065b84e40cf64baf4cc0c76 - https://git.kernel.org/stable/c/15a87206879951712915c03c8952a73d6a74721e - https://git.kernel.org/stable/c/2798111f8e504ac747cce911226135d50b8de468 - https://git.kernel.org/stable/c/58bdd5160184645771553ea732da5c2887fc9bd1 - https://git.kernel.org/stable/c/783ea37b237a9b524f1e5ca018ea17d772ee0ea0 - https://git.kernel.org/stable/c/22b7897c289cc25d99c603f5144096142a30d897 - https://g
b237a9b524f1e5ca018ea17d772ee0ea0 - https://git.kernel.org/stable/c/22b7897c289cc25d99c603f5144096142a30d897 - https://git.kernel.org/stable/c/3014168731b7930300aab656085af784edc861f6
CVE ID: CVE-2025-38498 State: PUBLISHED Published: 2025-07-30T06:03:36.483Z Last Updated: 2025-11-03T17:39:07.695Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: do_change_type(): refuse to operate on unmounted/not ours mounts Ensure that propagation settings can only be changed for mounts located in the caller's mount namespace. This change aligns permission checking with the rest of mount(2). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/787937c4e373f1722c4343e5a5a4eb0f8543e589 - https://git.kernel.org/stable/c/c7d11fdf8e5db5f34a6c062c7e6ba3a0971879d2 - https://git.kernel.org
43e5a5a4eb0f8543e589 - https://git.kernel.org/stable/c/c7d11fdf8e5db5f34a6c062c7e6ba3a0971879d2 - https://git.kernel.org/stable/c/432a171d60056489270c462e651e6c3a13f855b1 - https://git.kernel.org/stable/c/064014f7812744451d5d0592f3d2bcd727f2ee93 - https://git.kernel.org/stable/c/4f091ad0862b02dc42a19a120b7048de848561f8 - https://git.kernel.org/stable/c/9c1ddfeb662b668fff69c5f1cfdd9f5d23d55d23 - https://git.kernel.org/stable/c/19554c79a2095ddde850906a067915c1ef3a4114 - https://git.kernel.org/stable/c/12f147ddd6de7382dad54812e65f3f08d05809fc
CVE ID: CVE-2025-38499 State: PUBLISHED Published: 2025-08-11T16:01:08.257Z Last Updated: 2025-11-03T17:39:08.627Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN c
ongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/36fecd740de2d542d2091d65d36554ee2bcf9c65 - https://git.kernel.org/stable/c/d717325b5ecf2a40daca85c61923e17f32306179 - https://git.kernel.org/stable/c/dc6a664089f10eab0fb36b6e4f705022210191d2 - https://git.kernel.org/stable/c/e77078e52fbf018ab986efb3c79065ab3502
stable/c/dc6a664089f10eab0fb36b6e4f705022210191d2 - https://git.kernel.org/stable/c/e77078e52fbf018ab986efb3c79065ab35025607 - https://git.kernel.org/stable/c/38628ae06e2a37770cd794802a3f1310cf9846e3 - https://git.kernel.org/stable/c/c28f922c9dcee0e4876a2c095939d77fe7e15116
CVE ID: CVE-2025-38500 State: PUBLISHED Published: 2025-08-12T16:02:42.363Z Last Updated: 2025-11-03T17:39:09.573Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xfrm: interface: fix use-after-free after changing collect_md xfrm interface collect_md property on xfrm interfaces can only be set on device creation, thus xfrmi_changelink() should fail when called on such interfaces. The check to enforce this was done only in the case where the xi was returned from xfrmi_locate() which doesn't look for the collect_md interface, and thus the validation was never reached. Calling changelink would thus errornously place the special int
md interface, and thus the validation was never reached. Calling changelink would thus errornously place the special interface xi in the xfrmi_net->xfrmi hash, but since it also exists in the xfrmi_net->collect_md_xfrmi pointer it would lead to a double free when the net namespace was taken down [1]. Change the check to use the xi from netdev_priv which is available earlier in the function to prevent changes in xfrm collect_md interfaces. [1] resulting oops: [ 8.516540] kernel BUG at net/core/dev.c:12029! [ 8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary) [ 8.516565] Hardware name: QEMU U
: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary) [ 8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 8.516569] Workqueue: netns cleanup_net [ 8.516579] RIP: 0010:unregister_netdevice_many_notify+0x101/0xab0 [ 8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24 [ 8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206 [ 8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60 [ 8.516601] RDX: 0000000000000004 RSI: 0000000000
598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60 [ 8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122 [ 8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100 [ 8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00 [ 8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00 [ 8.516615] FS: 0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000 [ 8.516619] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0 [ 8.516625] PKRU: 55555554 [ 8.516627] Call Trace: [ 8.516632] <TASK> [ 8.516635] ? rtnl_i
aa40000 CR4: 0000000000752ef0 [ 8.516625] PKRU: 55555554 [ 8.516627] Call Trace: [ 8.516632] <TASK> [ 8.516635] ? rtnl_is_locked+0x15/0x20 [ 8.516641] ? unregister_netdevice_queue+0x29/0xf0 [ 8.516650] ops_undo_list+0x1f2/0x220 [ 8.516659] cleanup_net+0x1ad/0x2e0 [ 8.516664] process_one_work+0x160/0x380 [ 8.516673] worker_thread+0x2aa/0x3c0 [ 8.516679] ? __pfx_worker_thread+0x10/0x10 [ 8.516686] kthread+0xfb/0x200 [ 8.516690] ? __pfx_kthread+0x10/0x10 [ 8.516693] ? __pfx_kthread+0x10/0x10 [ 8.516697] ret_from_fork+0x82/0xf0 [ 8.516705] ? __pfx_kthread+0x10/0x10 [ 8.516709] ret_from_fork_asm+0x1a/0x30 [ 8.516718] </TASK> Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Contain
ret_from_fork_asm+0x1a/0x30 [ 8.516718] </TASK> Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a8d4748b954584ab7bd800f1a4e46d5b0eeb5ce4 - https://git.kernel.org/stable/c/bfebdb85496e1da21d3cf05de099210915c3e706 - https://git.kernel.org/stable/c/5918c3f4800a3aef2173865e5903370f21e24f47 - https://git.kernel.org/stable/c/69a31f7a6a81f5ffd3812c442e09ff0be22960f1 - https://git.kernel.org/stable/c/a90b2a1aaacbcf0f91d7e4868ad6c51c5dee814b
CVE ID: CVE-2025-38501 State: PUBLISHED Published: 2025-08-16T05:30:09.138Z Last Updated: 2025-11-04T21:10:11.398Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: limit repeated connections from clients with the same IP Repeated connections from clients with the same IP address may exhaust the max connections and prevent other normal client connections. This patch limit repeated connections from clients with the same IP. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cb092fc3a62972a4aa47c9fe356c2c6a01cd840b - https://git.kernel.org/stable/c/fa1c47a
es: - https://git.kernel.org/stable/c/cb092fc3a62972a4aa47c9fe356c2c6a01cd840b - https://git.kernel.org/stable/c/fa1c47af4ff641cf9197ecdb1f8240cbb30389c1 - https://git.kernel.org/stable/c/7e5d91d3e6c62a9755b36f29c35288f06c3cd86b - https://git.kernel.org/stable/c/f1ce9258bcbce2491f9f71f7882b6eed0b33ec65 - https://git.kernel.org/stable/c/6073afe64510c302b7a0683a01e32c012eff715d - https://git.kernel.org/stable/c/e6bb9193974059ddbb0ce7763fa3882bd60d4dc3
CVE ID: CVE-2025-38502 State: PUBLISHED Published: 2025-08-16T09:34:25.135Z Last Updated: 2025-11-03T17:39:11.518Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix oob access in cgroup local storage Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any