Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-21696 State: PUBLISHED Published: 2025-02-12T13:27:54.905Z Last Updated: 2025-10-01T19:57:09.649Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: clear uffd-wp PTE/PMD state on mremap() When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROT_WRITE) to trigger a warning in page_table_check_pte_flags() due to setting the pte to wr
uses a subsequent mprotect(PROT_WRITE) to trigger a warning in page_table_check_pte_flags() due to setting the pte to writable while uffd-wp is still set. Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VM_UFFD_WP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/310ac886d68de661c3a334198d8604b722d7fdf8 - https://git.kernel.org/stable/c/0cef0bb836e3cfe00f08f9606c72abd72fe78ca3
CVE ID: CVE-2025-21697 State: PUBLISHED Published: 2025-02-12T13:27:55.488Z Last Updated: 2025-11-03T20:59:20.493Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Ensure job pointer is set to NULL after job completion After a job completes, the corresponding pointer in the device must be set to NULL. Failing to do so triggers a warning when unloading the driver, as it appears the job is still active. To prevent this, assign the job pointer to NULL after completing the job, indicating the job has finished. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/sta
ed. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/1bd6303d08c85072ce40ac01a767ab67195105bd - https://git.kernel.org/stable/c/a34050f70e7955a359874dff1a912a748724a140 - https://git.kernel.org/stable/c/14e0a874488e79086340ba8e2d238cb9596b68a8 - https://git.kernel.org/stable/c/2a1c88f7ca5c12dff6fa6787492ac910bb9e4407 - https://git.kernel.org/stable/c/63195bae1cbf78f1d392b1bc9ae4b03c82d0ebf3 - https://git.kernel.org/stable/c/b22467b1ae104073dcb11aa78562a331cd7fb0e0 - https://git.kernel.org/stable/c/e4b5ccd392b92300a2b341705cc4805681094e49
CVE ID: CVE-2025-21698 State: REJECTED Published: 2025-02-12T13:52:50.352Z Last Updated: 2025-02-13T15:22:49.587Z Description: No description available.
CVE ID: CVE-2025-21699 State: PUBLISHED Published: 2025-02-12T13:52:50.962Z Last Updated: 2025-11-03T20:59:23.304Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag Truncate an inode's address space when flipping the GFS2_DIF_JDATA flag: depending on that flag, the pages in the address space will either use buffer heads or iomap_folio_state structs, and we cannot mix the two. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2b0bd5051ad1c1e9ef4879f18e15a7712c974f3e - https://git.kernel.org/stable/c
References: - https://git.kernel.org/stable/c/2b0bd5051ad1c1e9ef4879f18e15a7712c974f3e - https://git.kernel.org/stable/c/8c41abc11aa8438c9ed2d973f97e66674c0355df - https://git.kernel.org/stable/c/4e3ded34f3f3c9d7ed2aac7be8cf51153646574a - https://git.kernel.org/stable/c/2a40a140e11fec699e128170ccaa98b6b82cb503 - https://git.kernel.org/stable/c/4dd57d1f0e9844311c635a7fb39abce4f2ac5a61 - https://git.kernel.org/stable/c/4516febe325342555bb09ca5b396fb816d655821 - https://git.kernel.org/stable/c/5bb1fd0855bb0abc7d97e44758d6ffed7882d2d0 - https://git.kernel.org/stable/c/7c9d9223802fbed4dee1ae301661bf346964c9d2
CVE ID: CVE-2025-21700 State: PUBLISHED Published: 2025-02-13T11:30:19.003Z Last Updated: 2025-11-03T19:35:46.524Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: sched: Disallow replacing of child qdisc from one parent to another Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr step3. a class for nesting tc class add dev lo classid 1:2 drr step4. a class to graft qdisc to tc class add dev lo classid 1:3 dr
lass for nesting tc class add dev lo classid 1:2 drr step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024 step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr step7. tc class add dev lo classid 3:1 drr step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo step 9. Display the class/qdisc layout tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2 step10. trigger the bug <===
lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2 step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0 step 11. Redisplay again the qdiscs/classes tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2 Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has go
rve that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it. Step 12. send one packet to plug echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003)) step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1 The semantics of "replace" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more compl
_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of "disallow such config". Joint work with Lion Ackermann <nnamrec@gmail.com> Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/cd796e269123e1994bfc4e99dd76680ba0946a97 - https://git.kernel.org/stable/c/fe18c21d67dc7d1bcce1bba56515b1b0306db19b - https://git.kernel.org/stable/c/38646749d6e12f9d80a08d21ca39f0beca20230d - https://git.kernel.org/stable/c/deda09c0543a66fa51554abc5ffd723d99b191bf - https://git.k
12f9d80a08d21ca39f0beca20230d - https://git.kernel.org/stable/c/deda09c0543a66fa51554abc5ffd723d99b191bf - https://git.kernel.org/stable/c/7e2bd8c13b07e29a247c023c7444df23f9a79fd8 - https://git.kernel.org/stable/c/73c7e1d6898ccbeee126194dcc05f58b8a795e70 - https://git.kernel.org/stable/c/46c59ec33ec98aba20c15117630cae43a01404cc - https://git.kernel.org/stable/c/bc50835e83f60f56e9bec2b392fb5544f250fb6f
CVE ID: CVE-2025-21701 State: PUBLISHED Published: 2025-02-13T15:05:46.483Z Last Updated: 2025-11-03T19:35:47.886Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: avoid race between device unregistration and ethnl ops The following trace can be seen if a device is being unregistered while its number of channels are being modified. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120 CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771 RIP: 0010:__mutex_lock+0xc8a/0x1120 Call Trace: <TASK> ethtool_check_max_channel+0x1ea/0x880 ethnl_set_chann
0-rc6+ #771 RIP: 0010:__mutex_lock+0xc8a/0x1120 Call Trace: <TASK> ethtool_check_max_channel+0x1ea/0x880 ethnl_set_channels+0x3c3/0xb10 ethnl_default_set_doit+0x306/0x650 genl_family_rcv_msg_doit+0x1e3/0x2c0 genl_rcv_msg+0x432/0x6f0 netlink_rcv_skb+0x13d/0x3b0 genl_rcv+0x28/0x40 netlink_unicast+0x42e/0x720 netlink_sendmsg+0x765/0xc20 __sys_sendto+0x3ac/0x420 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being us
in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea. Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough. Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kerne
ll be found. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/26bc6076798aa4dc83a07d0a386f9e57c94e8517 - https://git.kernel.org/stable/c/b1cb37a31a482df3dd35a6ac166282dac47664f4 - https://git.kernel.org/stable/c/2f29127e94ae9fdc7497331003d6860e9551cdf3 - https://git.kernel.org/stable/c/b382ab9b885cbb665e0e70a727f101c981b4edf3 - https://git.kernel.org/stable/c/4dc880245f9b529fa8f476b5553c799d2848b47b - https://git.kernel.org/stable/c/12e070eb6964b341b41677fd260af5a305316a1f
CVE ID: CVE-2025-21702 State: PUBLISHED Published: 2025-02-18T14:37:43.429Z Last Updated: 2025-11-03T19:35:50.649Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pfifo_tail_enqueue: Drop new packet when sch->limit == 0 Expected behaviour: In case we reach scheduler's limit, pfifo_tail_enqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifo_tail_enqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifo_tail_enqueue() return `NET_XMIT_CN` status code. Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no pac
code. Weird behaviour: In case we set `sch->limit == 0` and trigger pfifo_tail_enqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifo_tail_enqueue() to increase qlen by one and return `NET_XMIT_CN` status code. The problem is: Let's say we have two qdiscs: Qdisc_A and Qdisc_B. - Qdisc_A's type must have '->graft()' function to create parent/child relationship. Let's say Qdisc_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqu
_A's type is `hfsc`. Enqueue packet to this qdisc will trigger `hfsc_enqueue`. - Qdisc_B's type is pfifo_head_drop. Enqueue packet to this qdisc will trigger `pfifo_tail_enqueue`. - Qdisc_B is configured to have `sch->limit == 0`. - Qdisc_A is configured to route the enqueued's packet to Qdisc_B. Enqueue packet through Qdisc_A will lead to: - hfsc_enqueue(Qdisc_A) -> pfifo_tail_enqueue(Qdisc_B) - Qdisc_B->q.qlen += 1 - pfifo_tail_enqueue() return `NET_XMIT_CN` - hfsc_enqueue() check for `NET_XMIT_SUCCESS` and see `NET_XMIT_CN` => hfsc_enqueue() don't increase qlen of Qdisc_A. The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other
A. The whole process lead to a situation where Qdisc_A->q.qlen == 0 and Qdisc_B->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen. Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/78285b53266d6d51fa4ff504a23df03852eba84e - https://git.kernel.org/stable/c/7a9723ec27aff5674f1fd4934608937f1d650980 - https://git.kernel.org/stable/c/a56a6e8589a9b98d8171611fbcc1e45a15fd2455 - https://git.kernel.org/stable/c/020ecb76812a05
ttps://git.kernel.org/stable/c/a56a6e8589a9b98d8171611fbcc1e45a15fd2455 - https://git.kernel.org/stable/c/020ecb76812a0526f4130ab5aeb6dc7c773e7ab9 - https://git.kernel.org/stable/c/79a955ea4a2e5ddf4a36328959de0de496419888 - https://git.kernel.org/stable/c/e40cb34b7f247fe2e366fd192700d1b4f38196ca - https://git.kernel.org/stable/c/b6a079c3b6f95378f26e2aeda520cb3176f7067b - https://git.kernel.org/stable/c/647cef20e649c576dff271e018d5d15d998b629d
CVE ID: CVE-2025-21703 State: PUBLISHED Published: 2025-02-18T14:37:44.261Z Last Updated: 2025-11-03T19:35:52.049Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netem: Update sch->q.qlen before qdisc_tree_reduce_backlog() qdisc_tree_reduce_backlog() notifies parent qdisc only if child qdisc becomes empty, therefore we need to reduce the backlog of the child qdisc before calling it. Otherwise it would miss the opportunity to call cops->qlen_notify(), in the case of DRR, it resulted in UAF since DRR uses ->qlen_notify() to maintain its active list. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: Refer
_notify() to maintain its active list. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e395fec75ac2dbffc99b4bce57b7f1f3c5449f2c - https://git.kernel.org/stable/c/7f31d74fcc556a9166b1bb20515542de7bb939d1 - https://git.kernel.org/stable/c/98a2c685293aae122f688cde11d9334dddc5d207 - https://git.kernel.org/stable/c/7b79ca9a1de6a428d486ff52fb3d602321c08f55 - https://git.kernel.org/stable/c/1f8e3f4a4b8b90ad274dfbc66fc7d55cb582f4d5 - https://git.kernel.org/stable/c/6312555249082d6d8cc5321ff725df05482d8b83 - https://git.kernel.org/stable/c/839ecc583fa00fab785fde1c85a326743657fd32 - https://git.kernel.org/stable/c/638ba508932479
ttps://git.kernel.org/stable/c/839ecc583fa00fab785fde1c85a326743657fd32 - https://git.kernel.org/stable/c/638ba5089324796c2ee49af10427459c2de35f71
CVE ID: CVE-2025-21704 State: PUBLISHED Published: 2025-02-22T09:43:37.377Z Last Updated: 2025-11-03T19:35:54.825Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: cdc-acm: Check control transfer buffer size before access If the first fragment is shorter than struct usb_cdc_notification, we can't calculate an expected_size. Log an error and discard the notification instead of reading lengths from memory outside the received data, which can lead to memory corruption when the expected_size decreases between fragments, causing `expected_size - acm->nb_index` to wrap. This issue has been present since the beginning of git histor
ragments, causing `expected_size - acm->nb_index` to wrap. This issue has been present since the beginning of git history; however, it only leads to memory corruption since commit ea2583529cd1 ("cdc-acm: reassemble fragmented notifications"). A mitigating factor is that acm_ctrl_irq() can only execute after userspace has opened /dev/ttyACM*; but if ModemManager is running, ModemManager will do that automatically depending on the USB device's vendor/product IDs and its other interfaces. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a4e1ae5c0533964170197e4fb4f33bc8c1db5cd2 - https://git.kernel.org/stable/c/90dd2f1b7342b9a671a5ea4160f408037b92b
table/c/a4e1ae5c0533964170197e4fb4f33bc8c1db5cd2 - https://git.kernel.org/stable/c/90dd2f1b7342b9a671a5ea4160f408037b92b118 - https://git.kernel.org/stable/c/871619c2b78fdfe05afb4e8ba548678687beb812 - https://git.kernel.org/stable/c/7828e9363ac4d23b02419bf2a45b9f1d9fb35646 - https://git.kernel.org/stable/c/6abb510251e75f875797d8983a830e6731fa281c - https://git.kernel.org/stable/c/f64079bef6a8a7823358c3f352ea29a617844636 - https://git.kernel.org/stable/c/383d516a0ebc8641372b521c8cb717f0f1834831 - https://git.kernel.org/stable/c/e563b01208f4d1f609bcab13333b6c0e24ce6a01 - https://project-zero.issues.chromium.org/issues/395107243
CVE ID: CVE-2025-21705 State: PUBLISHED Published: 2025-02-27T02:07:19.764Z Last Updated: 2025-11-03T19:35:56.220Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: handle fastopen disconnect correctly Syzbot was able to trigger a data stream corruption: WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Modules linked in: CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:
mpute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 <0f> 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07 RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293 RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928 R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000 R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000 F
00000000 R11: ffffed10170c8929 R12: 0000000000000000 R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000 FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074 mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493 release_sock+0x1aa/0x1f0 net/core/sock.c:3640 inet_wait_for_connect net/ipv4/af_inet.c:609 [inline] __inet_stream_connect+
lease_sock+0x1aa/0x1f0 net/core/sock.c:3640 inet_wait_for_connect net/ipv4/af_inet.c:609 [inline] __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703 mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755 mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:726 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583 ___sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6e86ebfe69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e
y/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6e86ebfe69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69 RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508 </TASK> The root ca
000000000246 R12: 00007f6e86f491bc R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508 </TASK> The root cause is the bad handling of disconnect() generated internally by the MPTCP protocol in case of connect FASTOPEN errors. Address the issue increasing the socket disconnect counter even on such a case, to allow other threads waiting on the same socket lock to properly error out. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/73e268b4be27b36ae68ea10755cb003f43b38884 - https://git.kernel.org/stable/c/0263fb2e7b7b88075a5d86e74c4384ee4400828d - https://git.kernel.org/stable/c/84ac44d9fed3a56440971cbd7600a02b70b5b32a - https://git.k
b88075a5d86e74c4384ee4400828d - https://git.kernel.org/stable/c/84ac44d9fed3a56440971cbd7600a02b70b5b32a - https://git.kernel.org/stable/c/6ec806762318a4adde0ea63342d42d0feae95079 - https://git.kernel.org/stable/c/619af16b3b57a3a4ee50b9a30add9ff155541e71
CVE ID: CVE-2025-21706 State: PUBLISHED Published: 2025-02-27T02:07:20.458Z Last Updated: 2025-11-03T19:35:57.608Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only set fullmesh for subflow endp With the in-kernel path-manager, it is possible to change the 'fullmesh' flag. The code in mptcp_pm_nl_fullmesh() expects to change it only on 'subflow' endpoints, to recreate more or less subflows using the linked address. Unfortunately, the set_flags() hook was a bit more permissive, and allowed 'implicit' endpoints to get the 'fullmesh' flag while it is not allowed before. That's what syzbot found, triggering the followi
t' endpoints to get the 'fullmesh' flag while it is not allowed before. That's what syzbot found, triggering the following warning: WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 __mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064 Modules linked in: CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172
ptcp/pm_netlink.c:2064 Modules linked in: CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline] RIP: 0010:mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064 Code: 01 00 00 49 89 c5 e8 fb 45 e8 f5 e9 b8 fc ff ff e8 f1 45 e8 f5 4c 89 f7 be 03 00 00 00 e8 44 1d 0b f9 eb a0 e8 dd 45 e8 f5 90 <0f> 0b 90 e9 17 ff ff ff 89 d9 80 e1 07 38 c1 0f 8c c9 fc ff ff