CVE-2024-44991
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2024-44991
- Import Source
- https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-44991.json
- JSON Data
- https://api.osv.dev/v1/vulns/CVE-2024-44991
- Downstream
- Related
- Published
- 2024-09-04T19:54:38Z
- Modified
- 2025-10-22T02:26:47.443977Z
- Summary
- tcp: prevent concurrent execution of tcp_sk_exit_batch
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
tcp: prevent concurrent execution of tcpskexit_batch
Its possible that two threads call tcpskexitbatch() concurrently, once from the cleanupnet workqueue, once from a task that failed to clone a new netns. In the latter case, error unwinding calls the exit handlers in reverse order for the 'failed' netns.
tcpskexitbatch() calls tcptwskpurge(). Problem is that since commit b099ce2602d8 ("net: Batch inettwskpurge"), this function picks up twsk in any dying netns, not just the one passed in via exitbatch list.
This means that the error unwind of setup_net() can "steal" and destroy timewait sockets belonging to the exiting netns.
This allows the netns exit worker to proceed to call
WARNONONCE(!refcountdecandtest(&net->ipv4.tcpdeathrow.twrefcount));
without the expected 1 -> 0 transition, which then splats.
At same time, error unwind path that is also running inettwskpurge() will splat as well:
WARNING: .. at lib/refcount.c:31 refcountwarnsaturate+0x1ed/0x210 ... refcountdec include/linux/refcount.h:351 [inline] inettwskkill+0x758/0x9c0 net/ipv4/inettimewaitsock.c:70 inettwskdescheduleput net/ipv4/inettimewaitsock.c:221 inettwskpurge+0x725/0x890 net/ipv4/inettimewaitsock.c:304 tcpskexitbatch+0x1c/0x170 net/ipv4/tcpipv4.c:3522 opsexitlist+0x128/0x180 net/core/netnamespace.c:178 setupnet+0x714/0xb40 net/core/netnamespace.c:375 copynetns+0x2f0/0x670 net/core/netnamespace.c:508 createnewnamespaces+0x3ea/0xb10 kernel/nsproxy.c:110
... because refcountdec() of twrefcount unexpectedly dropped to 0.
This doesn't seem like an actual bug (no tw sockets got lost and I don't see a use-after-free) but as erroneous trigger of debug check.
Add a mutex to force strict ordering: the task that calls tcptwskpurge() blocks other task from doing final decand_test before mutex-owner has removed all tw sockets of dying netns.
- References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- https://git.kernel.org/stable/c/565d121b69980637f040eb4d84289869cdaabedf
- https://git.kernel.org/stable/c/99580ae890ec8bd98b21a2a9c6668f8f1555b62e
- https://git.kernel.org/stable/c/e3d9de3742f4d5c47ae35f888d3023a5b54fcd2f
- https://git.kernel.org/stable/c/f6fd2dbf584a4047ba88d1369ff91c9851261ec1
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducede9bd0cca09d13ac2f08d25e195203e42d4ad1ce8Fixede3d9de3742f4d5c47ae35f888d3023a5b54fcd2f
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducede9bd0cca09d13ac2f08d25e195203e42d4ad1ce8Fixed99580ae890ec8bd98b21a2a9c6668f8f1555b62e
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducede9bd0cca09d13ac2f08d25e195203e42d4ad1ce8Fixedf6fd2dbf584a4047ba88d1369ff91c9851261ec1
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introducede9bd0cca09d13ac2f08d25e195203e42d4ad1ce8Fixed565d121b69980637f040eb4d84289869cdaabedf