{"vulnerability": "CVE-2025-2164", "sightings": [{"uuid": "104a0176-f6c5-44c5-bac6-32dcba898dd6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-2164", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lkfdkxmyou2n", "content": "", "creation_timestamp": "2025-03-15T04:56:49.508860Z"}, {"uuid": "b7113ff2-ea87-4adf-bf31-7a03e81d9cce", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21640", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854659059377333", "content": "", "creation_timestamp": "2025-01-19T10:57:07.097188Z"}, {"uuid": "428b6bae-9a56-4caf-9111-3a758b313b27", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21641", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854659075710792", "content": "", "creation_timestamp": "2025-01-19T10:57:07.303734Z"}, {"uuid": "ba3bb4cc-a589-4468-a16f-83371d09fa8a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21642", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854659091214712", "content": "", "creation_timestamp": "2025-01-19T10:57:07.447764Z"}, {"uuid": "10240b5f-dfc8-4db5-925b-b5da8aa0ecfe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21643", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854718095653986", "content": "", "creation_timestamp": "2025-01-19T11:12:07.622745Z"}, {"uuid": "5c1a8e6d-2d95-4753-80f7-d1751a69508b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21644", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854718111133051", "content": "", "creation_timestamp": "2025-01-19T11:12:08.124875Z"}, {"uuid": "78b01e50-15b1-4f39-9d62-f7c6d51421ce", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21645", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854718146355859", "content": "", "creation_timestamp": "2025-01-19T11:12:08.638503Z"}, {"uuid": "c493cf1f-3f3c-4d39-ab8f-b48226bee1bd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21646", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854718161211847", "content": "", "creation_timestamp": "2025-01-19T11:12:08.922579Z"}, {"uuid": "d1514686-f7a3-4f1e-b11f-7fd82e3d9e82", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21640", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p3wyztq2j", "content": "", "creation_timestamp": "2025-01-19T11:15:44.769046Z"}, {"uuid": "8fe9d407-bac0-4f87-91b7-d7b3faf8df18", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21641", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p3zmg6q2p", "content": "", "creation_timestamp": "2025-01-19T11:15:47.674668Z"}, {"uuid": "c2c9a071-c86e-48c2-aed6-ca9bc76b2b3b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21642", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p43xec72h", "content": "", "creation_timestamp": "2025-01-19T11:15:50.317065Z"}, {"uuid": "e0cd62c7-0de2-4338-a603-f94ddd0ae6fc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21643", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p46isrc2t", "content": "", "creation_timestamp": "2025-01-19T11:15:52.639435Z"}, {"uuid": "35ed81c1-fc16-4486-936c-71178a7c18f4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21644", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p4b24lo2t", "content": "", "creation_timestamp": "2025-01-19T11:15:55.589397Z"}, {"uuid": "7e2358e0-f2f6-4056-999d-84ed12ff4edb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21645", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p4diys22n", "content": "", "creation_timestamp": "2025-01-19T11:15:57.937306Z"}, {"uuid": "7342161b-4fb5-4945-a84d-6d21556691c9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21646", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p4foqnd2r", "content": "", "creation_timestamp": "2025-01-19T11:16:00.456001Z"}, {"uuid": "ebd51597-e31e-46bd-bf96-7c86ceb19334", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21647", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p4kcyac2f", "content": "", "creation_timestamp": "2025-01-19T11:16:05.077581Z"}, {"uuid": "408be0c2-9b94-474e-9d64-e580e7c5d828", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21648", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p4neyrv2b", "content": "", "creation_timestamp": "2025-01-19T11:16:08.354156Z"}, {"uuid": "a20f693e-72c0-4a50-ab56-9a04e896062c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21649", "type": "seen", "source": "https://bsky.app/profile/cve-notifications.bsky.social/post/3lg3p4pi2jp2h", "content": "", "creation_timestamp": "2025-01-19T11:16:10.560372Z"}, {"uuid": "8e5776ee-34f8-4c41-a9fe-2e96f67eaf78", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21647", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854777164009372", "content": "", "creation_timestamp": "2025-01-19T11:27:08.978279Z"}, {"uuid": "72f01899-e573-41e7-9fa9-445d25137601", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21648", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854777178287041", "content": "", "creation_timestamp": "2025-01-19T11:27:09.168750Z"}, {"uuid": "9a5836eb-27b1-4a9f-b6e9-1b3f1b5b52da", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21649", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113854777192747347", "content": "", "creation_timestamp": "2025-01-19T11:27:09.783829Z"}, {"uuid": "01379c27-43af-4b60-8c32-398775eb1f9d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21646", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lg3qyxuruw2g", "content": "", "creation_timestamp": "2025-01-19T11:49:53.136458Z"}, {"uuid": "3b6e250a-17f7-425f-8b6b-e1131c5c1509", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21640", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lg3qyyiago2h", "content": "", "creation_timestamp": "2025-01-19T11:49:54.966970Z"}, {"uuid": "9a46720e-cc9b-476d-bf4b-2cc44e1de568", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21641", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lg3qyyqg6j2q", "content": "", "creation_timestamp": "2025-01-19T11:49:56.073528Z"}, {"uuid": "5d9a2ebf-9882-4e2b-b373-efd82cf5ea8f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21643", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lg3qyz7tax2q", "content": "", "creation_timestamp": "2025-01-19T11:49:57.328874Z"}, {"uuid": "9f856087-2124-42db-967f-12dacbe47e2b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21645", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "cbc043cc-22f5-425c-a8a6-ac76d773035e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21649", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "f31f52a3-410d-4f28-b9f3-e1124461686f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21648", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2319", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21648\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: clamp maximum hashtable size to INT_MAX\n\nUse INT_MAX as maximum size for the conntrack hashtable. Otherwise, it\nis possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when\nresizing hashtable because __GFP_NOWARN is unset. See:\n\n  0708a0afe291 (\"mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls\")\n\nNote: hashtable resize is only possible from init_netns.\n\ud83d\udccf Published: 2025-01-19T10:18:05.700Z\n\ud83d\udccf Modified: 2025-01-19T10:18:05.700Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/5552b4fd44be3393b930434a7845d8d95a2a3c33\n2. https://git.kernel.org/stable/c/d5807dd1328bbc86e059c5de80d1bbee9d58ca3d\n3. https://git.kernel.org/stable/c/f559357d035877b9d0dcd273e0ff83e18e1d46aa\n4. https://git.kernel.org/stable/c/b541ba7d1f5a5b7b3e2e22dc9e40e18a7d6dbc13", "creation_timestamp": "2025-01-19T10:58:21.000000Z"}, {"uuid": "b6fec4a4-5393-4071-810f-5ef11a152e34", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21649", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2318", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21649\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when 1588 is sent on HIP08 devices\n\nCurrently, HIP08 devices does not register the ptp devices, so the\nhdev->ptp is NULL. But the tx process would still try to set hardware time\nstamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.\n\n[  128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n...\n[  128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge]\n[  128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge]\n[  128.292938] sp : ffff800059b93140\n[  128.297200] x29: ffff800059b93140 x28: 0000000000003280\n[  128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080\n[  128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001\n[  128.315969] x23: 0000000000000000 x22: 0000000000000194\n[  128.322219] x21: ffff0cd94f986000 x20: 0000000000000000\n[  128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000\n[  128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24\n[  128.340934] x15: 0000ffffd530a518 x14: 0000000000000000\n[  128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368\n[  128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02\n[  128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0\n[  128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000\n[  128.372040] x5 : 0000000000000000 x4 : 000000000000ffff\n[  128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294\n[  128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080\n[  128.390626] Call trace:\n[  128.393964]  hclge_ptp_set_tx_info+0x2c/0x140 [hclge]\n[  128.399893]  hns3_nic_net_xmit+0x39c/0x4c4 [hns3]\n[  128.405468]  xmit_one.constprop.0+0xc4/0x200\n[  128.410600]  dev_hard_start_xmit+0x54/0xf0\n[  128.415556]  sch_direct_xmit+0xe8/0x634\n[  128.420246]  __dev_queue_xmit+0x224/0xc70\n[  128.425101]  dev_queue_xmit+0x1c/0x40\n[  128.429608]  ovs_vport_send+0xac/0x1a0 [openvswitch]\n[  128.435409]  do_output+0x60/0x17c [openvswitch]\n[  128.440770]  do_execute_actions+0x898/0x8c4 [openvswitch]\n[  128.446993]  ovs_execute_actions+0x64/0xf0 [openvswitch]\n[  128.453129]  ovs_dp_process_packet+0xa0/0x224 [openvswitch]\n[  128.459530]  ovs_vport_receive+0x7c/0xfc [openvswitch]\n[  128.465497]  internal_dev_xmit+0x34/0xb0 [openvswitch]\n[  128.471460]  xmit_one.constprop.0+0xc4/0x200\n[  128.476561]  dev_hard_start_xmit+0x54/0xf0\n[  128.481489]  __dev_queue_xmit+0x968/0xc70\n[  128.486330]  dev_queue_xmit+0x1c/0x40\n[  128.490856]  ip_finish_output2+0x250/0x570\n[  128.495810]  __ip_finish_output+0x170/0x1e0\n[  128.500832]  ip_finish_output+0x3c/0xf0\n[  128.505504]  ip_output+0xbc/0x160\n[  128.509654]  ip_send_skb+0x58/0xd4\n[  128.513892]  udp_send_skb+0x12c/0x354\n[  128.518387]  udp_sendmsg+0x7a8/0x9c0\n[  128.522793]  inet_sendmsg+0x4c/0x8c\n[  128.527116]  __sock_sendmsg+0x48/0x80\n[  128.531609]  __sys_sendto+0x124/0x164\n[  128.536099]  __arm64_sys_sendto+0x30/0x5c\n[  128.540935]  invoke_syscall+0x50/0x130\n[  128.545508]  el0_svc_common.constprop.0+0x10c/0x124\n[  128.551205]  do_el0_svc+0x34/0xdc\n[  128.555347]  el0_svc+0x20/0x30\n[  128.559227]  el0_sync_handler+0xb8/0xc0\n[  128.563883]  el0_sync+0x160/0x180\n\ud83d\udccf Published: 2025-01-19T10:18:06.911Z\n\ud83d\udccf Modified: 2025-01-19T10:18:06.911Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/f19ab3ef96d9626e5f1bdc56d3574c355e83d623\n2. https://git.kernel.org/stable/c/9741e72b2286de8b38de9db685588ac421a95c87", "creation_timestamp": "2025-01-19T10:58:20.000000Z"}, {"uuid": "f0759d9e-7466-4621-8f50-7e6140b4bb0d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21641", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2324", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21641\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: sysctl: blackhole timeout: avoid using current->nsproxy\n\nAs mentioned in the previous commit, using the 'net' structure via\n'current' is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader's/writer's netns vs only\n  from the opener's netns.\n\n- current->nsproxy can be NULL in some cases, resulting in an 'Oops'\n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n  syzbot [1] using acct(2).\n\nThe 'pernet' structure can be obtained from the table->data using\ncontainer_of().\n\ud83d\udccf Published: 2025-01-19T10:17:58.351Z\n\ud83d\udccf Modified: 2025-01-19T10:17:58.351Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/4c74fbdc5ab95b13945be01e6065940b68222db7\n2. https://git.kernel.org/stable/c/92cf7a51bdae24a32c592adcdd59a773ae149289", "creation_timestamp": "2025-01-19T10:58:28.000000Z"}, {"uuid": "09f0677a-04a4-46c7-97b6-2b548ce6501b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21643", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2323", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21643\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix kernel async DIO\n\nNetfslib needs to be able to handle kernel-initiated asynchronous DIO that\nis supplied with a bio_vec[] array.  Currently, because of the async flag,\nthis gets passed to netfs_extract_user_iter() which throws a warning and\nfails because it only handles IOVEC and UBUF iterators.  This can be\ntriggered through a combination of cifs and a loopback blockdev with\nsomething like:\n\n        mount //my/cifs/share /foo\n        dd if=/dev/zero of=/foo/m0 bs=4K count=1K\n        losetup --sector-size 4096 --direct-io=on /dev/loop2046 /foo/m0\n        echo hello >/dev/loop2046\n\nThis causes the following to appear in syslog:\n\n        WARNING: CPU: 2 PID: 109 at fs/netfs/iterator.c:50 netfs_extract_user_iter+0x170/0x250 [netfs]\n\nand the write to fail.\n\nFix this by removing the check in netfs_unbuffered_write_iter_locked() that\ncauses async kernel DIO writes to be handled as userspace writes.  Note\nthat this change relies on the kernel caller maintaining the existence of\nthe bio_vec array (or kvec[] or folio_queue) until the op is complete.\n\ud83d\udccf Published: 2025-01-19T10:17:59.820Z\n\ud83d\udccf Modified: 2025-01-19T10:17:59.820Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/9f3a265836844eda30bf34c2584b8011fd4f0f49\n2. https://git.kernel.org/stable/c/3f6bc9e3ab9b127171d39f9ac6eca1abb693b731", "creation_timestamp": "2025-01-19T10:58:27.000000Z"}, {"uuid": "e4563682-a315-488d-bf9a-8c30de21d446", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21644", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2322", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21644\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix tlb invalidation when wedging\n\nIf GuC fails to load, the driver wedges, but in the process it tries to\ndo stuff that may not be initialized yet. This moves the\nxe_gt_tlb_invalidation_init() to be done earlier: as its own doc says,\nit's a software-only initialization and should had been named with the\n_early() suffix.\n\nMove it to be called by xe_gt_init_early(), so the locks and seqno are\ninitialized, avoiding a NULL ptr deref when wedging:\n\n xe 0000:03:00.0: [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01\n xe 0000:03:00.0: [drm] *ERROR* GT0: firmware signature verification failed\n xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged.\n ...\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 9 UID: 0 PID: 3908 Comm: modprobe Tainted: G     U  W          6.13.0-rc4-xe+ #3\n Tainted: [U]=USER, [W]=WARN\n Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 07/01/2022\n RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe]\n\nThis can be easily triggered by poking the GuC binary to force a\nsignature failure. There will still be an extra message,\n\n xe 0000:03:00.0: [drm] *ERROR* GT0: GuC mmio request 0x4100: no reply 0x4100\n\nbut that's better than a NULL ptr deref.\n\n(cherry picked from commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6)\n\ud83d\udccf Published: 2025-01-19T10:18:00.752Z\n\ud83d\udccf Modified: 2025-01-19T10:18:00.752Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/09b94ddc58c6640cbbc7775a61a5387b8be71488\n2. https://git.kernel.org/stable/c/9ab4981552930a9c45682d62424ba610edc3992d", "creation_timestamp": "2025-01-19T10:58:26.000000Z"}, {"uuid": "d425a727-522a-46f8-92b3-93339e47ab17", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21645", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2321", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21645\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it\n\nWakeup for IRQ1 should be disabled only in cases where i8042 had\nactually enabled it, otherwise \"wake_depth\" for this IRQ will try to\ndrop below zero and there will be an unpleasant WARN() logged:\n\nkernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug\nkernel: ------------[ cut here ]------------\nkernel: Unbalanced IRQ 1 wake disable\nkernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0\n\nThe PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops\nwhich sets amd_pmc_suspend_handler() to the .suspend, .freeze, and\n.poweroff handlers. i8042_pm_suspend(), however, is only set as\nthe .suspend handler.\n\nFix the issue by call PMC suspend handler only from the same set of\ndev_pm_ops handlers as i8042_pm_suspend(), which currently means just\nthe .suspend handler.\n\nTo reproduce this issue try hibernating (S4) the machine after a fresh boot\nwithout putting it into s2idle first.\n\n[ij: edited the commit message.]\n\ud83d\udccf Published: 2025-01-19T10:18:01.556Z\n\ud83d\udccf Modified: 2025-01-19T10:18:01.556Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/5cc621085e2b7a9b1905a98f8e5a86bb4aea2016\n2. https://git.kernel.org/stable/c/b25778c87a6bce40c31e92364f08aa6240309e25\n3. https://git.kernel.org/stable/c/dd410d784402c5775f66faf8b624e85e41c38aaf", "creation_timestamp": "2025-01-19T10:58:26.000000Z"}, {"uuid": "d7c5c588-31e0-43c1-a11b-75af1277edef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21647", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/2320", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21647\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nsched: sch_cake: add bounds checks to host bulk flow fairness counts\n\nEven though we fixed a logic error in the commit cited below, syzbot\nstill managed to trigger an underflow of the per-host bulk flow\ncounters, leading to an out of bounds memory access.\n\nTo avoid any such logic errors causing out of bounds memory accesses,\nthis commit factors out all accesses to the per-host bulk flow counters\nto a series of helpers that perform bounds-checking before any\nincrements and decrements. This also has the benefit of improving\nreadability by moving the conditional checks for the flow mode into\nthese helpers, instead of having them spread out throughout the\ncode (which was the cause of the original logic error).\n\nAs part of this change, the flow quantum calculation is consolidated\ninto a helper function, which means that the dithering applied to the\nost load scaling is now applied both in the DRR rotation and when a\nsparse flow's quantum is first initiated. The only user-visible effect\nof this is that the maximum packet size that can be sent while a flow\nstays sparse will now vary with +/- one byte in some cases. This should\nnot make a noticeable difference in practice, and thus it's not worth\ncomplicating the code to preserve the old behaviour.\n\ud83d\udccf Published: 2025-01-19T10:18:04.415Z\n\ud83d\udccf Modified: 2025-01-19T10:18:04.415Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/a777e06dfc72bed73c05dcb437d7c27ad5f90f3f\n2. https://git.kernel.org/stable/c/27202e2e8721c3b23831563c36ed5ac7818641ba\n3. https://git.kernel.org/stable/c/91bb18950b88f955838ec0c1d97f74d135756dc7\n4. https://git.kernel.org/stable/c/737d4d91d35b5f7fa5bb442651472277318b0bfd", "creation_timestamp": "2025-01-19T10:58:24.000000Z"}, {"uuid": "c2a6a7b6-a298-4596-a871-23d4071c8c5f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21640", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/2325", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-21640\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy\n\nAs mentioned in a previous commit of this series, using the 'net'\nstructure via 'current' is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader's/writer's netns vs only\n  from the opener's netns.\n\n- current->nsproxy can be NULL in some cases, resulting in an 'Oops'\n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n  syzbot [1] using acct(2).\n\nThe 'net' structure can be obtained from the table->data using\ncontainer_of().\n\nNote that table->data could also be used directly, as this is the only\nmember needed from the 'net' structure, but that would increase the size\nof this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' is\nused.\n\ud83d\udccf Published: 2025-01-19T10:17:57.593Z\n\ud83d\udccf Modified: 2025-01-19T10:17:57.593Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/3cd0659deb9c03535fd61839e91d4d4d3e51ac71\n2. https://git.kernel.org/stable/c/ad673e514b2793b8d5902f6ba6ab7e890dea23d5\n3. https://git.kernel.org/stable/c/f0bb3935470684306e4e04793a20ac4c4b08de0b\n4. https://git.kernel.org/stable/c/ea62dd1383913b5999f3d16ae99d411f41b528d4", "creation_timestamp": "2025-01-19T10:58:32.000000Z"}, {"uuid": "2e548fa8-98a1-4aea-8f77-77518ed9f2e7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21648", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "bd18a346-1153-4997-8945-d8d0c9a4cd9b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-2164", "type": "seen", "source": "https://t.me/DarkWebInformer_CVEAlerts/7658", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-2164\n\ud83d\udd25 CVSS Score: 6.1 (cvssV3_1, Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)\n\ud83d\udd39 Description: The pixelstats plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the 'post_id' and 'sortby' parameters in all versions up to, and including, 0.8.2 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.\n\ud83d\udccf Published: 2025-03-15T03:23:23.563Z\n\ud83d\udccf Modified: 2025-03-15T03:23:23.563Z\n\ud83d\udd17 References:\n1. https://www.wordfence.com/threat-intel/vulnerabilities/id/8683bc00-1136-42c4-a256-84b2cac1d575?source=cve\n2. https://plugins.trac.wordpress.org/browser/pixelstats/tags/0.8.2/pixelstats.php#L331\n3. https://plugins.trac.wordpress.org/browser/pixelstats/tags/0.8.2/pixelstats.php#L664\n4. https://wordpress.org/plugins/pixelstats/", "creation_timestamp": "2025-03-15T03:49:05.000000Z"}, {"uuid": "4baf14bd-f426-4660-bb71-3a8b651909f6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-2164", "type": "seen", "source": "https://t.me/cvedetector/20353", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-2164 - WordPress Pixelstats Reflected Cross-Site Scripting\", \n  \"Content\": \"CVE ID : CVE-2025-2164 \nPublished : March 15, 2025, 4:15 a.m. | 1\u00a0hour, 35\u00a0minutes ago \nDescription : The pixelstats plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the 'post_id' and 'sortby' parameters in all versions up to, and including, 0.8.2 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link. \nSeverity: 6.1 | MEDIUM \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"15 Mar 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-03-15T06:55:39.000000Z"}, {"uuid": "2f2ba322-f316-4ef8-9bf6-e2e481045acf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21646", "type": "seen", "source": "https://t.me/cvedetector/15822", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21646 - \"Linux AFS Denial of Service\"\", \n  \"Content\": \"CVE ID : CVE-2025-21646 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nafs: Fix the maximum cell name length  \n  \nThe kafs filesystem limits the maximum length of a cell to 256 bytes, but a  \nproblem occurs if someone actually does that: kafs tries to create a  \ndirectory under /proc/net/afs/ with the name of the cell, but that fails  \nwith a warning:  \n  \n        WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405  \n  \nbecause procfs limits the maximum filename length to 255.  \n  \nHowever, the DNS limits the maximum lookup length and, by extension, the  \nmaximum cell name, to 255 less two (length count and trailing NUL).  \n  \nFix this by limiting the maximum acceptable cellname length to 253.  This  \nalso allows us to be sure we can create the \"/afs/./\" mountpoint too.  \n  \nFurther, split the YFS VL record cell name maximum to be the 256 allowed by  \nthe protocol and ignore the record retrieved by YFSVL.GetCellName if it  \nexceeds 253. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"19 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:07:06.000000Z"}, {"uuid": "259146a1-985c-4c7a-b9d1-849c58e3c2c1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21644", "type": "seen", "source": "https://t.me/cvedetector/15837", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21644 - \"Intel Xeon DRM GuC Firmware Wedge Null Pointer Dereference Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2025-21644 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/xe: Fix tlb invalidation when wedging  \n  \nIf GuC fails to load, the driver wedges, but in the process it tries to  \ndo stuff that may not be initialized yet. This moves the  \nxe_gt_tlb_invalidation_init() to be done earlier: as its own doc says,  \nit's a software-only initialization and should had been named with the  \n_early() suffix.  \n  \nMove it to be called by xe_gt_init_early(), so the locks and seqno are  \ninitialized, avoiding a NULL ptr deref when wedging:  \n  \n xe 0000:03:00.0: [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01  \n xe 0000:03:00.0: [drm] *ERROR* GT0: firmware signature verification failed  \n xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged.  \n ...  \n BUG: kernel NULL pointer dereference, address: 0000000000000000  \n #PF: supervisor read access in kernel mode  \n #PF: error_code(0x0000) - not-present page  \n PGD 0 P4D 0  \n Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI  \n CPU: 9 UID: 0 PID: 3908 Comm: modprobe Tainted: G     U  W          6.13.0-rc4-xe+ #3  \n Tainted: [U]=USER, [W]=WARN  \n Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 07/01/2022  \n RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe]  \n  \nThis can be easily triggered by poking the GuC binary to force a  \nsignature failure. There will still be an extra message,  \n  \n xe 0000:03:00.0: [drm] *ERROR* GT0: GuC mmio request 0x4100: no reply 0x4100  \n  \nbut that's better than a NULL ptr deref.  \n  \n(cherry picked from commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"19 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:07:26.000000Z"}, {"uuid": "9acc42ce-8076-4864-a376-e100c3352965", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21643", "type": "seen", "source": "https://t.me/cvedetector/15836", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21643 - \"CIFS Netfs Linux Kernel Async DIO Handling Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2025-21643 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetfs: Fix kernel async DIO  \n  \nNetfslib needs to be able to handle kernel-initiated asynchronous DIO that  \nis supplied with a bio_vec[] array.  Currently, because of the async flag,  \nthis gets passed to netfs_extract_user_iter() which throws a warning and  \nfails because it only handles IOVEC and UBUF iterators.  This can be  \ntriggered through a combination of cifs and a loopback blockdev with  \nsomething like:  \n  \n        mount //my/cifs/share /foo  \n        dd if=/dev/zero of=/foo/m0 bs=4K count=1K  \n        losetup --sector-size 4096 --direct-io=on /dev/loop2046 /foo/m0  \n        echo hello >/dev/loop2046  \n  \nThis causes the following to appear in syslog:  \n  \n        WARNING: CPU: 2 PID: 109 at fs/netfs/iterator.c:50 netfs_extract_user_iter+0x170/0x250 [netfs]  \n  \nand the write to fail.  \n  \nFix this by removing the check in netfs_unbuffered_write_iter_locked() that  \ncauses async kernel DIO writes to be handled as userspace writes.  Note  \nthat this change relies on the kernel caller maintaining the existence of  \nthe bio_vec array (or kvec[] or folio_queue) until the op is complete. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"19 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:07:22.000000Z"}, {"uuid": "70ebe098-2d45-4760-9750-74b4889854bb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21642", "type": "seen", "source": "https://t.me/cvedetector/15834", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21642 - Microsoft Windows MPTCP Linux Kernel NetSysctl Use After Free Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21642 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmptcp: sysctl: sched: avoid using current->nsproxy  \n  \nUsing the 'net' structure via 'current' is not recommended for different  \nreasons.  \n  \nFirst, if the goal is to use it to read or write per-netns data, this is  \ninconsistent with how the \"generic\" sysctl entries are doing: directly  \nby only using pointers set to the table entry, e.g. table->data. Linked  \nto that, the per-netns data should always be obtained from the table  \nlinked to the netns it had been created for, which may not coincide with  \nthe reader's or writer's netns.  \n  \nAnother reason is that access to current->nsproxy->netns can oops if  \nattempted when current->nsproxy had been dropped when the current task  \nis exiting. This is what syzbot found, when using acct(2):  \n  \n  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI  \n  KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]  \n  CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0  \n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024  \n  RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125  \n  Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <803c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00  \n  RSP: 0018:ffffc900034774e8 EFLAGS: 00010206  \n  \n  RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620  \n  RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028  \n  RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040  \n  R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000  \n  R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000  \n  FS:  0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000  \n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n  CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0  \n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  \n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  \n  Call Trace:  \n     \n   proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601  \n   __kernel_write_iter+0x318/0xa80 fs/read_write.c:612  \n   __kernel_write+0xf6/0x140 fs/read_write.c:632  \n   do_acct_process+0xcb0/0x14a0 kernel/acct.c:539  \n   acct_pin_kill+0x2d/0x100 kernel/acct.c:192  \n   pin_kill+0x194/0x7c0 fs/fs_pin.c:44  \n   mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81  \n   cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366  \n   task_work_run+0x14e/0x250 kernel/task_work.c:239  \n   exit_task_work include/linux/task_work.h:43 [inline]  \n   do_exit+0xad8/0x2d70 kernel/exit.c:938  \n   do_group_exit+0xd3/0x2a0 kernel/exit.c:1087  \n   get_signal+0x2576/0x2610 kernel/signal.c:3017  \n   arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337  \n   exit_to_user_mode_loop kernel/entry/common.c:111 [inline]  \n   exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]  \n   __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]  \n   syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218  \n   do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89  \n   entry_SYSCALL_64_after_hwframe+0x77/0x7f  \n  RIP: 0033:0x7fee3cb87a6a  \n  Code: Unable to access opcode bytes at 0x7fee3cb87a40.  \n  RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037  \n  RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a  \n  RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003  \n  RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7  \n  R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007f[...]", "creation_timestamp": "2025-01-19T13:07:21.000000Z"}, {"uuid": "27c454ed-9f96-4df5-a56c-d1e75b6c664e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21641", "type": "seen", "source": "https://t.me/cvedetector/15833", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21641 - Linux Kernel MPTCP Sysctl Blackhole Timeout Use-After-Free Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21641 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmptcp: sysctl: blackhole timeout: avoid using current->nsproxy  \n  \nAs mentioned in the previous commit, using the 'net' structure via  \n'current' is not recommended for different reasons:  \n  \n- Inconsistency: getting info from the reader's/writer's netns vs only  \n  from the opener's netns.  \n  \n- current->nsproxy can be NULL in some cases, resulting in an 'Oops'  \n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by  \n  syzbot [1] using acct(2).  \n  \nThe 'pernet' structure can be obtained from the table->data using  \ncontainer_of(). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"19 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:07:20.000000Z"}, {"uuid": "4d71aa14-cdf1-422f-95e4-f1f6b1d3a65a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21640", "type": "seen", "source": "https://t.me/cvedetector/15832", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21640 - Apache Linux Kernel SCTP Null Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21640 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy  \n  \nAs mentioned in a previous commit of this series, using the 'net'  \nstructure via 'current' is not recommended for different reasons:  \n  \n- Inconsistency: getting info from the reader's/writer's netns vs only  \n  from the opener's netns.  \n  \n- current->nsproxy can be NULL in some cases, resulting in an 'Oops'  \n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by  \n  syzbot [1] using acct(2).  \n  \nThe 'net' structure can be obtained from the table->data using  \ncontainer_of().  \n  \nNote that table->data could also be used directly, as this is the only  \nmember needed from the 'net' structure, but that would increase the size  \nof this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' is  \nused. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"19 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:07:19.000000Z"}, {"uuid": "6a784d26-6361-49fc-a889-ba25b4f57630", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21649", "type": "seen", "source": "https://t.me/cvedetector/15827", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21649 - Here is the title for the vulnerability: \"Huawei HNS3 Net Driver Null Pointer Dereference Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2025-21649 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: hns3: fix kernel crash when 1588 is sent on HIP08 devices  \n  \nCurrently, HIP08 devices does not register the ptp devices, so the  \nhdev->ptp is NULL. But the tx process would still try to set hardware time  \nstamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.  \n  \n[  128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018  \n...  \n[  128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge]  \n[  128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge]  \n[  128.292938] sp : ffff800059b93140  \n[  128.297200] x29: ffff800059b93140 x28: 0000000000003280  \n[  128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080  \n[  128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001  \n[  128.315969] x23: 0000000000000000 x22: 0000000000000194  \n[  128.322219] x21: ffff0cd94f986000 x20: 0000000000000000  \n[  128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000  \n[  128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24  \n[  128.340934] x15: 0000ffffd530a518 x14: 0000000000000000  \n[  128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368  \n[  128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02  \n[  128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0  \n[  128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000  \n[  128.372040] x5 : 0000000000000000 x4 : 000000000000ffff  \n[  128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294  \n[  128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080  \n[  128.390626] Call trace:  \n[  128.393964]  hclge_ptp_set_tx_info+0x2c/0x140 [hclge]  \n[  128.399893]  hns3_nic_net_xmit+0x39c/0x4c4 [hns3]  \n[  128.405468]  xmit_one.constprop.0+0xc4/0x200  \n[  128.410600]  dev_hard_start_xmit+0x54/0xf0  \n[  128.415556]  sch_direct_xmit+0xe8/0x634  \n[  128.420246]  __dev_queue_xmit+0x224/0xc70  \n[  128.425101]  dev_queue_xmit+0x1c/0x40  \n[  128.429608]  ovs_vport_send+0xac/0x1a0 [openvswitch]  \n[  128.435409]  do_output+0x60/0x17c [openvswitch]  \n[  128.440770]  do_execute_actions+0x898/0x8c4 [openvswitch]  \n[  128.446993]  ovs_execute_actions+0x64/0xf0 [openvswitch]  \n[  128.453129]  ovs_dp_process_packet+0xa0/0x224 [openvswitch]  \n[  128.459530]  ovs_vport_receive+0x7c/0xfc [openvswitch]  \n[  128.465497]  internal_dev_xmit+0x34/0xb0 [openvswitch]  \n[  128.471460]  xmit_one.constprop.0+0xc4/0x200  \n[  128.476561]  dev_hard_start_xmit+0x54/0xf0  \n[  128.481489]  __dev_queue_xmit+0x968/0xc70  \n[  128.486330]  dev_queue_xmit+0x1c/0x40  \n[  128.490856]  ip_finish_output2+0x250/0x570  \n[  128.495810]  __ip_finish_output+0x170/0x1e0  \n[  128.500832]  ip_finish_output+0x3c/0xf0  \n[  128.505504]  ip_output+0xbc/0x160  \n[  128.509654]  ip_send_skb+0x58/0xd4  \n[  128.513892]  udp_send_skb+0x12c/0x354  \n[  128.518387]  udp_sendmsg+0x7a8/0x9c0  \n[  128.522793]  inet_sendmsg+0x4c/0x8c  \n[  128.527116]  __sock_sendmsg+0x48/0x80  \n[  128.531609]  __sys_sendto+0x124/0x164  \n[  128.536099]  __arm64_sys_sendto+0x30/0x5c  \n[  128.540935]  invoke_syscall+0x50/0x130  \n[  128.545508]  el0_svc_common.constprop.0+0x10c/0x124  \n[  128.551205]  do_el0_svc+0x34/0xdc  \n[  128.555347]  el0_svc+0x20/0x30  \n[  128.559227]  el0_sync_handler+0xb8/0xc0  \n[  128.563883]  el0_sync+0x160/0x180 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"19 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:07:12.000000Z"}, {"uuid": "4109d424-3ede-4343-9b36-5b70c3ac5bc7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21648", "type": "seen", "source": "https://t.me/cvedetector/15826", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21648 - \"Linux Netfilter Conntrack INT_MAXHashtable Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2025-21648 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetfilter: conntrack: clamp maximum hashtable size to INT_MAX  \n  \nUse INT_MAX as maximum size for the conntrack hashtable. Otherwise, it  \nis possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when  \nresizing hashtable because __GFP_NOWARN is unset. See:  \n  \n  0708a0afe291 (\"mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls\")  \n  \nNote: hashtable resize is only possible from init_netns. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"19 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:07:09.000000Z"}, {"uuid": "4fc7f62e-886f-46eb-a7de-4721343236cf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21647", "type": "seen", "source": "https://t.me/cvedetector/15825", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21647 - Linux Kernel sch_cake Out-of-Bounds Memory Access Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21647 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsched: sch_cake: add bounds checks to host bulk flow fairness counts  \n  \nEven though we fixed a logic error in the commit cited below, syzbot  \nstill managed to trigger an underflow of the per-host bulk flow  \ncounters, leading to an out of bounds memory access.  \n  \nTo avoid any such logic errors causing out of bounds memory accesses,  \nthis commit factors out all accesses to the per-host bulk flow counters  \nto a series of helpers that perform bounds-checking before any  \nincrements and decrements. This also has the benefit of improving  \nreadability by moving the conditional checks for the flow mode into  \nthese helpers, instead of having them spread out throughout the  \ncode (which was the cause of the original logic error).  \n  \nAs part of this change, the flow quantum calculation is consolidated  \ninto a helper function, which means that the dithering applied to the  \nost load scaling is now applied both in the DRR rotation and when a  \nsparse flow's quantum is first initiated. The only user-visible effect  \nof this is that the maximum packet size that can be sent while a flow  \nstays sparse will now vary with +/- one byte in some cases. This should  \nnot make a noticeable difference in practice, and thus it's not worth  \ncomplicating the code to preserve the old behaviour. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"19 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:07:08.000000Z"}, {"uuid": "8edf9d23-54cb-4b07-a99d-6ffd6826e76f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21645", "type": "seen", "source": "https://t.me/cvedetector/15824", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21645 - AMD PMC Linux Kernel Wakeup Handling Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2025-21645 \nPublished : Jan. 19, 2025, 11:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nplatform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it  \n  \nWakeup for IRQ1 should be disabled only in cases where i8042 had  \nactually enabled it, otherwise \"wake_depth\" for this IRQ will try to  \ndrop below zero and there will be an unpleasant WARN() logged:  \n  \nkernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug  \nkernel: ------------[ cut here ]------------  \nkernel: Unbalanced IRQ 1 wake disable  \nkernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0  \n  \nThe PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops  \nwhich sets amd_pmc_suspend_handler() to the .suspend, .freeze, and  \n.poweroff handlers. i8042_pm_suspend(), however, is only set as  \nthe .suspend handler.  \n  \nFix the issue by call PMC suspend handler only from the same set of  \ndev_pm_ops handlers as i8042_pm_suspend(), which currently means just  \nthe .suspend handler.  \n  \nTo reproduce this issue try hibernating (S4) the machine after a fresh boot  \nwithout putting it into s2idle first.  \n  \n[ij: edited the commit message.] \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"19 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-19T13:07:07.000000Z"}]}