Add Dirty Frag + ptrace fixes (CVE-2026-43500, 46300, 46333)

Bring back three local patches that were dropped from a9 after
upstream landed the related fixes. The xfrm-esp fix (CVE-2026-43284)
came in via the CKI Backport Bot at 5.14.0-611.55.1, but rxrpc,
net/skbuff and ptrace did not -- restore them here. Blobs are
imported verbatim from the latest a9 commits that carried them
(2530dd40b / d62b1833b / cbd86e459 / cc48c27cd):

  1101-rxrpc-linearize-paged-frags.patch (CVE-2026-43500)
  1102-net-skbuff-propagate-shared-frag-marker.patch
    v3 frag-transfer helpers variant (CVE-2026-46300 "Fragnesia")
  1103-ptrace-require-cap-on-mm-less-task.patch
    CVE-2026-46333, kABI-safe replacement for upstream 31e62c2ebbfd

Release is not bumped; a second changelog entry is added under the
existing 5.14.0-611.55.1 version. All three verified to apply with
`patch -p1 -F0` against the 5.14.0-611.55.1.el9_7 source tree
(one minor offset, no fuzz, no rejects).
This commit is contained in:
Andrew Lukoshko 2026-05-19 18:15:47 +00:00
parent ba99d2d4ea
commit 01f79da1ca
4 changed files with 258 additions and 0 deletions

View File

@ -0,0 +1,68 @@
From: Andrew Lukoshko <alukoshko@almalinux.org>
Subject: [PATCH AlmaLinux 9] 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/
(sibling to upstream commit f4c50a4034e6 in the ESP/xfrm subsystem).
The upstream patch can not be cherry-picked against this 5.14 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 9 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-5.14.0-611.54.1.el9_7.
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
@@ -225,16 +225,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

View File

