CVE-2022-49872: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2022-49872

In the Linux kernel, the following vulnerability has been resolved: net: gso: fix panic on frag_list with mixed head alloc types Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list"), it is allowed to change gso_size of a GRO packet. However, that commit assumes that "checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too". It turns out this assumption does not hold. We've seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced. There are three different locations where this can be fixed: (1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem. (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list. (3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down. This patch implements (3). To limit the performance impact in skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set that have gso_size changed. Normal paths thus will not hit it. We could check only the last skb but since we need to walk the whole list anyway, let's stay on the safe side.

AI Analysis

Technical Summary

CVE-2022-49872 is a vulnerability in the Linux kernel's network stack, specifically related to the Generic Segmentation Offload (GSO) and Generic Receive Offload (GRO) packet processing mechanisms. The issue arises from an incorrect assumption in the skb_segment function about the memory allocation types of sk_buff (socket buffer) fragments in a frag_list. The vulnerability stems from the fact that skbs on the frag_list can have mixed head allocation types—some page-backed and others kmalloced—due to the behavior of __netdev_alloc_skb and __napi_alloc_skb functions, which allocate skbs differently based on size. The original code assumed that checking the first list_skb member's head_frag status was sufficient, but this assumption fails when the last small skb in the GRO packet is kmalloced, leading to a kernel panic (BUG_ON) during segmentation. The patch implemented addresses this by walking the entire frag_list in skb_segment when determining whether to clear the NETIF_F_SG flag, but only for skbs marked with SKB_GSO_DODGY and where gso_size has changed, to minimize performance impact. This fix prevents the kernel panic by ensuring consistent handling of mixed allocation types in frag_lists during packet segmentation. The vulnerability affects multiple Linux kernel versions prior to the patch and is particularly relevant for network drivers like vmxnet3 that can produce such mixed allocation scenarios. No known exploits are currently reported in the wild.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems running vulnerable Linux kernel versions, especially those utilizing network drivers like vmxnet3 commonly found in virtualized environments (e.g., VMware). A successful exploitation leads to a kernel panic, causing denial of service (DoS) by crashing the affected system or network interface. This can disrupt critical services, especially in data centers, cloud infrastructure, and enterprise networks heavily reliant on Linux-based servers. While the vulnerability does not appear to allow privilege escalation or remote code execution directly, the resulting DoS can impact availability of services, potentially affecting business operations, service level agreements, and customer trust. Organizations with high network traffic and GSO/GRO enabled may experience higher exposure. Given the widespread use of Linux in European IT infrastructure, the impact can be significant if unpatched systems are exploited, particularly in sectors like finance, telecommunications, and government where uptime is critical.

Mitigation Recommendations

1. Apply the official Linux kernel patches that address CVE-2022-49872 as soon as they become available for your distribution. This is the most effective mitigation. 2. For environments using virtualized network drivers such as vmxnet3, ensure that the latest driver and kernel versions are deployed to avoid mixed allocation issues. 3. Monitor kernel logs for BUG_ON or panic messages related to skb_segment or GSO/GRO processing to detect potential exploitation attempts or instability. 4. If immediate patching is not feasible, consider disabling GSO/GRO features temporarily on affected interfaces to reduce the risk of triggering the vulnerability, understanding this may impact network performance. 5. Implement robust system monitoring and automated recovery mechanisms to minimize downtime in case of kernel panics. 6. Regularly update and audit Linux kernel versions across all critical infrastructure to maintain security posture against emerging vulnerabilities.