CVE-2026-43503

Think of the Linux kernel as the system’s traffic controller and memory manager. This bug makes the kernel sometimes “forget” that certain pieces of network data still point to shared memory, which can trick the kernel into letting a malicious local user overwrite parts of memory they shouldn’t. In the worst case, that can become a root-level takeover.

This matters if you run Linux systems where untrusted users or tenants can already get local execution, especially in environments like containers or multi-tenant setups. The risky behavior depends on specific packet handling paths—ESP input (esp4.c/esp6.c) plus a local duplication pathway such as an nft “dup to ” rule (or an equivalent nf_dup_ipv4()/xt_TEE caller). The practical gate here is local access and reachability through those network/duplication features—this is not described as a simple remote, internet-triggerable bug.

Verdict: AMBER. There are credible reports of an exploit proof-of-concept being published, and this is a privilege-escalation style bug that targets the kernel, so you should patch, but it’s not clearly described as internet-wide exploitation. Prioritize Linux hosts that can be reached by untrusted local users and that use the ESP + duplication pattern (e.g., nft dup-to-local).

1. Confirm exposure by kernel version

   • On each affected host, record the running kernel version (uname -r) and also check how it was installed (distro package, vendor kernel, custom build).
   • Determine whether your kernel is older than the fix. The upstream fixed commits are:
     • fbeab9555564a1b98e8582cd106dfe46c4606991
     • 179f1852bdedc300e373e807cc102cd81feff196
     • 12401fcfb01f53ccc63ab0a3246570fe8f3105ee
     • 989214c66884d70716d83dc1d0bf5e16287bf349
     • fc6eb39c55e97df2f94ad974b8a5bbcd019da2c8
     • ff375cc75f9167168db38e0464a482d5fbc8d81d
     • 9bc9d6d6967a2239aa57af2aa53554eddd640d20
     • 48f6a5356a33dd78e7144ae1faef95ffc990aae0
   • If your vendor uses package versions rather than raw commit hashes, upgrade to the vendor kernel update that includes this fix.

2. Confirm whether your networking configuration can reach the vulnerable code paths

   • Check whether your system uses ESP input handling (esp4.c/esp6.c). Practically, this often correlates with whether you configure IPsec ESP or have kernel modules/services enabling that path.
   • Check nftables rules for duplication patterns, especially any rule resembling “dup to ”. Also review for other duplication/TEE-like usages tied to nf_dup_ipv4()/xt_TEE.
   • If you do not use those features, your risk is lower, but kernel patching is still the only complete fix.

3. Upgrade / patch

   • Upgrade the kernel to include the fix. Use your distribution’s standard kernel update mechanism (recommended) so you get the correct build and dependencies.
   • Make sure you reboot into the updated kernel and verify the running version.

4. If patching is delayed (temporary containment)

   • Reduce exposure by limiting untrusted local users/tenants (for example, tighten who can run workloads that can reach the networking stack).
   • Avoid enabling or using nftables duplication rules (like “dup to ”) and any nf_dup_ipv4()/xt_TEE configurations until patched, if feasible without breaking business operations.

5. What to monitor after updating

   • Track authentication/admin changes and any suspicious local activity on systems that previously used the risky packet paths.
   • Monitor for kernel update/boot completion and ensure the patched kernel remains the one running after reboot.

Note on KEV: This issue is not listed in CISA KEV based on the provided findings, and no dated “active exploitation in the wild” report is confirmed in the findings; however, exploitation capability has been demonstrated via proof-of-concept reporting, so treat patching as important for relevant hosts.

Severity is high (CVE-2026-43503; CVSS 8.8 as provided). This is a local privilege escalation mechanism in the Linux kernel networking stack: fragment-copy/shift helpers do not propagate the SKB shared-frag marker (skb_shinfo()->flags), causing code paths that rely on skb_has_shared_frag() to incorrectly decide pages don’t need copy-on-write/detouring.

Attack vector (from findings/backstop): a local attacker can leverage ESP input (esp4.c/esp6.c) and a packet duplication pathway—explicitly an nft “dup to ” rule or other nf_dup_ipv4()/xt_TEE caller—to create a cloned packet state where the shared-page relationship is misrepresented. The result is that the attacker can write into page-cache-backed memory associated with a root-owned read-only file.

Exploitation status: KEV is not listed, no public exploit code is on record per findings, and the press summary provided does not state active widespread exploitation with dates. Still, reporting indicates proof-of-concept exploitation was demonstrated (variant in the DirtyFrag family) and a working exploit was published.

Fix: The vulnerability is resolved by ensuring the shared-frag marker is set on the destination skb whenever fragment descriptors are actually moved/shared, with additional related helpers addressed for consistency (notably skb segmentation/GRO/cloning helpers in the backstop).