@ -0,0 +1,122 @@
From: Eduard Abdullin <eabdullin@almalinux.org>
Subject: [PATCH AlmaLinux 9] net: skbuff: propagate shared-frag marker through frag-transfer helpers
Backport of upstream v3 patch posted at
https://lore.kernel.org/all/agW4vC0r8QOUKtRT@v4bel/
(sibling to upstream commit f4c50a4034e6 "xfrm: esp: avoid in-place
decrypt on shared skb frags").
Three frag-transfer helpers in net/core/skbuff.c
(__pskb_copy_fclone(), skb_try_coalesce(), skb_shift()) and the
GRO accumulator path in net/core/gro.c (skb_gro_receive()) and the
UDP GRO list helper in net/ipv4/udp_offload.c
(skb_gro_receive_list(), kept as a static helper on AlmaLinux 9)
fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags
when moving frag descriptors from source to destination. As a
result, the destination skb keeps a reference to the same
externally-owned or page-cache-backed pages while reporting
skb_has_shared_frag() as false.
The mismatch is harmful in any in-place writer that uses
skb_has_shared_frag() to decide whether shared pages must be detoured
through skb_cow_data(). ESP input is one such writer (esp4.c,
esp6.c). Combined with an nft 'dup to <local>' rule, an
nf_dup_ipv4() / xt_TEE caller, or ESP-over-UDP with UDP GRO, this
lets an unprivileged user write into the page cache of a root-owned
read-only file via authencesn-ESN stray writes (CVE-2026-46300,
"Fragnesia").
Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors
were actually moved from the source. skb_copy() and skb_copy_expand()
share skb_copy_header() too but linearize all paged data into freshly
allocated head storage and emerge with nr_frags == 0, so
skb_has_shared_frag() returns false on its own; they need no change.
The same omission exists in skb_gro_receive() and
skb_gro_receive_list(). The former moves the incoming skb's frag
descriptors into the accumulator's last sub-skb via two paths plus a
"merge:" fallback that chains the whole skb onto frag_list; the
latter chains the incoming skb whole onto p's frag_list. Downstream
skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list()
reuses each sub-skb's shinfo as the nskb -- both p and lp must carry
the marker.
Tree adaptation:
* Upstream v3 places skb_gro_receive_list() in net/core/gro.c.
AlmaLinux 9 still keeps it as a static helper in
net/ipv4/udp_offload.c (it has not been promoted to a global
GRO helper in this tree). Apply the propagation hunk there
instead.
* Upstream skb_shift() uses skb_len_add() helpers (introduced in
v5.16); AlmaLinux 9 still has the open-coded
`skb->len -= shiftlen; ...` block. The insertion point (right
after both ip_summed assignments) is the same.
Fixes: cef401de7be8 ("net: fix possible wrong checksum generation")
Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb frags")
Reported-by: Sultan Alsawaf <sultan@kerneltoast.com>
Reported-by: William Bowling <vakzz@zellic.io>
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: Eduard Abdullin <eabdullin@almalinux.org>
---
net/core/gro.c | 2 ++
net/core/skbuff.c | 6 ++++++
net/ipv4/udp_offload.c | 2 ++
3 files changed, 10 insertions(+)
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@ -222,10 +222,12 @@ int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb)
p->data_len += len;
p->truesize += delta_truesize;
p->len += len;
+ skb_shinfo(p)->flags |= skbinfo->flags & SKBFL_SHARED_FRAG;
if (lp != p) {
lp->data_len += len;
lp->truesize += delta_truesize;
lp->len += len;
+ skb_shinfo(lp)->flags |= skbinfo->flags & SKBFL_SHARED_FRAG;
}
NAPI_GRO_CB(skb)->same_flow = 1;
return 0;
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2026,6 +2026,7 @@ struct sk_buff *__pskb_copy_fclone(struct sk_buff *skb, int headroom,
skb_frag_ref(skb, i);
}
skb_shinfo(n)->nr_frags = i;
+ skb_shinfo(n)->flags |= skb_shinfo(skb)->flags & SKBFL_SHARED_FRAG;
}
if (skb_has_frag_list(skb)) {
@@ -4029,6 +4030,8 @@ int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen)
tgt->ip_summed = CHECKSUM_PARTIAL;
skb->ip_summed = CHECKSUM_PARTIAL;
+ skb_shinfo(tgt)->flags |= skb_shinfo(skb)->flags & SKBFL_SHARED_FRAG;
+
/* Yak, is it really working this way? Some helper please? */
skb->len -= shiftlen;
skb->data_len -= shiftlen;
@@ -5740,6 +5743,8 @@ bool skb_try_coalesce(struct sk_buff *to, struct sk_buff *from,
from_shinfo->frags,
from_shinfo->nr_frags * sizeof(skb_frag_t));
to_shinfo->nr_frags += from_shinfo->nr_frags;
+ if (from_shinfo->nr_frags)
+ to_shinfo->flags |= from_shinfo->flags & SKBFL_SHARED_FRAG;
if (!skb_cloned(from))
from_shinfo->nr_frags = 0;
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -487,6 +487,8 @@ static int skb_gro_receive_list(struct sk_buff *p, struct sk_buff *skb)
p->truesize += skb->truesize;
p->len += skb->len;
+ skb_shinfo(p)->flags |= skb_shinfo(skb)->flags & SKBFL_SHARED_FRAG;
+
NAPI_GRO_CB(skb)->same_flow = 1;
return 0;
--
2.43.0

View File

