https://vulnerability.circl.lu/sightings/feed 2026-05-10T14:00:58.887444+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent sightings. https://vulnerability.circl.lu/sighting/2e8088fa-e04f-48bc-ab8a-33d85113fc5d/export 2026-05-10T14:00:59.401017+00:00 Automation user http://vulnerability.circl.lu/user/automation {"uuid": "2e8088fa-e04f-48bc-ab8a-33d85113fc5d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44991", "type": "seen", "source": "https://t.me/cvedetector/4860", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2024-44991 - Linux Kernel - Net namespace TCP Timewait Socket Deserialization Vulnerability\", \n \"Content\": \"CVE ID : CVE-2024-44991 \nPublished : Sept. 4, 2024, 8:15 p.m. | 27\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ntcp: prevent concurrent execution of tcp_sk_exit_batch \n \nIts possible that two threads call tcp_sk_exit_batch() concurrently, \nonce from the cleanup_net workqueue, once from a task that failed to clone \na new netns. In the latter case, error unwinding calls the exit handlers \nin reverse order for the 'failed' netns. \n \ntcp_sk_exit_batch() calls tcp_twsk_purge(). \nProblem is that since commit b099ce2602d8 (\"net: Batch inet_twsk_purge\"), \nthis function picks up twsk in any dying netns, not just the one passed \nin via exit_batch list. \n \nThis means that the error unwind of setup_net() can \"steal\" and destroy \ntimewait sockets belonging to the exiting netns. \n \nThis allows the netns exit worker to proceed to call \n \nWARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount)); \n \nwithout the expected 1 -> 0 transition, which then splats. \n \nAt same time, error unwind path that is also running inet_twsk_purge() \nwill splat as well: \n \nWARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 \n... \n refcount_dec include/linux/refcount.h:351 [inline] \n inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 \n inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 \n inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 \n tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 \n ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 \n setup_net+0x714/0xb40 net/core/net_namespace.c:375 \n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 \n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 \n \n... because refcount_dec() of tw_refcount unexpectedly dropped to 0. \n \nThis doesn't seem like an actual bug (no tw sockets got lost and I don't \nsee a use-after-free) but as erroneous trigger of debug check. \n \nAdd a mutex to force strict ordering: the task that calls tcp_twsk_purge() \nblocks other task from doing final _dec_and_test before mutex-owner has \nremoved all tw sockets of dying netns. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"04 Sep 2024\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T22:47:26.000000Z"} 2024-09-04T22:47:26+00:00