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

[Konstantin Khorenko]

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