{"vulnerability": "CVE-2024-44991", "sightings": [{"uuid": "2e8088fa-e04f-48bc-ab8a-33d85113fc5d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "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"}]}