CVE-2026-46331

Published Jun 16, 2026

Last updated a month ago

CVSS high 7.8

Overview

AI description

Automated description summarized from trusted sources.

CVE-2026-46331, dubbed "pedit COW," is a local privilege escalation vulnerability found within the Linux kernel's traffic-control subsystem, specifically affecting the `act_pedit` packet-editing action. The flaw stems from a "partial Copy-on-Write (COW)" failure where the `tcf_pedit_act()` function incorrectly calculates the writable range. It computes this range before accounting for runtime header offsets introduced by typed keys, leading to an out-of-bounds write that corrupts shared page-cache memory. Exploitation of this vulnerability allows a local unprivileged user to gain root access on affected systems. Attackers can achieve this by poisoning the cached copy of a setuid root binary, such as `/bin/su`, in memory. They inject a malicious payload into this cached image, which then executes with root privileges when the binary is invoked, all while leaving the on-disk file integrity checks undisturbed. Successful exploitation typically requires `act_pedit` to be loadable and unprivileged user namespaces to be enabled, granting the necessary `CAP_NET_ADMIN` capability.

Description
In the Linux kernel, the following vulnerability has been resolved: net/sched: fix pedit partial COW leading to page cache corruption tcf_pedit_act() computes the COW range for skb_ensure_writable() once before the key loop using tcfp_off_max_hint, but the hint does not account for the runtime header offset added by typed keys. This can leave part of the write region un-COW'd. Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic. For negative offsets (e.g. Ethernet header edits at ingress), use skb_cow() to COW the headroom instead. Guard offset_valid() against INT_MIN, where negation is undefined.
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Modified
Products
linux_kernel

Risk scores

CVSS 3.1

Type
Secondary
Base score
7.8
Impact score
5.9
Exploitability score
1.8
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity
HIGH

Weaknesses

134c704f-9b21-4f2e-91b3-4a467353bcc0
CWE-190
0b0ca135-0b70-47e7-9f44-1890c2a1c46c
CWE-787

Social media

