Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-38613 State: PUBLISHED Published: 2025-08-19T17:03:55.457Z Last Updated: 2025-09-29T05:54:47.581Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: gpib: fix unset padding field copy back to userspace The introduction of a padding field in the gpib_board_info_ioctl is showing up as initialized data on the stack frame being copyied back to userspace in function board_info_ioctl. The simplest fix is to initialize the entire struct to zero to ensure all unassigned padding fields are zero'd before being copied back to userspace. References: - https://git.kernel.org/stable/c/19dedd4f70f5a6505e7c601ef7dd40542d1
before being copied back to userspace. References: - https://git.kernel.org/stable/c/19dedd4f70f5a6505e7c601ef7dd40542d1d9aa5 - https://git.kernel.org/stable/c/a739d3b13bff0dfa1aec679d08c7062131a2a425
CVE ID: CVE-2025-38614 State: PUBLISHED Published: 2025-08-19T17:03:56.348Z Last Updated: 2025-11-03T17:40:26.593Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: eventpoll: Fix semi-unbounded recursion Ensure that epoll instances can never form a graph deeper than EP_MAX_NESTS+1 links. Currently, ep_loop_check_proc() ensures that the graph is loop-free and does some recursion depth checks, but those recursion depth checks don't limit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered fo
the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths"). Essentially, the current recursion depth check in ep_loop_check_proc() just serves to prevent it from recursing too deeply while checking for loops. A more thorough check is done in reverse_path_check() after the new graph edge has already been created; this checks, among other things, that no paths going upwards from any non-epoll file with a length of more than 5 edges exist. However, this check does not apply to non-epoll files. As a result, it is possible to recurse to a depth of at least roughly 500, t
is check does not apply to non-epoll files. As a result, it is possible to recurse to a depth of at least roughly 500, tested on v6.15. (I am unsure if deeper recursion is possible; and this may have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion problem").) To fix it: 1. In ep_loop_check_proc(), note the subtree depth of each visited node, and use subtree depths for the total depth calculation even when a subtree has already been visited. 2. Add ep_get_upwards_depth_proc() for similarly determining the maximum depth of an upwards walk. 3. In ep_loop_check(), use these values to limit the total path length between epoll nodes to EP_MAX_NESTS edges. Additional Analyst No
heck(), use these values to limit the total path length between epoll nodes to EP_MAX_NESTS edges. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/71379495ab70eaba19224bd71b5b9b399eb85e04 - https://git.kernel.org/stable/c/1b13b033062824495554e836a1ff5f85ccf6b039 - https://git.kernel.org/stable/c/2a0c0c974bea9619c6f41794775ae4b97530e0e6 - https://git.kernel.org/stable/c/7a2125962c42d5336ca0495a9ce4cb38a63e9161 - https://git.kernel.org/stable/c/ea5f97dbdcb1651581a22bd10afd2f0dd9dc11d6 - https://git.kernel.org/stable/c/3542c90797bc3ab83ebab54b737d751cf3682036 - https://git.kernel.org/stable/c/f2e467a48287c868818085aa35389a224d226732
CVE ID: CVE-2025-38615 State: PUBLISHED Published: 2025-08-19T17:03:57.164Z Last Updated: 2025-09-29T05:54:50.014Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: cancle set bad inode after removing name fails The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted. The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - t
node, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles". References: - https://git.kernel.org/stable/c/b35a50d639ca5259466ef5fea85529bb4fb17d5b - https://git.kernel.org/stable/c/3ed2cc6a6e93fbeb8c0cafce1e7fb1f64a331dcc - https://git.kernel.org/stable/c/358d4f821c03add421a4c49290538a705852ccf1 - https://git.kernel.org/stable/c/a285395020780adac1ffbc844069c3d700bf007a - https://git.kernel.org/stab
0538a705852ccf1 - https://git.kernel.org/stable/c/a285395020780adac1ffbc844069c3d700bf007a - https://git.kernel.org/stable/c/d99208b91933fd2a58ed9ed321af07dacd06ddc3
CVE ID: CVE-2025-38616 State: PUBLISHED Published: 2025-08-22T13:01:23.217Z Last Updated: 2025-09-29T05:54:51.143Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tls: handle data disappearing from under the TLS ULP TLS expects that it owns the receive queue of the TCP socket. This cannot be guaranteed in case the reader of the TCP socket entered before the TLS ULP was installed, or uses some non-standard read API (eg. zerocopy ones). Replace the WARN_ON() and a buggy early exit (which leaves anchor pointing to a freed skb) with real error handling. Wipe the parsing state and tell the reader to retry. We already reload the ancho
a freed skb) with real error handling. Wipe the parsing state and tell the reader to retry. We already reload the anchor every time we (re)acquire the socket lock, so the only condition we need to avoid is an out of bounds read (not having enough bytes in the socket for previously parsed record len). If some data was read from under TLS but there's enough in the queue we'll reload and decrypt what is most likely not a valid TLS record. Leading to some undefined behavior from TLS perspective (corrupting a stream? missing an alert? missing an attack?) but no kernel crash should take place. References: - https://git.kernel.org/stable/c/f1fe99919f629f980d0b8a7ff16950bffe06a859 - https://git.ker
uld take place. References: - https://git.kernel.org/stable/c/f1fe99919f629f980d0b8a7ff16950bffe06a859 - https://git.kernel.org/stable/c/eb0336f213fe88bbdb7d2b19c9c9ec19245a3155 - https://git.kernel.org/stable/c/db3658a12d5ec4db7185ae7476151a50521b7207 - https://git.kernel.org/stable/c/2fb97ed9e2672b4f6e24ce206ac1a875ce4bcb38 - https://git.kernel.org/stable/c/6db015fc4b5d5f63a64a193f65d98da3a7fc811d
CVE ID: CVE-2025-38617 State: PUBLISHED Published: 2025-08-22T13:01:23.963Z Last Updated: 2025-11-03T17:40:28.543Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/packet: fix a race in packet_set_ring() and packet_notifier() When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event. This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()"). There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was si
NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken. The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/18f13f2a83eb81be349a9757ba2141ff1da9ad73 - https://git.kernel.org/stable/c/7da733f117533e9b2ebbd530a22ae4028713955c - https://git.kernel.org/stable/c/ba2257034755ae773722f15f4c3ad1dcdad15ca9 - https://git.kernel.org/stable/c/7de07705007c7e34995a5599aaab1d23e762d7ca - https://git.kernel.
722f15f4c3ad1dcdad15ca9 - https://git.kernel.org/stable/c/7de07705007c7e34995a5599aaab1d23e762d7ca - https://git.kernel.org/stable/c/88caf46db8239e6471413d28aabaa6b8bd552805 - https://git.kernel.org/stable/c/f2e8fcfd2b1bc754920108b7f2cd75082c5a18df - https://git.kernel.org/stable/c/e50ccfaca9e3c671cae917dcb994831a859cf588 - https://git.kernel.org/stable/c/f1791fd7b845bea0ce9674fcf2febee7bc87a893 - https://git.kernel.org/stable/c/01d3c8417b9c1b884a8a981a3b886da556512f36
CVE ID: CVE-2025-38618 State: PUBLISHED Published: 2025-08-22T13:01:24.678Z Last Updated: 2025-11-03T17:40:30.483Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vsock: Do not allow binding to VMADDR_PORT_ANY It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDR_PORT_ANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction). Modify the check in __vsock_bind_con
o the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction). Modify the check in __vsock_bind_connectible() to also prevent binding to VMADDR_PORT_ANY. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c04a2c1ca25b9b23104124d3b2d349d934e302de - https://git.kernel.org/stable/c/d1a5b1964cef42727668ac0d8532dae4f8c19386 - https://git.kernel.org/stable/c/cf86704798c1b9c46fa59dfc2d662f57d1394d79 - https://git.kernel.org/stable/c/f138be5d7f301fddad4e65ec66dfc3ceebf79be3 - https://git.kernel.org/stable/c/44bd006d5c93f6a8f28b106cbae2428c5d0275b7 - https://git.kernel.org/stable/c/32950b1907919be86a7a2697d6f93d57068b3865 - https://gi
5c93f6a8f28b106cbae2428c5d0275b7 - https://git.kernel.org/stable/c/32950b1907919be86a7a2697d6f93d57068b3865 - https://git.kernel.org/stable/c/8f01093646b49f6330bb2d36761983fd829472b1 - https://git.kernel.org/stable/c/d73960f0cf03ef1dc9e96ec7a20e538accc26d87 - https://git.kernel.org/stable/c/aba0c94f61ec05315fa7815d21aefa4c87f6a9f4
CVE ID: CVE-2025-38619 State: PUBLISHED Published: 2025-08-22T16:00:23.564Z Last Updated: 2025-09-29T05:54:54.550Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: ti: j721e-csi2rx: fix list_del corruption If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue. This causes the same buffer to be retried in the next iteration, resulting in a double list_del() and eventual list corruption. Fix this by removing the buffer from the queue before calling vb2_buffer_done() on error. This resolves a crash due to list_del corruption: [ 37.8
uffer from the queue before calling vb2_buffer_done() on error. This resolves a crash due to list_del corruption: [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048 [ 37.839761] list_del corruption. next->prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428) [ 37.850799] ------------[ cut here ]------------ [ 37.855424] kernel BUG at lib/list_debug.c:65! [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce
] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT) [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114 [ 37.914059] sp : ffff800080003db0 [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000 [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead
080003db0 x28: 0000000000000007 x27: ffff800080e50000 [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122 [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0 [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720 [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568 [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000 [ 37.981686] x
7fe8 x6 : c0000000ffffefff [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000 [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d [ 37.988832] Call trace: [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P) [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4 [ 38.001419] udma_vchan_complete+0x1e0/0x344 [ 38.005705] tasklet_action_common+0x118/0x310 [ 38.010163] tasklet_action+0x30/0x3c [ 38.013832] handle_softirqs+0x10c/0x2e0 [ 38.017761] __do_softirq+0x14/0x20 [ 38.021256] ____do_softirq+0x10/0x20 [ 38.024931] call_on_irq_stack+0x24/0x60 [ 38.028873] do_softirq_own_stack+0x1c/0x40 [ 38.033064] __irq_exit_rcu+0x130/0x15c [ 38.036909]
_on_irq_stack+0x24/0x60 [ 38.028873] do_softirq_own_stack+0x1c/0x40 [ 38.033064] __irq_exit_rcu+0x130/0x15c [ 38.036909] irq_exit_rcu+0x10/0x20 [ 38.040403] el1_interrupt+0x38/0x60 [ 38.043987] el1h_64_irq_handler+0x18/0x24 [ 38.048091] el1h_64_irq+0x6c/0x70 [ 38.051501] default_idle_call+0x34/0xe0 (P) [ 38.055783] do_idle+0x1f8/0x250 [ 38.059021] cpu_startup_entry+0x34/0x3c [ 38.062951] rest_init+0xb4/0xc0 [ 38.066186] console_on_rootfs+0x0/0x6c [ 38.070031] __primary_switched+0x88/0x90 [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000) [ 38.080168] ---[ end trace 0000000000000000 ]--- [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 38.0921
trace 0000000000000000 ]--- [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt [ 38.092197] SMP: stopping secondary CPUs [ 38.096139] Kernel Offset: disabled [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b [ 38.105202] Memory Limit: none [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]--- References: - https://git.kernel.org/stable/c/68e5579f4de12207b23c41b44a4c0778b6c2858f - https://git.kernel.org/stable/c/92d0188f36ca8082af7989d743eb5b44c2d259f7 - https://git.kernel.org/stable/c/a4a8cb0889927d59ebd839458c8f038bc5298ef9 - https://git.kernel.org/stable/c/ae42c6fe531425ef2f47e82f96851427d24bbf6b
CVE ID: CVE-2025-38620 State: PUBLISHED Published: 2025-08-22T16:00:24.445Z Last Updated: 2025-09-29T05:54:55.708Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: zloop: fix KASAN use-after-free of tag set When a zoned loop device, or zloop device, is removed, KASAN enabled kernel reports "BUG KASAN use-after-free" in blk_mq_free_tag_set(). The BUG happens because zloop_ctl_remove() calls put_disk(), which invokes zloop_free_disk(). The zloop_free_disk() frees the memory allocated for the zlo pointer. However, after the memory is freed, zloop_ctl_remove() calls blk_mq_free_tag_set(&zlo->tag_set), which accesses the freed zlo. He
after the memory is freed, zloop_ctl_remove() calls blk_mq_free_tag_set(&zlo->tag_set), which accesses the freed zlo. Hence the KASAN use-after-free. zloop_ctl_remove() put_disk(zlo->disk) put_device() kobject_put() ... zloop_free_disk() kvfree(zlo) blk_mq_free_tag_set(&zlo->tag_set) To avoid the BUG, move the call to blk_mq_free_tag_set(&zlo->tag_set) from zloop_ctl_remove() into zloop_free_disk(). This ensures that the tag_set is freed before the call to kvfree(zlo). References: - https://git.kernel.org/stable/c/c7c87046b41a9ef28ee7ac476c369da5b5228bc5 - https://git.kernel.org/stable/c/765761851d89c772f482494d452e266795460278
CVE ID: CVE-2025-38621 State: PUBLISHED Published: 2025-08-22T16:00:30.308Z Last Updated: 2025-09-29T05:54:56.808Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: make rdev_addable usable for rcu mode Our testcase trigger panic: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: <TASK> md_start_sync+0x329/0x480 process_one_work+0x226/0x
d_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: <TASK> md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0 md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive. References: - ht
ize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive. References: - https://git.kernel.org/stable/c/b5fbe940862339cdcc34dea7a057ad18d18fa137 - https://git.kernel.org/stable/c/13017b427118f4311471ee47df74872372ca8482
CVE ID: CVE-2025-38622 State: PUBLISHED Published: 2025-08-22T16:00:31.343Z Last Updated: 2025-11-03T17:40:32.369Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: drop UFO packets in udp_rcv_segment() When sending a packet with virtio_net_hdr to tun device, if the gso_type in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr size, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIO
2 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000
000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: <TASK> udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x7
6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 </TASK> To trigger gso segment in udp_qu
xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 </TASK> To trigger gso segment in udp_queue_rcv_skb(), we should also set option UDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcv hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try to pull udphdr, but the skb size has been segmented to gso size, which leads to this crash. Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection") introduces segmentation in UDP receive path only for GRO, which was never intended to be used for UFO, so drop UFO packets in udp_rcv_segment(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kern
drop UFO packets in udp_rcv_segment(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/72f97d3cb791e26492236b2be7fd70d2c6222555 - https://git.kernel.org/stable/c/df6ad849d59256dcc0e2234844ef9f0daf885f5c - https://git.kernel.org/stable/c/4c1022220b1b6fea802175e80444923a3bbf93a5 - https://git.kernel.org/stable/c/791f32c5eab33ca3a153f8f6f763aa0df1ddc320 - https://git.kernel.org/stable/c/0d45954034f8edd6d4052e0190d3d6335c37e4de - https://git.kernel.org/stable/c/c0ec2e47f1e92d69b42b17a4a1e543256778393e - https://git.kernel.org/stable/c/fc45b3f9599b657d4a64bcf423d2a977b3e13a49 - https://git.kernel.org/stable/c/0c639c6479ec4480372901a5fc566f7588cf552
ble/c/fc45b3f9599b657d4a64bcf423d2a977b3e13a49 - https://git.kernel.org/stable/c/0c639c6479ec4480372901a5fc566f7588cf5522 - https://git.kernel.org/stable/c/d46e51f1c78b9ab9323610feb14238d06d46d519
CVE ID: CVE-2025-38623 State: PUBLISHED Published: 2025-08-22T16:00:32.046Z Last Updated: 2025-11-03T17:40:33.389Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: pnv_php: Fix surprise plug detection and recovery The existing PowerNV hotplug code did not handle surprise plug events correctly, leading to a complete failure of the hotplug system after device removal and a required reboot to detect new devices. This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notificati
will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot. Issue the appropriate unfreeze and rescan commands on hotplug events, and don't oops on hotplug if pci_bus_to_OF_node() returns NU