kernel/1101-rxrpc-linearize-paged-frags.patch
Andrew Lukoshko b3bdb38281 Reapply Dirty Frag fixes (CVE-2026-43284, CVE-2026-43500) and add pskb_copy marker propagation
Restore the two Dirty Frag patches that were introduced on this branch
in 6.12.0-226 (commit 2a779fc66) and dropped during the import of
6.12.0-227.el10:

  1100-xfrm-esp-avoid-in-place-decrypt-shared-skb-frags.patch
  1101-rxrpc-linearize-paged-frags.patch

Add the sibling supplement already shipped on the a10 branch as its
local Patch1100, renumbered to 1102 here so it sits next to the other
two:

  1102-net-skbuff-propagate-shared-frag-marker.patch

Release is not bumped; new entry is added under the existing
6.12.0-227 version, matching the pattern used by the original 226
commit.
2026-05-13 17:01:53 +00:00

70 lines
2.6 KiB
Diff

From: Andrew Lukoshko <alukoshko@almalinux.org>
Subject: [PATCH AlmaLinux 10] rxrpc: linearize incoming DATA packet when it has paged frags
AlmaLinux-specific backport of the intent of the upstream rxrpc fix
posted at https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/ for the
"Dirty Frag" class of bugs (sibling to upstream commit f4c50a4034e6 in
the ESP/xfrm subsystem).
The upstream patch can not be cherry-picked against this 6.12 tree:
its target lines were introduced by upstream commit d0d5c0cd1e71
("rxrpc: Use skb_unshare() rather than skb_cow_data()") which is not
present here. The age-equivalent code path on AlmaLinux 10 is the
centralized skb_unshare() in net/rxrpc/io_thread.c that is run for
every DATA packet with a non-zero securityIndex before in-place
decryption.
skb_unshare() only handles cloned skbs. An skb that is non-cloned but
carries paged fragments (skb->data_len != 0) — e.g. pages attached via
udp_sendpage() / splice() / MSG_SPLICE_PAGES on a UDP socket carrying
rxrpc traffic — slips through and is decrypted in place over data the
skb does not own privately. With kernel-modules-partner installed
(rxrpc.ko enabled), this is exploitable.
Replace the unconditional skb_unshare() with skb_copy() whenever the
skb is cloned OR carries paged fragments. skb_copy() always returns a
freshly allocated linear skb, so subsequent in-place decryption only
touches kernel-owned memory. The original skb is consumed explicitly
(skb_unshare did this internally via consume_skb()).
Verified to apply with `patch -p1 -F0` (no offset, no fuzz, no
rejects) against kernel-6.12.0-124.55.1.el10_1.
Fixes: cac2661c53f3 ("rxrpc: Use skb_cow_data() in rxrpc_recvmsg_data()")
Signed-off-by: Andrew Lukoshko <alukoshko@almalinux.org>
---
net/rxrpc/io_thread.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
--- a/net/rxrpc/io_thread.c
+++ b/net/rxrpc/io_thread.c
@@ -235,16 +235,18 @@
* decryption.
*/
if (sp->hdr.securityIndex != 0) {
- skb = skb_unshare(skb, GFP_ATOMIC);
- if (!skb) {
- rxrpc_eaten_skb(*_skb, rxrpc_skb_eaten_by_unshare_nomem);
- *_skb = NULL;
- return just_discard;
- }
+ if (skb_cloned(skb) || skb->data_len) {
+ struct sk_buff *nskb = skb_copy(skb, GFP_ATOMIC);
+
+ if (!nskb) {
+ rxrpc_eaten_skb(*_skb, rxrpc_skb_eaten_by_unshare_nomem);
+ return just_discard;
+ }
- if (skb != *_skb) {
rxrpc_eaten_skb(*_skb, rxrpc_skb_eaten_by_unshare);
- *_skb = skb;
+ consume_skb(*_skb);
+ *_skb = nskb;
+ skb = nskb;
rxrpc_new_skb(skb, rxrpc_skb_new_unshared);
sp = rxrpc_skb(skb);
}
--
2.43.0