CVE-2022-49093·Kernel vulnerability
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().
- Severity
- high
- Software
- Kernel
- Fixed in
- 5.17.3
- Published
- 2025-02-26
Affected versions
From: 5.17
Until: 5.17.3
Fixed in: 5.17.3
How to fix this CVE
Update your Linux kernel to version 5.17.3 or later to resolve a critical use-after-free vulnerability in the page_pool fragment recycling mechanism. This flaw affects systems running kernels 5.17.0 through 5.17.2 and can lead to memory corruption when network packets are coalesced during TCP processing. Apply the patch immediately, especially on systems handling high-volume network traffic or those with IOMMU enabled.
sudo dnf update kernel kernel-develDefensia detects this vulnerability
How to check if you are affected
- Step 1: Check installed kernel version with `uname -r` and verify it is NOT in the 5.17.0–5.17.2 range
- Step 2: Confirm page_pool is active by checking if your network driver supports it: `grep -i page_pool /boot/config-$(uname -r)` or check driver capability with ethtool
- Step 3: Search system logs for IOMMU faults or memory corruption errors: `sudo journalctl -u kernel --no-pager | grep -i 'iommu\|page\|fault\|corruption'`
- Step 4: After patching, reboot and verify new kernel version: `uname -r` should show 5.17.3 or higher
FAQ
What is CVE-2022-49093?
CVE-2022-49093 is a use-after-free vulnerability in Linux kernel's skbuff coalescing logic when handling page_pool fragment recycling. It occurs when TCP combines network packets and incorrectly manages reference counts for shared memory pages, leading to premature page deallocation while hardware descriptors still reference the freed memory.
Is CVE-2022-49093 being actively exploited?
No, there is no evidence of active exploitation in the wild or public exploit code available for CVE-2022-49093. However, the vulnerability can be triggered through normal network operations on affected systems.
What versions of Kernel are affected by CVE-2022-49093?
Linux kernel versions 5.17.0, 5.17.1, and 5.17.2 are vulnerable. The fix was released in kernel version 5.17.3.
How do I check if my server is vulnerable to CVE-2022-49093?
Run `uname -r` to check your kernel version. If it shows 5.17.0, 5.17.1, or 5.17.2, your system is vulnerable. Also verify page_pool is enabled in your kernel: `grep CONFIG_PAGE_POOL /boot/config-$(uname -r)`.
What are the consequences of this vulnerability?
Exploitation can cause memory corruption, IOMMU faults, system crashes, or data loss. On systems with IOMMU disabled, memory corruption may occur silently without clear error messages.
Does Defensia detect CVE-2022-49093?
Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If Linux kernel is installed on a monitored server, CVE-2022-49093 will appear in your dashboard with remediation steps.
Related Kernel CVEs
References
Track CVEs across your fleet automatically
Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2022-49093. Free for 1 server.
Get started free