An exploit for GRO Frag — a local privilege escalation vulnerability in the Linux kernel related to the handling of GRO and zero-copy skb in the networking stack. The exact date of the initial discovery in public materials is not specified. Based on open trails, two dates can be noted: the fix was discussed on the netdev mailing list on May 20, 2026, where this vulnerability was already described as suitable for page cache overwriting, and a public PoC was posted on GitHub Gist on May 22, 2026..
As a temporary measure until the patched kernel is installed, the attack vector can be limited via sysctl: kernel.io_uring_disabled=1. This mode prevents the creation of new io_uring instances by unprivileged processes unless they are included in an allowed io_uring_group; when the group value is -1, access is retained only by processes with CAP_SYS_ADMIN. This is a mitigation, not a full fix for the vulnerability.
The issue lies in the skb_gro_receive() function: when merging GRO packets, the kernel could transfer fragments from a zero-copy skb to another skb without properly checking the zero-copy state and the SKBFL_MANAGED_FRAG_REFS flag. As a result, memory pages that the original skb did not hold separate references to could be incorrectly freed, leading to use-after-free. The patch explicitly states that such a situation could lead to UAF, and that the discovered variant was suitable for page cache overwrite.
The published PoC describes the vulnerability as LPE via GRO managed-frag UAF using io_uring SEND_ZC and virtual network interface veth. The code comments indicate that affected kernels are Linux 6.0+, exploitation is possible by an unprivileged user, but requires accessible io_uring; the patch mentioned is the commit 4db79a322db8 with the change "net: gro: don’t merge zcopy skbs."
In terms of consequences, GRO Frag falls into the same dangerous class of errors as Copy Fail and Dirty Frag: an attacker with local unprivileged access can achieve data modification in the page cache, meaning in memory, without necessarily modifying the file on disk. Such errors are particularly troublesome as they affect the boundary between the 'read-only' status of a file and the actual content seen by the kernel and processes during subsequent accesses. Elastic previously described this class as a practical way to gain root access through page-cache corruption.
At the time of publication, a separate CVE identifier for GRO Frag had not yet been assigned, based on available reports. As a temporary measure, administrators should focus on updating the kernel to the version with the fix, as well as applying general risk mitigation measures for such LPEs: limiting unprivileged user namespaces where applicable, monitoring the use of io_uring, and keeping an eye on suspicious chains related to local privilege escalation. For related Copy Fail/DirtyFrag attacks, Elastic also recommends combining patching with detection of low-level exploitation primitives.
Low-level exploitation primitives are not the 'ready-made hack' itself, but the basic technical techniques from which the exploit is constructed.
In the context of GRO Frag, this may mean not detecting the already completed fact of 'the user became root', but rather attempting to notice specific suspicious actions that the exploit uses on its way to privilege escalation.
Source: linux.org.ru
