Willem De Bruijn

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: The issue concerns the Linux kernel, where a vulnerability has been resolved related to the handling of UDP GSO fraglist segmentation after data is pulled from the frag list. This occurs when optional datapath hooks, such as NAT and BPF, modify SKBs, breaking their invariants. In extreme cases, this can cause a NULL pointer dereference. The fix involves detecting SKBs with corrupted geometry and passing them to skb segment instead of skb segment list. Recommendations: For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider restricting the use of optional datapath hooks such as NAT and BPF to minimize the risk of exploitation.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue concerns the Linux kernel's handling of TCP fragmentation. Specifically, it involves the `net: gso: fix tcp fraglist segmentation after pull from frag list` fix, which addresses a problem where optional datapath hooks like NAT and BPF can modify SKB GSO FRAGLIST skbs, breaking their invariants. This can lead to a NULL pointer dereference in ` tcpv4 gso segment list csum` at `tcp hdr(seg->next)`. The solution involves detecting invalid geometry due to pull by checking the `head skb` size and converting it to be able to pass to regular `skb segment` instead of `skb segment list`. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.6.58 Description: The issue arises from insufficient sanity checks in the `qdisc pkt len init()` function, specifically when handling `SKB GSO DODGY` packets. The `virtio net hdr to skb()` function does not fully dissect TCP headers, only ensuring they are at least 20 bytes long. This allows a user to craft a malicious 'GSO' packet with a total length of 80 bytes, comprising a 20-byte IPv4 header, a 60-byte TCP header, and a small `gso size` like 8. As a result, `virtio net hdr to skb()` would incorrectly identify this packet as a normal GSO packet due to the perceived payload size being larger than `gso size`. This can lead to an underflow in `qdisc skb cb(skb)->pkt len`. Recommendations: For Linux kernel versions prior to 6.6.58, update to version 6.6.58 or later to resolve the issue. As a temporary workaround, consider implementing additional sanity checks for `SKB GSO DODGY` packets to prevent underflow in `qdisc skb cb(skb)->pkt len`. Restrict the use of `virtio net hdr to skb()` function until the update is applied to minimize the risk of exploitation.

The issue is related to the function `gue gro receive()` in the Linux kernel, which has a problem with incorrect input validation. This can potentially impact the confidentiality, integrity, and availability of protected information. The vulnerability is related to the handling of unsupported protocols in the `gue gro receive()` function. A packet can be easily constructed to trigger a warning, which was previously reduced from `WARN ON` to `WARN ON ONCE`. The warning has been removed as it is expected and not actionable.

The issue is related to the Linux kernel's handling of UDP tunnel packets. When `NETIF F GRO FRAGLIST` or `NETIF F GRO UDP FWD` are enabled and UDP tunnels are available, the `udp gro receive()` function could perform L4 aggregation at the outer UDP tunnel level, leading to inner protocol corruption. This can cause issues with packets carrying vxlan headers, where different vxlan ids may be ignored or aggregated to the same GSO packet. To resolve this, the code path for `SKB GSO UDP L4` and `SKB GSO FRAGLIST` is skipped if the packet could land in a UDP tunnel, and `udp gro receive()` is allowed to do GRO via `udp sk(sk)->gro receive`. The check implemented is broader than necessary, but covering the corner case would add complexity.