[Bug 2154172] Re: GRO managed-frag use-after-free leading to local privilege escalation

This bug is awaiting verification that the linux-nvidia/6.8.0-1057.60 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-noble-linux-nvidia' to 'verification-done- noble-linux-nvidia'. If the problem still exists, change the tag 'verification-needed-noble-linux-nvidia' to 'verification-failed-noble- linux-nvidia'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: kernel-spammed-noble-linux-nvidia-v2 verification-needed-noble-linux-nvidia -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2154172 Title: GRO managed-frag use-after-free leading to local privilege escalation Status in linux package in Ubuntu: In Progress Status in linux source package in Noble: Fix Released Status in linux source package in Questing: Fix Released Status in linux source package in Resolute: Fix Released Bug description: [ Impact ] skb_gro_receive() in net/core/gro.c transfers frag descriptors from a source skb into a GRO accumulator without checking the SKBFL_MANAGED_FRAG_REFS flag. A managed-frag skb does not hold a per-frag page reference; the caller owns page lifetime. When such frags are appended to a non-managed accumulator, skb_release_data() later calls put_page() on frags it never get_page()'d, producing a page refcount underflow. The resulting use-after-free is reachable by an unprivileged local user via io_uring SEND_ZC with fixed buffers over a GRO-enabled interface, and yields local privilege escalation. The bug was introduced upstream by commit 753f1ca4e1e5 ("net: introduce managed frags infrastructure"), which first landed in v5.20/v6.0. [ Fix ] commit 4db79a322db8c97f7b73b8a347395ef4d685eb40 ("net: gro: don't merge zcopy skbs") Refuse to merge in skb_gro_receive() when either side has SKBFL_MANAGED_FRAG_REFS or any zerocopy flag set. Landed in net.git for v7.1-rc5. [ Test Plan ] A user-space reproducer is run on a VM with the candidate kernel installed. sha256(/etc/passwd) is captured pre and post. Patched kernel: reproducer self-reports failure, sha256 unchanged. Unpatched kernel: reproducer succeeds, sha256 changes during the run. [ Where Problems Could Occur ] The fix only refuses a merge in a case that was always unsafe. The visible effect is that GRO occasionally produces one more segment-sized skb than otherwise on flows that mix managed and non-managed frags. Tiny throughput change in an uncommon path, no crash or correctness risk. No userspace API change, no kernel ABI change, no module change. [ Other Info ] No CVE ID assigned at the time of filing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2154172/+subscriptions