CVE-2024-44991

Source
https://nvd.nist.gov/vuln/detail/CVE-2024-44991
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-44991.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-44991
Related
Published
2024-09-04T20:15:08Z
Modified
2024-10-09T15:49:03.566355Z
Severity
  • 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
[none]
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

Affected packages

Debian:12 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.1.112-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3

Ecosystem specific

{
    "urgency": "not yet assigned"
}

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.10.7-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3
6.1.112-1
6.3.1-1~exp1
6.3.2-1~exp1
6.3.4-1~exp1
6.3.5-1~exp1
6.3.7-1~bpo12+1
6.3.7-1
6.3.11-1
6.4~rc6-1~exp1
6.4~rc7-1~exp1
6.4.1-1~exp1
6.4.4-1~bpo12+1
6.4.4-1
6.4.4-2
6.4.4-3~bpo12+1
6.4.4-3
6.4.11-1
6.4.13-1
6.5~rc4-1~exp1
6.5~rc6-1~exp1
6.5~rc7-1~exp1
6.5.1-1~exp1
6.5.3-1~bpo12+1
6.5.3-1
6.5.6-1
6.5.8-1
6.5.10-1~bpo12+1
6.5.10-1
6.5.13-1
6.6.3-1~exp1
6.6.4-1~exp1
6.6.7-1~exp1
6.6.8-1
6.6.9-1
6.6.11-1
6.6.13-1~bpo12+1
6.6.13-1
6.6.15-1
6.6.15-2
6.7-1~exp1
6.7.1-1~exp1
6.7.4-1~exp1
6.7.7-1
6.7.9-1
6.7.9-2
6.7.12-1~bpo12+1
6.7.12-1
6.8.9-1
6.8.11-1
6.8.12-1~bpo12+1
6.8.12-1
6.9.2-1~exp1
6.9.7-1~bpo12+1
6.9.7-1
6.9.8-1
6.9.9-1
6.9.10-1~bpo12+1
6.9.10-1
6.9.11-1
6.9.12-1
6.10-1~exp1
6.10.1-1~exp1
6.10.3-1
6.10.4-1
6.10.6-1~bpo12+1
6.10.6-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}