CVE-2024-43897

See a problem?
Source
https://nvd.nist.gov/vuln/detail/CVE-2024-43897
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-43897.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2024-43897
Related
Published
2024-08-26T11:15:04Z
Modified
2024-09-18T03:26:36.752103Z
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:

net: drop bad gso csumstart and offset in virtionet_hdr

Tighten csumstart and csumoffset checks in virtionethdrtoskb for GSO packets.

The function already checks that a checksum requested with VIRTIONETHDRFNEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation.

Syzkaller demonstrated to reach this warning in skbchecksumhelp

offset = skb_checksum_start_offset(skb);
ret = -EINVAL;
if (WARN_ON_ONCE(offset >= skb_headlen(skb)))

By injecting a TSO packet:

WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skbchecksumhelp+0x3d0/0x5b0 ipdofragment+0x209/0x1b20 net/ipv4/ipoutput.c:774 ipfinishoutputgso net/ipv4/ipoutput.c:279 [inline] _ipfinishoutput+0x2bd/0x4b0 net/ipv4/ipoutput.c:301 iptunnelxmit+0x50c/0x930 net/ipv4/iptunnelcore.c:82 iptunnelxmit+0x2296/0x2c70 net/ipv4/iptunnel.c:813 _grexmit net/ipv4/ipgre.c:469 [inline] ipgrexmit+0x759/0xa60 net/ipv4/ipgre.c:661 _netdevstartxmit include/linux/netdevice.h:4850 [inline] netdevstartxmit include/linux/netdevice.h:4864 [inline] xmitone net/core/dev.c:3595 [inline] devhardstartxmit+0x261/0x8c0 net/core/dev.c:3611 _devqueuexmit+0x1b97/0x3c90 net/core/dev.c:4261 packetsnd net/packet/afpacket.c:3073 [inline]

The geometry of the bad input packet at tcpgsosegment:

[ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) maclen=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nrfrags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ipsummed=3 completesw=0 valid=0 level=0)

Mitigate with stricter input validation.

csumoffset: for GSO packets, deduce the correct value from gsotype. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]ufofragment ignores these fields and always computes the checksum in software.

csumstart: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKBGSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload.

GSO packet are almost always CHECKSUMPARTIAL. USO packets may be CHECKSUMNONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4hwcsum/udp6hwcsumoutgoing. So no need to test for ipsummed == CHECKSUM_PARTIAL first.

This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests.

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.106-3

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

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.6-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.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

Ecosystem specific

{
    "urgency": "not yet assigned"
}