@ -0,0 +1,55 @@
From: Andrew Lukoshko <alukoshko@almalinux.org>
Subject: [PATCH AlmaLinux 9] ptrace: require CAP_SYS_PTRACE when task has no mm
kABI-safe AlmaLinux backport of upstream commit 31e62c2ebbfd
("ptrace: slightly saner 'get_dumpable()' logic") posted at
https://github.com/torvalds/linux/commit/31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a
The upstream fix adds a 'user_dumpable:1' bit to task_struct and
caches the last dumpability in exit_mm() so __ptrace_may_access()
can require CAP_SYS_PTRACE when the target has no mm (e.g. kernel
threads or already-exited user tasks). That layout change to
task_struct breaks kABI on RHEL/AlmaLinux 9 (the symtype
signature of struct task_struct is referenced by stablelist exports
such as set_cpus_allowed_ptr() and wake_up_process()), so we cannot
import the field/exit_mm hunks as-is.
Take the minimal kABI-safe slice instead: when task->mm == NULL,
require CAP_SYS_PTRACE in init_user_ns unconditionally. This closes
the Qualys Security Advisory hole -- mm-less targets no longer pass
the dumpability check by default -- without touching task_struct or
exit.c. The only behavioural delta versus upstream is that a user
task that has already cleared its mm in exit_mm() (a dying/zombie
task) now also requires CAP_SYS_PTRACE to attach, instead of being
remembered as previously dumpable. Such targets are rarely ptraced
in practice.
Verified to apply with `patch -p1 -F0` (no offset, no fuzz, no rejects)
against kernel-5.14.0-611.54.1.el9_7.
Reported-by: Qualys Security Advisory <qsa@qualys.com>
Signed-off-by: Andrew Lukoshko <alukoshko@almalinux.org>
---
kernel/ptrace.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -349,8 +349,11 @@ static int __ptrace_may_access(struct task_struct *task, unsigned int mode)
smp_rmb();
mm = task->mm;
- if (mm &&
- ((get_dumpable(mm) != SUID_DUMP_USER) &&
- !ptrace_has_cap(mm->user_ns, mode)))
- return -EPERM;
+ if (mm) {
+ if ((get_dumpable(mm) != SUID_DUMP_USER) &&
+ !ptrace_has_cap(mm->user_ns, mode))
+ return -EPERM;
+ } else if (!ptrace_has_cap(&init_user_ns, mode)) {
+ return -EPERM;
+ }
return security_ptrace_access_check(task, mode);
--
2.43.0

View File

@ -956,6 +956,9 @@ Patch2004: 0004-Bring-back-deprecated-pci-ids-to-qla2xxx-driver.patch
Patch2005: 0005-Bring-back-deprecated-pci-ids-to-lpfc-driver.patch
Patch2006: 0006-Bring-back-deprecated-pci-ids-to-qla4xxx-driver.patch
Patch2007: 0007-Bring-back-deprecated-pci-ids-to-be2iscsi-driver.patch
Patch1101: 1101-rxrpc-linearize-paged-frags.patch
Patch1102: 1102-net-skbuff-propagate-shared-frag-marker.patch
Patch1103: 1103-ptrace-require-cap-on-mm-less-task.patch
Patch11111: ppc64le-kvm-support.patch
@ -1700,6 +1703,9 @@ ApplyPatch 0004-Bring-back-deprecated-pci-ids-to-qla2xxx-driver.patch
ApplyPatch 0005-Bring-back-deprecated-pci-ids-to-lpfc-driver.patch
ApplyPatch 0006-Bring-back-deprecated-pci-ids-to-qla4xxx-driver.patch
ApplyPatch 0007-Bring-back-deprecated-pci-ids-to-be2iscsi-driver.patch
ApplyPatch 1101-rxrpc-linearize-paged-frags.patch
ApplyPatch 1102-net-skbuff-propagate-shared-frag-marker.patch
ApplyPatch 1103-ptrace-require-cap-on-mm-less-task.patch
# END OF PATCH APPLICATIONS
@ -3771,6 +3777,13 @@ fi
#
#
%changelog
* Tue May 19 2026 Andrew Lukoshko <alukoshko@almalinux.org> - 5.14.0-611.55.1
- rxrpc: linearize incoming DATA packet when it has paged frags (CVE-2026-43500)
- net: skbuff: propagate shared-frag marker through frag-transfer helpers
(CVE-2026-46300 "Fragnesia")
- ptrace: require CAP_SYS_PTRACE on mm-less tasks (CVE-2026-46333, kABI-safe
replacement for upstream 31e62c2ebbfd, Qualys Security Advisory)
* Mon May 18 2026 Andrew Lukoshko <alukoshko@almalinux.org> - 5.14.0-611.55.1
- hpsa: bring back deprecated PCI ids #CFHack #CFHack2024
- mptsas: bring back deprecated PCI ids #CFHack #CFHack2024