[Devel] [PATCH vz10 0/4] CVE-2026-43500: backport rxrpc "Dirty Frag" fix

[Pavel Tikhomirov]

Reviewed-by: Pavel Tikhomirov <ptikhomirov at virtuozzo.com>

On 6/17/26 22:49, Konstantin Khorenko wrote:
> This series backports the upstream fix for CVE-2026-43500 ("Dirty Frag")
> into the vz10 kernel (rh10-6.12.0-211.16.1.x.vz10).
> 
> What the bug is
> ---------------
> rxrpc decrypts secured DATA/RESPONSE packets in place. An sk_buff that is
> not cloned but still carries externally-owned paged fragments - e.g.
> SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data(),
> or a chained skb_has_frag_list() - falls through to the in-place decryption
> path, which binds the frag pages directly into the AEAD/skcipher SGL via
> skb_to_sgvec(). A low-privileged local attacker can use the splice-loopback
> vector to make rxrpc decrypt over pages it does not privately own,
> corrupting page-cache contents - a building block for local privilege
> escalation.
> 
> Why we have to carry it, while Red Hat marks the kernel "Not affected"
> ----------------------------------------------------------------------
> Red Hat rates RHEL 10 kernel as "Not affected" for CVE-2026-43500. Their
> rationale is packaging, not code: the vulnerable rxrpc code is present in
> the source, but "the binary RPMs that provide this module are not shipped
> or supported by Red Hat", and the module is not installed by default. RHEL
> keeps rxrpc out of the supported, shipped module set.
> 
> That reasoning does not carry over to us:
> 
>   - vz10 builds CONFIG_AF_RXRPC=m (and CONFIG_RXKAD=y), same as RHEL, so the
>     vulnerable code is compiled.
>   - In our packaging (def_variants.yaml.rhel, inherited verbatim from RHEL)
>     net/rxrpc/* maps to "modules-partner", and kernel-modules-partner is a
>     real, shippable sub-package - not the unshipped kernel-modules-internal
>     that RHEL's "Not affected" relies on.
>   - There is no mod-denylist entry blocking rxrpc, and
>     MODULE_ALIAS_NETPROTO(PF_RXRPC) means an unprivileged socket(AF_RXRPC,
>     ...) auto-loads af_rxrpc.ko if it is present on disk.
> 
> So wherever kernel-modules-partner is installed, the CVE is locally
> reachable. Hence we fix the code rather than rely on a "we don't ship it"
> verdict. AF_RXRPC sockets are not netns/VE-isolated, so the vector is also
> reachable from inside a container.
> 
> Why exactly 4 patches
> ---------------------
> The actual fix for CVE-2026-43500 is patch 4 (aa54b1d27fe0), with patch 2
> (24481a7f5733) providing the RESPONSE-side helper it extends. But both
> depend on infrastructure vz10 did not have, so two more upstream commits
> are required to land them cleanly and correctly:
> 
>   1. ms/rxrpc: Fix potential UAF after skb_unshare() failure (1f2740150f90)
>      Prerequisite. vz10 lacked this commit (verified: its trace enums
>      rxrpc_skb_put_response_copy / rxrpc_skb_see_unshare_nomem were absent).
>      It also moves the in-place-decryption unshare from io_thread.c into
>      rxrpc_input_call_event(), which is the location patches 3 and 4 build
>      on. Without it the helper in patch 2 fails to build.
> 
>   2. ms/rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
>      (24481a7f5733) - adds rxrpc_verify_response(); patch 4 extends its
>      gate.
> 
>   3. ms/rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets
>      (55b2984c96c3) - follow-up that Fixes: patch 1; restores the
>      DATA-packet-only condition on the unshare gate (so ACK/ABORT packets
>      are not needlessly copied).
> 
>   4. ms/rxrpc: Also unshare DATA/RESPONSE packets when paged frags are
>      present (aa54b1d27fe0) - the CVE-2026-43500 fix proper: extends the
>      gate from skb_cloned() to also cover skb_has_frag_list() /
>      skb_has_shared_frag(), catching the splice-loopback vector.
> 
> The patches are ordered exactly as in mainline. Only patch 2 needed a
> manual conflict resolution (mainline has an unrelated early
> spin_lock_irq(&conn->state_lock) state-check before the verify call that
> vz10 does not have; we kept the vz10 structure and applied only this
> patch's change). Patches 1, 3 and 4 applied cleanly.
> 
> What is deliberately NOT included
> ---------------------------------
> Upstream later reworked the decrypt path to extract packet data into a
> bounce buffer instead of copying the skb (8bfab4b6ffc2, d2bc90cf6c75,
> 16c8ae9735c5, all "improves the fix for CVE-2026-43500"). Those are
> performance/robustness improvements, not required to close the hole - the
> copy-based fix in this series is exactly what mainline shipped first and
> what the stable trees backported. They also conflict heavily in the
> rxkad/rxgk crypto classes and would pull in further dependencies, so they
> are left out of this CVE backport and can be done separately if we decide
> to track mainline for the rxrpc decrypt path.
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-131094
> 
> David Howells (3):
>   ms/rxrpc: Fix potential UAF after skb_unshare() failure
>   ms/rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
>   ms/rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets
> 
> Hyunwoo Kim (1):
>   ms/rxrpc: Also unshare DATA/RESPONSE packets when paged frags are
>     present
> 
>  include/trace/events/rxrpc.h |  4 ++--
>  net/rxrpc/ar-internal.h      |  1 -
>  net/rxrpc/call_event.c       | 22 +++++++++++++++++++++-
>  net/rxrpc/conn_event.c       | 30 +++++++++++++++++++++++++++++-
>  net/rxrpc/io_thread.c        | 24 ++----------------------
>  net/rxrpc/skbuff.c           |  9 ---------
>  6 files changed, 54 insertions(+), 36 deletions(-)
> 
> --
> 2.43.0
> 

-- 
Best regards, Pavel Tikhomirov
Senior Software Developer, Virtuozzo.