CVE-2026-43503

What it actually does

This is a Linux kernel sk_buff metadata propagation flaw. Several skb fragment-transfer paths move references to shared, externally owned, or page-cache-backed memory pages into a new skb but fail to preserve the SKBFL_SHARED_FRAG marker. Later in-place network writers, notably ESP/IPsec input handling, may incorrectly believe the packet data is private and skip copy-on-write via skb_cow_data(). That can allow writes into shared backing pages, including page-cache pages associated with files that should be read-only to the attacker. The likely consequences are kernel-mediated memory or page-cache corruption, integrity bypass, local privilege escalation, and possible denial of service depending on the reachable network path and kernel configuration.

Why it matters to the business

A successful attacker with local access can potentially tamper with protected data or system files through the kernel despite normal file permissions, which can lead to privilege escalation, service compromise, data corruption, or system instability. The issue affects the Linux kernel broadly rather than a single application, so exposure depends on deployed kernel versions, enabled networking/IPsec functionality, and use of packet duplication paths such as nftables dup or TEE-style forwarding. Although this is not currently listed in CISA KEV and the supplied EPSS score is low, the high CVSS score and named threat-actor context warrant prioritized remediation on multi-user systems, container hosts, VPN/IPsec gateways, and systems where untrusted users can execute code.

How an attack unfolds

An attacker first obtains low-privileged local execution on a vulnerable Linux system. They then arrange for packet processing that causes skb fragments backed by shared or page-cache memory to be transferred through affected helpers without carrying the shared-fragment marker. One described path uses packet duplication, such as an nftables dup to local destination rule or another nf_dup_ipv4()/xt_TEE caller, so that a copied skb reaches ESP input processing. Because the destination skb still references shared pages but no longer reports them as shared, ESP in-place processing can modify data without first copying it. Under the right conditions, those writes land in page-cache-backed data for files the attacker should not be able to modify, enabling protected file tampering, privilege escalation, or corruption. The provided threat-actor label DirtyClone should be treated as hunt context even though exploit maturity is listed as none and the vulnerability is not currently KEV-listed.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the fix for SKBFL_SHARED_FRAG propagation across affected skb fragment-transfer helpers, including __pskb_copy_fclone(), skb_shift(), skb_gro_receive(), skb_gro_receive_list(), tcp_clone_payload(), and skb_segment(). No fixed version was provided in the input, so use the relevant distribution or kernel vendor advisory as the source of truth and deploy the latest patched kernel for each supported branch. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, reviewing nftables/iptables TEE or dup usage, disabling unnecessary IPsec/ESP paths, and minimizing configurations that allow untrusted users to influence packet-processing paths. Treat mitigations as temporary because this is a kernel memory/page-cache integrity issue best addressed by patching.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated to a vendor build containing the fix. Validate with uname -a, package-manager kernel inventory, and vendor advisory metadata. If source or symbol-level validation is possible, verify that skb fragment-transfer paths propagate SKBFL_SHARED_FRAG when moving shared fragments. Review nftables and iptables rules for dup or TEE paths and review IPsec/XFRM ESP configurations to understand remaining exposure. After reboot, confirm no vulnerable older kernel remains selected as the default boot entry and that live-patching coverage, if used, explicitly includes this fix. Functional validation should include regression testing for packet forwarding, IPsec/VPN traffic, GRO/GSO-heavy workloads, and container networking.

Typical attack path

1. Gain low-privileged local code execution on a vulnerable Linux host.
2. Identify or create a reachable networking path involving fragmented skb data and packet duplication, GRO, segmentation, TCP payload cloning, or related skb fragment-transfer behavior.
3. Trigger packet processing that moves shared skb fragments into a destination skb without preserving the SKBFL_SHARED_FRAG marker.
4. Route the malformed metadata state into an in-place writer such as ESP/IPsec input processing.
5. Cause the kernel to write into memory or page-cache-backed pages that should have been treated as shared and copied first.
6. Use the resulting protected-file or memory corruption to alter system behavior, escalate privileges, corrupt data, or crash services.

How to detect it

There is unlikely to be a reliable universal kernel log entry for successful exploitation. Detection should combine exposure review, file-integrity monitoring, and forensic analysis. Collect kernel version data, nftables and iptables rules, XFRM/IPsec state, VPN configuration, auditd logs, EDR telemetry, package verification output, and file-integrity-monitoring alerts. Look for local users or workloads creating traffic that exercises ESP/IPsec and packet duplication paths, especially near the time of unexpected changes to root-owned or read-only files. Review audit logs for writes, renames, or metadata changes to privileged files that do not match authorized package management or configuration-management activity. Check for unexplained package verification failures, altered binaries or libraries, setuid/setgid changes, suspicious new persistence files, kernel oops/panic messages in networking or ESP paths, and unexpected nftables or iptables rule changes involving dup or TEE. For systems with threat-intelligence correlation, search for references to DirtyClone in case notes, detections, malware labels, or campaign tags, but validate with host evidence before declaring compromise.

• nft.*dup to
• dup to
• -j TEE
• --gateway
• xt_TEE
• nf_dup_ipv4
• authencesn
• esp4
• esp6
• ip xfrm state
• ip xfrm policy
• SKBFL_SHARED_FRAG
• skb_has_shared_frag
• skb_cow_data
• __pskb_copy_fclone
• skb_shift
• skb_gro_receive
• skb_gro_receive_list
• tcp_clone_payload
• skb_segment
• DirtyClone

What your security team should do

• Prioritize patching internet-facing VPN/IPsec systems, multi-user Linux servers, container hosts, CI/build workers, and systems running untrusted code.
• Inventory running kernel versions across Linux fleets and map them to vendor advisories that include this fix.
• Reboot systems after kernel updates and verify the active kernel version post-reboot.
• Hunt for risky exposure patterns such as nftables dup rules, iptables TEE targets, nf_dup usage, and active ESP/IPsec XFRM states, especially on systems with local untrusted users.
• Monitor for unexpected modification of root-owned or read-only files, package verification failures, integrity-monitoring alerts, and unexplained kernel instability.
• Treat DirtyClone as threat context for hunting and threat-intelligence correlation, but do not assume exploitation solely from the presence of prerequisite networking rules.
• If patching must be delayed, restrict local access, reduce privileges for untrusted workloads, isolate containers more strongly, and temporarily remove unnecessary packet duplication or IPsec processing paths.