In the Linux kernel, the following vulnerability has been resolved:
ipv4: validate checksum_start before completing checksum
If a packet with bad checksum metadata gets into the ipv4 stack,
skb_checksum_help can corrupt the network header and cause a bunch of
mischief.
This was discovered and reported by Paulos, and has been reporoduced
by others independently since.
We really shouldn't allow such packets in, but as a defence
in depth measure, let's also check before we complete the checksum.
A more complete validation at input is forthcoming, but needs more work.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
CVSS Score: 9.3
AV:L - A malicious microVM supplies crafted virtio-net checksum metadata with its outbound frame. The VMM writes it to the host TAP, where tun_get_user() feeds the skb to the IPv4 stack and ip_do_fragment() calls skb_checksum_help(); this is a guest/local virtual-device path, not an Internet receive path.
AC:L - The guest controls the frame, checksum start and offset, and packet size and can repeat the same fragmentation sequence. No race, timing window, or uncontrollable memory layout is needed; host leak, crash, and code-execution variants were reproduced with crafted packets.
PR:N - In the microVM scenario, a tenant workload able to transmit through its assigned virtio-net interface can supply the triggering traffic. It needs no host credentials, capability, or access to /dev/net/tun; the privileged VMM merely forwards guest output to its existing TAP fd.
UI:N - The attacker sends the crafted guest packets directly, and host TAP/IPv4 processing invokes checksum completion automatically. No host administrator or other victim must act.
S:C - The checksum metadata originates in an untrusted microVM, but skb_checksum_help() and ip_do_fragment() process and corrupt state in the host kernel. The demonstrated leak, crash, and administrator code execution cross the guest-to-host isolation boundary.
C:H - After skb_checksum_help() changes an already-validated IPv4 IHL, ip_do_fragment() trusts the new length and ip_frag_next() copies beyond the skb's logical linear head into transmitted IPv4 options. This was demonstrated as continuous host-memory disclosure in guest-emitted packets.
I:H - skb_checksum_help() writes at the attacker-controlled checksum position inside an IPv4 header after routing and validation, and downstream code trusts the modified fields. Crafted guest packets using this flaw were demonstrated to execute commands with full administrator privileges on the host.
A:H - Malformed checksum offsets reach skb_checksum_help() from IPv4 fragmentation and can trip WARN_ONCE/panic paths or poison the header geometry used downstream. Crafted guest packets were demonstrated to crash the physical host, taking down all sandboxes on it. -- Thanks, Sasha
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - A malicious microVM supplies crafted virtio-net checksum metadata with its outbound frame. The VMM writes it to the host TAP, where tun_get_user() feeds the skb to the IPv4 stack and ip_do_fragment() calls skb_checksum_help(); this is a guest/local virtual-device path, not an Internet receive path.
AC:L - The guest controls the frame, checksum start and offset, and packet size and can repeat the same fragmentation sequence. No race, timing window, or uncontrollable memory layout is needed; host leak, crash, and code-execution variants were reproduced with crafted packets.
PR:N - In the microVM scenario, a tenant workload able to transmit through its assigned virtio-net interface can supply the triggering traffic. It needs no host credentials, capability, or access to /dev/net/tun; the privileged VMM merely forwards guest output to its existing TAP fd.
UI:N - The attacker sends the crafted guest packets directly, and host TAP/IPv4 processing invokes checksum completion automatically. No host administrator or other victim must act.
S:C - The checksum metadata originates in an untrusted microVM, but skb_checksum_help() and ip_do_fragment() process and corrupt state in the host kernel. The demonstrated leak, crash, and administrator code execution cross the guest-to-host isolation boundary.
C:H - After skb_checksum_help() changes an already-validated IPv4 IHL, ip_do_fragment() trusts the new length and ip_frag_next() copies beyond the skb's logical linear head into transmitted IPv4 options. This was demonstrated as continuous host-memory disclosure in guest-emitted packets.
I:H - skb_checksum_help() writes at the attacker-controlled checksum position inside an IPv4 header after routing and validation, and downstream code trusts the modified fields. Crafted guest packets using this flaw were demonstrated to execute commands with full administrator privileges on the host.
A:H - Malformed checksum offsets reach skb_checksum_help() from IPv4 fragmentation and can trip WARN_ONCE/panic paths or poison the header geometry used downstream. Crafted guest packets were demonstrated to crash the physical host, taking down all sandboxes on it. -- Thanks, Sasha
CVSS 3.1