DEBIAN-CVE-2024-44991

See a problem?
Please try reporting it to the source first.
Source
https://security-tracker.debian.org/tracker/CVE-2024-44991
Import Source
https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-44991.json
JSON Data
https://api.test.osv.dev/v1/vulns/DEBIAN-CVE-2024-44991
Upstream
Published
2024-09-04T20:15:08Z
Modified
2025-09-25T23:30:11.688248Z
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 tcpskexitbatch 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 setupnet() 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

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:14 / 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

Ecosystem specific 

{
    "urgency": "not yet assigned"
}

Debian:11 / linux-6.1

Package

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

Affected ranges

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

Affected versions

6.*

6.1.106-3~deb11u1
6.1.106-3~deb11u2
6.1.106-3~deb11u3
6.1.112-1~deb11u1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}