CVE-2026-43284
Memory Corruption in Linux Kernel XFRM ESP
Publication date: 2026-05-08
Last updated on: 2026-05-08
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 4.11 (inc) to 5.10.255 (exc) |
| linux | linux_kernel | From 5.12 (inc) to 5.15.205 (exc) |
| linux | linux_kernel | From 5.16 (inc) to 6.1.171 (exc) |
| linux | linux_kernel | From 6.13 (inc) to 6.18.28 (exc) |
| linux | linux_kernel | From 6.2 (inc) to 6.6.138 (exc) |
| linux | linux_kernel | From 6.7 (inc) to 6.12.87 (exc) |
| linux | linux_kernel | From 7.0 (inc) to 7.0.5 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-123 | Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow. |
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify how CVE-2026-43284 affects compliance with common standards and regulations such as GDPR or HIPAA.
Can you explain this vulnerability to me?
This vulnerability involves the Linux kernel's handling of ESP (Encapsulating Security Payload) packets within UDP datagrams. Specifically, when pages from a pipe are attached directly to an skb (socket buffer) using MSG_SPLICE_PAGES, TCP marks these skbs with a flag (SKBFL_SHARED_FRAG) to indicate shared fragments, prompting a private copy before modification. However, the IPv4/IPv6 datagram append paths did not set this flag for UDP skbs, causing ESP-in-UDP packets made from shared pipe pages to be treated like ordinary uncloned nonlinear skbs.
As a result, ESP input decrypts data in place on skbs that do not own the data privately, potentially modifying shared data incorrectly. The fix involves marking IPv4/IPv6 datagram splice fragments with the SKBFL_SHARED_FRAG flag and making ESP input fall back to a safer method (skb_cow_data()) when this flag is present, preventing in-place decryption on shared fragments.
How can this vulnerability impact me? :
This vulnerability can lead to incorrect in-place decryption of shared packet data, which may cause data corruption or unexpected behavior in the processing of ESP-in-UDP packets. Since the data being decrypted is not privately owned by the socket buffer, modifying it in place could affect other processes or network operations relying on the same shared data.
What immediate steps should I take to mitigate this vulnerability?
The vulnerability has been resolved in the Linux kernel by marking IPv4/IPv6 datagram splice fragments with SKBFL_SHARED_FRAG and making ESP input fall back to skb_cow_data() when this flag is present. To mitigate this vulnerability, you should update your Linux kernel to a version that includes this fix.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection of CVE-2026-43284 involves identifying if your Linux kernel is vulnerable and checking for signs of exploitation related to the Dirty Frag vulnerability.
Since this vulnerability affects the Linux kernel's handling of ESP-in-UDP packets and shared skb fragments, direct network detection is complex and not straightforward from network traffic alone.
A practical approach includes:
- Check your kernel version to see if it falls within the vulnerable range (from 2017-01-17 up to patched mainline kernels). Use the command: `uname -r`
- Look for loaded vulnerable kernel modules related to the exploit such as `esp4`, `esp6`, and `rxrpc` using: `lsmod | grep -E 'esp4|esp6|rxrpc'`
- Monitor system logs for unusual kernel messages or crashes that might indicate exploitation attempts.
- If you suspect exploitation, clear the page cache to remove contamination caused by the exploit using: `echo 3 > /proc/sys/vm/drop_caches`
Currently, no direct network scanning commands or signatures are provided for detecting this vulnerability in network traffic.