[SRU][J][PATCH 0/1] CVE-2026-43500

Cengiz Can cengiz.can at canonical.com
Thu May 21 16:52:31 UTC 2026


https://ubuntu.com/security/CVE-2026-43500

[ Impact ]

The DATA-packet handler in net/rxrpc/input.c calls skb_unshare() to
copy the skb to a linear one before in-place decryption, but
skb_unshare() only copies when skb_cloned() is true. An skb that
is not cloned but carries externally-owned paged fragments (pages
deposited by splice() into a UDP socket bound to rxrpc) falls
through to the in-place decryption path. The AEAD/skcipher SGL is
built directly over the externally-owned pages via skb_to_sgvec(),
and the decrypt writes plaintext into the original page cache.

An unprivileged local user can use this primitive to corrupt the
page cache of a read-only file owned by root (e.g. /etc/passwd),
yielding a local privilege escalation. The bug is empirically
reproducible on the released GA jammy kernel image (5.15.0-101 and
later) via the public V4bel exp.c with the --force-rxrpc flag, run
as uid=1000 with no namespaces and no AppArmor evasion.

The rxrpc module auto-loads on socket(AF_RXRPC) from an
unprivileged user, so AppArmor's unprivileged_userns profile does
not mitigate this code path.


[ Fix ]

This submission targets jammy 5.15.

Upstream commit aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71 ("rxrpc:
Also unshare DATA/RESPONSE packets when paged frags are present",
v7.1-rc3) widens the gate to also catch shared paged fragments
before in-place decrypt.

The jammy backport differs from upstream along two axes:

  1. Target file. Upstream patches rxrpc_input_call_event() in
     net/rxrpc/call_event.c and rxrpc_verify_response() in
     net/rxrpc/conn_event.c. Both functions were added by the
     v7.1-rc1 unshare-move refactors 1f2740150f90 ("rxrpc: Fix
     potential UAF after skb_unshare() failure") and 24481a7f5733
     ("rxrpc: Fix conn-level packet handling to unshare RESPONSE
     packets"). Neither refactor is present in jammy 5.15. The
     backport instead applies the fix to the older unconditional
     skb_unshare() call site in net/rxrpc/input.c.

  2. Gate predicate. Upstream uses
     skb_cloned() || skb_has_frag_list() || skb_has_shared_frag().
     SKBFL_SHARED_FRAG is set in __ip_append_data by the companion
     DirtyFrag-ESP fix f4c50a4034e6 ("xfrm: esp: avoid in-place
     decrypt on shared skb frags"), which is not yet backported to
     jammy. Without that flag-setter, splice() into a UDP socket on
     jammy goes through udp_sendpage / ip_append_page and never
     sets the flag, so skb_has_shared_frag() returns false on the
     very skbs the gate needs to catch. The backport substitutes
     skb_is_nonlinear() for the two flag-based checks. It is a
     strict superset that catches the same skbs the upstream gate
     targets and is correct independent of the DirtyFrag-ESP
     backport status.


[ Test Plan ]

Booted linux-image-5.15.0-180-generic with this backport applied.
Ran the public V4bel ./exp --force-rxrpc as an unprivileged user
inside a uvt-kvm jammy VM. Pre-test sha256 of /etc/passwd captured;
post-test sha256 reread without dropping caches; getent passwd
root reread to confirm via NSS.

  pre  sha256(/etc/passwd) = e1dbccbd4c798210ea8902dca26879820d7f43e8b34142a9c5984db04cb3b8e1
  post sha256(/etc/passwd) = e1dbccbd4c798210ea8902dca26879820d7f43e8b34142a9c5984db04cb3b8e1
  getent passwd root pre   = root:x:0:0:root:/root:/bin/bash
  getent passwd root post  = root:x:0:0:root:/root:/bin/bash
  exp.c outcome            = "dirtyfrag: failed (rc=4)"
  exp.c self-check         = "post-trigger sanity check failed -- char layout off"

The exploit aborted because the page-cache write primitive did not
land. The same exploit on the unpatched 5.15.0-101 image produces
a mutated /etc/passwd with an empty root password field (verified
in prior testing).


[ Where Problems Could Occur ]

This change affects only the rxrpc protocol with rxkad encryption
enabled. rxrpc is used almost exclusively by AFS (Andrew File
System) clients; non-AFS workloads do not touch this code path.

For AFS workloads, the change may cause the kernel to allocate a
copy of an incoming packet more often than before in cases where
the packet arrives with paged fragments. In practice these
fragments only appear when the packet comes from a non-NIC source
(splice loopback, certain virtual devices). Ordinary AFS over
Ethernet receives linear skbs and is unaffected.

If a regression were to occur it would most likely manifest as
slightly higher CPU and memory use on AFS clients under heavy
load, not as a functional failure. No data path is changed; the
fix only adds a copy decision before processing.


[ Other Info ]

Colloquially known as the rxrpc half of "Dirty Frag" (the ESP half
is CVE-2026-43284).



More information about the kernel-team mailing list