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

[Bethany Jamison]

On 5/21/26 11:52 AM, Cengiz Can wrote:
> 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).
>
Acked-by: Bethany Jamison <bethany.jamison at canonical.com>