Skip to main content

CVE-2022-49093: Vulnerability in Linux Linux

High
VulnerabilityCVE-2022-49093cvecve-2022-49093
Published: Wed Feb 26 2025 (02/26/2025, 01:54:47 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

In the Linux kernel, the following vulnerability has been resolved: skbuff: fix coalescing for page_pool fragment recycling Fix a use-after-free when using page_pool with page fragments. We encountered this problem during normal RX in the hns3 driver: (1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through page_pool, and the other two allocate one half of PAGE2 each. Page references look like this: RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ (2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcp_queue_rcv(). (3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netif_receive_skb(): netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2) SKB2 and SKB3 share a reference to PAGE2 through skb_shinfo()->dataref. The other ref to PAGE2 is still held by RX_BD3: SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/ (3b) Now while handling TCP, coalesce SKB3 with SKB1: tcp_v4_rcv(SKB3) tcp_try_coalesce(to=SKB1, from=SKB3) // succeeds kfree_skb_partial(SKB3) skb_release_data(SKB3) // drops one dataref SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/ In skb_try_coalesce(), __skb_frag_ref() takes a page reference to PAGE2, where it should instead have increased the page_pool frag reference, pp_frag_count. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow. (3c) Drop SKB2: af_packet_rcv(SKB2) consume_skb(SKB2) skb_release_data(SKB2) // drops second dataref page_pool_return_skb_page(PAGE2) // drops one pp_frag_count SKB1 _____ PAGE1 \____ PAGE2 / RX_BD3 _________/ (4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well: tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // drops second pp_frag_count (5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled. Change the logic that checks whether pp_recycle SKBs can be coalesced. We still reject differing pp_recycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pp_recycled and 'from' is cloned. The new logic allows coalescing a cloned pp_recycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skb_try_coalesce().

AI-Powered Analysis

AILast updated: 07/03/2025, 03:39:46 UTC

Technical Analysis

CVE-2022-49093 is a high-severity use-after-free vulnerability in the Linux kernel's networking subsystem, specifically related to the handling of socket buffers (skbuff) and page_pool fragment recycling. The vulnerability arises from incorrect reference counting when coalescing socket buffers that share page fragments allocated from a page_pool. The flaw occurs during the receive (RX) path in network drivers such as hns3, where multiple descriptors reference shared memory pages. When TCP coalescing merges cloned skbuffs, the reference counting logic mistakenly drops more references than it should, leading to premature freeing of memory pages still in use by other RX descriptors. This can cause memory corruption or IOMMU faults if the memory is accessed after being freed. The root cause is that skb_try_coalesce() increases the page reference count incorrectly by taking a standard page reference instead of incrementing the page_pool fragment reference count (pp_frag_count). The fix involves changing the logic to reject coalescing in cases where both skbuffs are recycled from the page_pool and the 'from' skbuff is cloned, preventing the double free scenario. This vulnerability affects Linux kernel versions containing the specified commit hashes and is rated with a CVSS 3.1 score of 7.8 (high), reflecting its potential to impact confidentiality, integrity, and availability without requiring user interaction but requiring local privileges. Although no known exploits are reported in the wild, the vulnerability could be leveraged by an attacker with local access and limited privileges to cause system crashes, memory corruption, or potentially escalate privileges by exploiting kernel memory corruption.

Potential Impact

For European organizations, this vulnerability poses a significant risk especially for those relying on Linux-based infrastructure in critical environments such as data centers, cloud services, telecommunications, and industrial control systems. The flaw could lead to denial of service through kernel crashes or unpredictable behavior due to memory corruption. In worst cases, it might enable privilege escalation or arbitrary code execution within the kernel context, threatening system confidentiality and integrity. Organizations running network-intensive workloads or using affected network drivers (e.g., hns3) are particularly vulnerable. The impact is heightened in environments where Linux is used as a network gateway, firewall, or router, as exploitation could disrupt network traffic or compromise network security. Given the widespread use of Linux in European public sector, financial institutions, and technology providers, the vulnerability could affect critical services and infrastructure, potentially causing operational disruptions and data breaches.

Mitigation Recommendations

European organizations should promptly apply the official Linux kernel patches that address CVE-2022-49093 once available. Until patches are deployed, organizations should: 1) Restrict local access to Linux systems to trusted users only, minimizing the risk of exploitation by unprivileged attackers. 2) Monitor kernel logs and system behavior for signs of memory corruption or unexpected crashes related to network drivers. 3) Where feasible, disable or replace affected network drivers (such as hns3) with alternatives not impacted by this vulnerability. 4) Employ kernel hardening techniques such as Kernel Address Space Layout Randomization (KASLR), Kernel Page Table Isolation (KPTI), and seccomp filters to reduce exploitation likelihood. 5) Use security monitoring tools capable of detecting anomalous kernel activity or exploitation attempts. 6) Conduct thorough testing of kernel updates in staging environments before production deployment to ensure stability. 7) Maintain up-to-date inventory of Linux kernel versions and network drivers in use to prioritize patching efforts. These steps go beyond generic advice by focusing on access control, driver management, and proactive detection tailored to this specific vulnerability.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2025-02-26T01:49:39.249Z
Cisa Enriched
true
Cvss Version
3.1
State
PUBLISHED

Threat ID: 682d982fc4522896dcbe6b18

Added to database: 5/21/2025, 9:09:03 AM

Last enriched: 7/3/2025, 3:39:46 AM

Last updated: 8/16/2025, 11:49:31 AM

Views: 17

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats