Researchers Publish "pedit COW" Linux Disclosure (CVE-2026-46331)

A second Linux research disclosure in the same weekend — distribution patch tracking continues.

WASHINGTON — Security researchers in late June 2026 published a disclosure for a Linux kernel privilege-escalation flaw nicknamed "pedit COW" and tracked as CVE-2026-46331, the second such Linux disclosure to surface in the same weekend. According to the published reporting, the flaw is an out-of-bounds write in the kernel's act_pedit traffic-control action that a local, unprivileged user can use to corrupt shared page-cache memory and gain root on affected systems. A public proof-of-concept appeared within roughly a day of the CVE being assigned on June 16, 2026, and Red Hat has rated the issue as important.

For defenders, the disclosure reads as a patch-tracking exercise rather than a breach: there is no reported in-the-wild abuse, but a working exploit is public and the affected component is the Linux kernel itself. It lands the same weekend as DirtyClone, a separate kernel privilege-escalation flaw, and the two share a page-cache-corruption pattern that can keep on-disk integrity checks looking clean while a root shell is already open.

What the Research Disclosed

According to the published reporting, CVE-2026-46331 is an out-of-bounds write in the Linux kernel's traffic-control subsystem, specifically the packet-editing action known as act_pedit. The kernel's tc tooling can rewrite packet headers in flight using this action; the function that performs the edit is described as making a private copy of the data before modifying it, the standard copy-on-write (COW) pattern that prevents one process from changing memory another relies on. The researchers report that the writable range is checked once, before the final edit offsets are known, and that some edit keys resolve their offset only at runtime.

The consequence, as described, is a partial COW: when a runtime offset pushes the write past the privately copied region, the kernel ends up modifying a shared page-cache page rather than a private copy. If that page belongs to a cached file, the file's in-memory image is corrupted while the on-disk file is untouched. The published proof-of-concept reportedly targets the cached copy of a setuid root binary in memory, so that an unprivileged user can have an altered image run with root privileges. Because the change lives in memory rather than on disk, file-integrity checks can continue to report the binary as legitimate.

The reporting frames pedit COW as the latest in a recognizable family of Linux page-cache-corruption flaws — alongside earlier disclosures such as Dirty Pipe and, this same weekend, DirtyClone — in which a kernel fast path writes into a page it does not exclusively own. What is described as distinctive here is the entry point: an unprivileged user can configure tc actions from inside a user namespace, which is reported to supply the namespace-local CAP_NET_ADMIN capability the technique requires. The exploit chain, as published, depends on the act_pedit module being loadable and on unprivileged user namespaces being available — conditions present by default on some tested distributions.

Defender Posture for Affected Linux Distributions

The practical reading for defenders is straightforward: pedit COW is a local privilege-escalation flaw, so the systems that matter most are those where "local user" does not mean "trusted user." Multi-tenant hosts, continuous-integration runners, container and Kubernetes nodes, build workers, and shared research or lab machines are the environments where an unprivileged foothold is most plausible and where escalation to root is most consequential. That prioritization mirrors how other reachable kernel flaws have been handled across recent Linux disclosures.

The published guidance is to install the patched kernel and reboot once a fixed build is available for the relevant distribution, since the fix is a kernel change rather than a configuration tweak. Where patching is not yet possible, the reporting describes two mitigations that break the exploit chain. The first is to prevent the act_pedit module from loading on systems that do not need tc pedit rules; the second is to disable unprivileged user namespaces, which removes the namespace-local capability the technique relies on. The second mitigation carries operational cost — it can break rootless containers, some CI sandboxes, and sandboxed browsers — so the reporting advises testing before applying it broadly.

Because the corruption targets cached memory rather than the on-disk file, the disclosure is also a reminder of the limits of file-integrity monitoring against this class of flaw. The reporting notes that integrity checks may not detect the in-memory change, and that clearing the page cache removes the poisoned copy but does nothing about a root shell an attacker has already opened. The conservative posture, consistent with incident-response practice, is to treat a system as compromised if exploitation is suspected rather than to rely on an integrity tool's all-clear.

Patch Verification Across Distribution-Specific Releases

Linux kernel disclosures rarely resolve to a single version check, and pedit COW is no exception. The flaw is reported to affect mainline kernels from v5.18 through v7.1-rc6, with the fix landing in v7.1-rc7 and in distribution backports — but most production systems run vendor kernels, so the question that matters for any given fleet is which distribution build is deployed and whether that distribution has shipped a fix. The reporting describes a patch picture that varied by vendor at the time of disclosure.

On the distribution side, the published tracking indicated that Debian 13 (trixie) had been fixed through its security channel while Debian 11 and 12 were still listed as vulnerable; that Ubuntu listed supported releases from 18.04 through 26.04 as vulnerable as of late June, with Ubuntu 26.04 reported to block the demonstrated path by default through AppArmor restrictions on unprivileged user namespaces even though the underlying kernel remained affected; and that Red Hat listed RHEL 8, 9, and 10 as affected, with errata being issued. The precise state of any individual release moves quickly after a disclosure, so defenders should treat these as starting points and confirm current advisories against their own distribution's security tracker.

The verification work, then, is inventory-driven rather than headline-driven. Teams should enumerate the kernels actually running across their estate, map each against the relevant vendor advisory for CVE-2026-46331, and confirm that the reboot into a fixed kernel has actually happened — a running kernel, not just an installed package, is what determines exposure. Where a fixed build is not yet available for a given release, the interim mitigations described above can reduce exposure until the kernel update ships, a pattern familiar from prior cross-distribution kernel disclosures.

Open Questions

Several points are worth keeping in view. The disclosure is, at the brief stage, effectively single-source in its detailed write-up, with the core technical claims drawn from the researchers' publication and the reporting that summarized it; the CVE record and distribution advisories corroborate the existence and severity of the flaw, but the full exploitation details rest on the published research. No in-the-wild exploitation has been reported, yet a working proof-of-concept is public, which historically shortens the window before opportunistic attempts appear against reachable, unprivileged-to-root flaws — a dynamic seen with other kernel privilege-escalation research.

What also remains open is how the distribution patch picture settles for the releases still listed as vulnerable, and whether the same late-June clustering of Linux disclosures — pedit COW arriving beside DirtyClone, and following earlier cross-distribution flaws such as the PackageKit issue tracked as pack2theroot — reflects a sustained research focus on Linux privilege escalation rather than coincidence. For now, the confirmed facts are enough to act on: a public proof-of-concept for a local-to-root kernel flaw, fixes available in mainline and shipping across distributions, and a page-cache-corruption mechanism that argues against trusting on-disk integrity checks alone. The prudent reading is to treat patch verification across every affected Linux release as a near-term, high-priority cycle.

Sources