kernel: backport "net: gro: don't merge zcopy skbs" (CVE-pending)

[omkhar]

Summary

Backports upstream commit 4db79a322db8 ("net: gro: don't merge zcopy skbs") into the Azure Linux 3.0 kernel-6.6.139.1 package. The fix prevents a UAF in skb_gro_receive() that allows unprivileged LPE via io_uring SEND_ZC + veth GRO.

Why this matters for Azure Linux 3

• Pre-condition (SKBFL_MANAGED_FRAG_REFS, introduced upstream by 753f1ca4e1e5) is present in 6.6 LTS → 6.6.139.1
• io_uring is enabled by default (kernel.io_uring_disabled=0)
• A public PoC achieves root LPE in ~4/5 trials on stock 6.6.139.1-1.azl3 (Azure D2as_v5 VM, F32s_v2 build VM)

Change

• Adds SPECS/kernel/0002-net-gro-don-t-merge-zcopy-skbs.patch — 3-line addition to net/core/gro.c's skb_gro_receive() returning -ETOOMANYREFS when either skb is zero-copy
• Spec uses %autosetup -p1 so the patch auto-applies during %prep
• Release bumped to 2%{?dist}; changelog entry added

Empirical verification (Azure)

Built and booted kernel-6.6.139.1-2.azl3.x86_64 (6.6.139.1-grofix) on an F32s_v2 VM:

	unpatched 6.6.139.1-1.azl3	patched 6.6.139.1-grofix
Public PoC (lcfr-eth/2566a5cef312c94a5ff8d62fa417955f) over 5 trials	4/5 root achieved (hax::0:0::/root:/bin/sh injected into /etc/passwd)	0/5 (UAF prevented; PTE extraction lands on poisoned page each trial — page-poison sentinel 0xdeadbeefdeadbeef observed)
tools/testing/selftests/net/gro.sh	n/a	"All Tests Succeeded"
skb_gro_receive disasm — `skb_zcopy(p)		skb_zcopy(skb)` guard

Test plan

• Patch applies cleanly via %autosetup against kernel-6.6.139.1-1.azl3 SRPM
• Kernel builds without error (make -j12 vmlinux bzImage modules)
• Kernel boots; gro selftest passes
• Public PoC blocked across 5 trials
• CI / pipeline build (CLA-bot + build pipeline will run after PR open)

References

• Upstream fix: 4db79a322db8c97f7b73b8a347395ef4d685eb40
• Introduced by: 753f1ca4e1e5 ("net: introduce managed frags infrastructure")
• Author: Sabrina Dubroca <sd@queasysnail.net>
• Reported by: Huzaifa Sidhpurwala <huzaifas@redhat.com>

🤖 Generated with Claude Code

[omkhar]

@microsoft-github-policy-service agree

[christopherco]

Thanks for the contribution, @omkhar . We're taking a closer look at the backport and will follow up shortly. In the meantime, please retarget the PR to our 3.0-dev branch, which is our primary branch for 3.0 changes. ref link on branch structure

cc: @allenpais

[omkhar]

Retargeted to 3.0-dev — thanks for the pointer to the branch-structure table. Rebased the single backport commit onto current 3.0-dev (clean apply, no spec conflicts). Standing by for the backport review whenever you and @allenpais have cycles.

[amarao]

How exploitable this thing is? It's already 3 days since publication of zero day exploit, and there is no CVE yet...

[omkhar]

CVE requires the kernel team to go through the process of registering and issuing a report.

With the speed exploits are being generated, it seems like the official CVE lags the exploit and fix by a while (see some of the recent exploits like copy_fail).

Unfortunately, the lack of a CVE isn't correlated to exploitability. That's the definition of a 0 day.

[allenpais]

@omkhar, we need to get this via the stable route. for now, we can look to carry it as OOT. We'll work with stable maintainers to get this in.

[omkhar]

Thanks @allenpais — OOT carry until it shows up in 6.6.y stable works for me. Going forward I'll keep the bar high: only ask for OOT when there's a public PoC achieving LPE/RCE on a stock kernel, or active-in-the-wild signal. Anything below that I'll just wait. AUTOPATCHER on 3.0-dev is empirically pulling 6.6.y stable within ~1–3 weeks (139.1 on 05-16, 138.1 on 05-10, 137.1 on 05-01), so the spec churn and eventual revert isn't worth it for the rest.

Fair warning: I've got a handful of other kernel backports open against 3.0-dev today — #17416, #17417, #17422, #17424, #17425, #17426, plus #17421 and #17423 still pointing at main (retargeting). I'll re-triage them against the bar above and close anything without a working public PoC, so you and your team aren't reviewing a wall of low-severity backports. I'll leave a note on each as I go.

On the stable route for this fix: 4db79a322db8 is in Linus's tree but not yet in linux-6.6.y (cgit log against the 6.6.y branch returns nothing for "zcopy" as of today). Happy to defer the submission to your team. If it'd move things along I can send a Cc: stable@vger.kernel.org # 6.6.x backport request referencing the commit and the SEND_ZC + veth repro — just say the word. Once it lands in a 6.6.y release the AUTOPATCHER picks up I'll open a one-commit follow-up dropping the 0002-... patch and reverting the Release bump.

Open question on Mariner 2.0 for the deployed fleet: cgit on linux-5.15.y shows both SKBFL_MANAGED_FRAG_REFS and IORING_OP_SEND_ZC were backported, so the precondition is there — the fleet looks exposed in principle, not protected by version. AUTOPATCHER on Mariner 2.0 has effectively stopped (last bump 5.15.202.1 on 2026-03-30, gap before that was 5 weeks), so the upstream-stable route won't reach those nodes on any reasonable timeline. What's your recommended path for the existing Mariner fleet here? Happy to build the 5.15 PoC and open an OOT backport PR for Mariner 2.0 if you want it covered the same way, or stand down if the fleet's risk posture says don't bother. Let me know.