# CVE-2026-43503: net: skbuff: propagate shared-frag marker through frag-transfer helpers

> An unprivileged user can escalate privileges by writing to root-owned files via a kernel bug in network packet handling when specific firewall rules are active.

- **Severity:** High 8.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 23 May 2026
- **Updated:** 16 Oct 2026
- **Also known as:** AZL-87348, BELL-CVE-2026-43503, DEBIAN-CVE-2026-43503, GHSA-494p-q444-9xf7, ROOT-OS-DEBIAN-11-CVE-2026-43503, ROOT-OS-DEBIAN-12-CVE-2026-43503, UBUNTU-CVE-2026-43503

## What is CVE-2026-43503?

CVE-2026-43503 is a high-severity vulnerability in Linux kernel, published on 23 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

net: skbuff: propagate shared-frag marker through frag-transfer helpers

Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail
to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when
moving frags from source to destination.  __pskb_copy_fclone() defers
the rest of the shinfo metadata to skb_copy_header() after copying
frag descriptors, but that helper only carries over gso_{size,segs,
type} and never touches skb_shinfo()->flags; skb_shift() moves frag
descriptors directly and leaves flags untouched.  As a result, the
destination skb keeps a reference to the same externally-owned or
page-cache-backed pages while reporting skb_has_shared_frag() as
false.

The mismatch is harmful in any in-place writer that uses
skb_has_shared_frag() to decide whether shared pages must be detoured
through skb_cow_data().  ESP input is one such writer (esp4.c,
esp6.c), and a single nft 'dup to <local>' rule -- or any other
nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d
skb in esp_input() with the marker stripped, letting an unprivileged
user write into the page cache of a root-owned read-only file via
authencesn-ESN stray writes.

Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors
were actually moved from the source.  skb_copy() and skb_copy_expand()
share skb_copy_header() too but linearize all paged data into freshly
allocated head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own; they need no change.

The same omission exists in skb_gro_receive() and skb_gro_receive_list().
The former moves the incoming skb's frag descriptors into the
accumulator's last sub-skb via two paths (a direct frag-move loop and
the head_frag + memcpy path); the latter chains the incoming skb whole
onto p's frag_list.  Downstream skb_segment() reads only
skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's
shinfo as the nskb -- both p and lp must carry the marker.

The same omission also exists in tcp_clone_payload(), which builds an
MTU probe skb by moving frag descriptors from skbs on sk_write_queue
into a freshly allocated nskb.  The helper falls into the same family
and warrants the same fix for consistency; no TCP TX-side in-place
writer is currently known to reach a user page through this gap, but
a future consumer depending on the marker would regress silently.

The same omission exists in skb_segment(): the per-iteration flag
merge takes only head_skb's flag, and the inner switch that rebinds
frag_skb to list_skb on head_skb-frags exhaustion does not fold the
new frag_skb's flag into nskb.  Fold frag_skb's flag at both sites
so segments drawing frags from frag_list members carry the marker.

Weakness: CWE-664 (Improper Control of a Resource Through its Lifetime), CWE-691 (Insufficient Control Flow Management)

## Which versions are affected by CVE-2026-43503?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2026-43503?

Apply the vendor's patch.

## Is CVE-2026-43503 being exploited?

It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-43503 exists.

Public exploit code:

- CVE-2026-43503 (github_poc): https://github.com/0xredash/CVE-2026-43503
- Python Proof of Concept for DirtyClone (CVE-2026-43503) - Linux kernel LPE via page-cache corruption (github_poc): https://github.com/entra1337/DirtyClone
- https://github.com/mooder1/dirtyclone-CVE-2026-43503 (github_poc): https://github.com/mooder1/dirtyclone-CVE-2026-43503
- Educational, defensive kit for two Linux page-cache-corruption LPEs (DirtyClone CVE-2026-43503, pedit COW CVE-2026-46331): hardening, detection, verification, seccomp + validation harness. Detection and prevention only — no exploit code. TLP:CLEAR. (github_poc): https://github.com/douglasmun/pagecache-lpe-containment-kit
- DirtyClone - local privilege escalation (LPE) proof-of-concept targeting a kernel/XFRM-related vulnerability described in the source as CVE-2026-43503 (github_poc): https://github.com/gl1tch0x1/DirtyClone
- https://github.com/lieehrdiansyah12/CVE-2026-43503 (github_poc): https://github.com/lieehrdiansyah12/CVE-2026-43503

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-43503 and fix it if it is affected.

What it is: CVE-2026-43503 is a high-severity vulnerability in Linux kernel, published on 23 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-43503 exists.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-43503/ (Markdown: https://insights.sbomify.com/CVE-2026-43503/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-43503
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-43503
- OSV: https://osv.dev/vulnerability/CVE-2026-43503

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-43503/
Summaries are generated and may contain mistakes; the official description above is the record.