Reviewed-by: Pavel Tikhomirov <[email protected]> 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. _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