Hype score
Not currently trending

  1. Added 3 New LPE to the Toolkit (Open Source) Page Cache Corruption Exploits - Research by Rajat Gupta (Qualcomm): - Dirty Pedit (CVE-2026-46331) - Sub-second root shell, no crypto needed - skb_shift (CVE-2026-43503) - 13 years of kernels affected (3.9-7.1-rc5) - GRO Flag Loss h

    @khadafigans_

    3 Aug 2026

    91 Impressions

    1 Retweet

    3 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. GitHub - sgkdev/packet_edit_meme: PACKET_EDIT_MEME.c (aka CVE-2026-46331): yet another page cache poisoning nightmare · GitHub https://t.co/oieVRX2PIE

    @hereticreader

    26 Jul 2026

    61 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. CVE-2026-46331 in Linux's act_pedit module anchors SharedRoot, a sandbox-escape chain letting code inside a Claude Cowork local VM reach host macOS files. No confirmed in-the-wild exploitation, but a public PoC exists on GitHub as of July 23, 2026. Key details: - CVE-2026-46331

    @DFIR_Radar

    25 Jul 2026

    115 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  4. Done with all page-cache frenzy? Introducing Dirty-Pedit (CVE-2026-46331)! https://t.co/VGpf8gVuyU A true semantic variant with a novel in-place writer from the entire dirty bug class! Two other variants (CVE-2026-43503) that got collided: skb_shift and gro are in the repo.

    @z3ta_rjt

    22 Jul 2026

    191 Impressions

    0 Retweets

    2 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  5. CVE-2026-46331: Critical Linux Privilege Escalation: pedit COW Corrupts Page Cache to Hijack /bin/su in Memory Patch Immediately a reliable local root exploit for CVE-2026-46331 in Linux's actpedit subsystem. Unprivileged users with namespaces enabled can poison cached…

    @lyrie_ai

    18 Jul 2026

    28 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  6. Added 4 new LPE exploits to lpe-toolkit: - PEdit COW CVE-2026-46331 - DirtyClone CVE-2026-43503 - Bad Epoll CVE-2026-46242 - FUSE OOB CVE-2026-31694 https://t.co/BmdCcmBkWK

    @portbuster1337

    6 Jul 2026

    10226 Impressions

    48 Retweets

    211 Likes

    137 Bookmarks

    2 Replies

    1 Quote

  7. Top #CVE to #patch this week 👀 - @Ubiquiti UniFi OS (CVE-2026-34908, 34909, 34910) critical flaws - @Cisco UCM (CVE-2026-20230) SSRF to root - Another two @Linux Privesc pedit COW(CVE-2026-46331), DirtyClone - @Linux kernel — new DirtyFrag family privesc, JFrog published

    @stansecure

    2 Jul 2026

    120 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  8. Tails 7.9.1 is out: https://t.co/1TZmZC8BtT It fixes CVE-2026-43503 (*DirtyClone*) and CVE-2026-46331 (*PACKET_EDIT_MEME*).

    @Tails_live

    1 Jul 2026

    4751 Impressions

    25 Retweets

    93 Likes

    6 Bookmarks

    2 Replies

    1 Quote

  9. Thread — CVE-2026-46331 "pedit COW" 🔴 1. 🧵Imagine leaving your house, locking the door — but someone already swapped your key while you slept. No forced entry. No alarm. That's CVE-2026-46331. - A Linux flaw that gives attackers root access without breaking a single lo

    @Nu11Sector

    29 Jun 2026

    87 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  10. CISO Daily Briefing: Amazon Q Developer CVE-2026-12957 (CVSS 8.5) — MCP auto-execution, no user interaction required, Miasma worm across 73 GitHub repos; Linux LPEs CVE-2026-46331 + CVE-2026-43503 bypass file integrity monitoring entirely in memory. Fable 5/Mythos 5 suspended f

    @cloudsa

    28 Jun 2026

    428 Impressions

    0 Retweets

    0 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  11. Open-source defensive toolkit against #DirtyClone (CVE-2026-43503) and #peditCOW (CVE-2026-46331). While patching remains the ultimate solution, this toolkit helps you close the gap while you patch. https://t.co/2ETRhoK5oU

    @douglasmun

    28 Jun 2026

    234 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  12. 1/3 A new Linux kernel exploit nicknamed pedit COW lets a local unprivileged user gain root. CVE-2026-46331 is an out-of-bounds write in act_pedit that corrupts shared page-cache memory. A working exploit appeared within a day. #CVE #Linux #PrivEsc #cybersecurity

    @CyberTLDR

    27 Jun 2026

    42 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  13. Linux kernel flaw CVE-2026-46331 allows local users to gain root access, Red Hat rates it as severe, can you trust your Linux systems to be secure after June 16? #LinuxSecurity #CVE #RootAccess Source: New Linux pedit COW Exploit Enables Root Access by Poisoning Cached Binaries

    @Soemailsecurity

    27 Jun 2026

    40 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  14. pedit COW (CVE-2026-46331) is a Linux kernel flaw that lets unprivileged users gain root via page cache corruption.Patch now or disable act_pedit. For More: https://t.co/BqDkEZ4lVS #peditCOW #CVE #LinuxKernel #PrivilegeEscalation #RootAccess #CyberSecurity #Linux #InfoSec #RHEL

    @redsecuretech

    27 Jun 2026

    43 Impressions

    1 Retweet

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  15. CVE-2026-46331 CVE-2026-43503 アルマリナックス対応済み

    @hacker_infra

    26 Jun 2026

    206 Impressions

    0 Retweets

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. In the Linux kernel, the following vulnerability has been resolved: NFSv4: include MAY_WRITE in open permission mask for O_TRUNC POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode. nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES. Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced.•CVE-2026-64298
  2. In the Linux kernel, the following vulnerability has been resolved: module: decompress: check return value of module_extend_max_pages() module_extend_max_pages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked. If the initial allocation fails, info->pages remains NULL and info->max_pages remains 0. Subsequent calls to module_get_next_page() will attempt to dynamically grow the array by calling module_extend_max_pages(info, 0) since info->used_pages is 0. This results in kvrealloc(NULL, 0) returning ZERO_SIZE_PTR, which is treated as a success, leading to a dereference of ZERO_SIZE_PTR and a kernel oops. Fix: add the missing error check after module_extend_max_pages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path. [Sami: Corrected the analysis in the commit message.]•CVE-2026-64297
  3. In the Linux kernel, the following vulnerability has been resolved: exfat: bound uniname advance in exfat_find_dir_entry() In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: if (++order == 2) uniname = p_uniname->name; else uniname += EXFAT_FILE_NAME_LEN; len = exfat_extract_uni_name(ep, entry_uniname); name_len += len; unichar = *(uniname+len); *(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba ("exfat: check if filename entries exceeds max filename length")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer.•CVE-2026-64296
  4. In the Linux kernel, the following vulnerability has been resolved: mm: page_ext: add count limit to page_ext_iter_next to prevent invalid PFN access The page_ext iteration API does not validate if the PFN still belongs to a valid section while advancing the iterator. When dynamically adding memory in the hotplug path, it can lead to a NULL pointer dereference during page_ext_lookup at the boundary of the last valid section when iterator count equals __pgcount. The for_each_page_ext() macro calls page_ext_iter_next() as its loop increment. for_each_page_ext() does a "__page_ext = page_ext_iter_next(&__iter)" at the end. This causes page_ext_iter_next() to increment iter->index past __pgcount and call page_ext_lookup(start_pfn + __pgcount). During memory hotplug (online), the PFN at start_pfn + __pgcount may belong to a section that has not yet been initialized, causing page_ext_lookup() to trigger a NULL pointer dereference. [ 14.555124][ T846] Call trace: [ 14.555125][ T846] lookup_page_ext+0x6c/0x108 (P) [ 14.555127][ T846] page_ext_lookup+0x30/0x3c [ 14.555129][ T846] __reset_page_owner+0x11c/0x260 [ 14.571201][ T846] __free_pages_ok+0x5e8/0x8e0 [ 14.571204][ T846] __free_pages_core+0x78/0xf0 [ 14.571206][ T846] generic_online_page+0x14/0x24 [ 14.597782][ T846] online_pages+0x178/0x30c [ 14.597784][ T846] memory_block_change_state+0x284/0x32c [ 14.597787][ T846] memory_subsys_online+0x4c/0x64 [ 14.597789][ T846] device_online+0x88/0xb0 [ 14.597791][ T846] online_memory_block+0x30/0x40 [ 14.597793][ T846] walk_memory_blocks+0xac/0xe8 [ 14.597794][ T846] add_memory_resource+0x280/0x298 [ 14.656161][ T846] add_memory+0x60/0x98 Move the iteration boundary enforcement inside the iterator functions, so callers cannot inadvertently access beyond the requested range.•CVE-2026-64295
  5. In the Linux kernel, the following vulnerability has been resolved: mm: do file ownership checks with the proper mount idmap Ever since idmapped mounts were introduced, inode ownership checks (for side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done against the nop_mnt_idmap, which completely ignores the file's mount's idmap. This results in odd edgecases like: 1) mount/bind-mount with an idmap userA:userB:1 2) userB runs an owner_or_capable() check on file that is owned by userA on-disk/in-memory, but owned by userB after idmap translation 3) owner_or_capable() mysteriously fails as the correct idmap wasn't supplied In the case of mincore/madvise MADV_PAGEOUT, this is usually benign, because file_permission(file, MAY_WRITE) will probably succeed, as it uses the proper idmap internally, but it does not need to be the case on e.g a 0444 file where even the owner itself doesn't have permissions to write to it. Since this is clearly not trivial to get right, introduce a file_owner_or_capable() that can carry the correct semantics, and switch the various users in mm to it. The issue was found by manual code inspection & an off-list discussion with Jan Kara.•CVE-2026-64294

References

Sources include official advisories and independent security research.