CVE-2026-46331

What it actually does

This is a Linux kernel memory-corruption flaw in the traffic control packet edit action, `pedit`, under `net/sched`. The vulnerable code calculates the socket-buffer copy-on-write range before it knows the final per-key packet-header offset. When typed `pedit` keys add a runtime header offset, part of the packet data that will be modified may not be made private/writable first. As a result, packet-edit operations can modify shared backing memory and corrupt page-cache-backed data. The fix moves writability checks into the per-key loop, uses `skb_cow()` for negative offsets such as ingress Ethernet-header edits, and adds integer-overflow/`INT_MIN` handling for offset arithmetic. Practical impact depends heavily on whether an attacker can configure traffic-control rules; that normally requires `CAP_NET_ADMIN` or equivalent administrative control over a network namespace.

Why it matters to the business

Successful exploitation can cause kernel instability, data corruption, service disruption, and potentially broader host compromise depending on kernel configuration and attacker privileges. The most exposed systems are Linux hosts that allow less-trusted users, containers, or automation to create traffic-control rules with `pedit`, especially where unprivileged user namespaces or delegated network administration are enabled. Current public signals indicate low EPSS probability, no known CISA KEV listing, no ransomware association, and no known exploit maturity, so this should be prioritized as a kernel hardening and integrity issue rather than an active mass-exploitation emergency.

How an attack unfolds

An attacker first needs a way to configure Linux traffic-control actions, typically through `tc`/netlink with `CAP_NET_ADMIN` in the relevant network namespace. They create a qdisc, filter, or action chain that uses `pedit` with typed keys and offsets that cause the runtime write position to extend beyond the precomputed copy-on-write range. When matching packets traverse the affected ingress or egress path, the kernel attempts to edit packet bytes using the incorrectly prepared socket buffer. Because not all bytes in the edited region were privately copied, the write can affect shared memory and corrupt page-cache-backed data. Exploitation is not expected to be a simple unauthenticated remote attack by itself; it is more plausible as a local/container-adjacent abuse path where network-administration capabilities are available, or as a reliability/data-integrity attack by someone who can install malicious traffic-control policy.

How to fix it

Upgrade to a kernel version that includes the upstream `net/sched: fix pedit partial COW leading to page cache corruption` patch. Because no exact product fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory and confirm the changelog includes this `net/sched`/`pedit` fix. Where immediate patching is not possible, reduce exposure by restricting `CAP_NET_ADMIN`, disabling untrusted creation of network namespaces where feasible, preventing untrusted containers from receiving network-administration capabilities, and auditing/removing unnecessary `tc pedit` rules. Avoid delegating traffic-control management to less-trusted users or workloads until patched.

How to confirm the fix worked

Confirm the running kernel has been updated, not just that the package is installed, by checking the active kernel version after reboot and comparing it against the vendor advisory. Review kernel package changelogs or source patches for the specific `net/sched` `pedit` copy-on-write fix. Validate exposure by enumerating traffic-control configuration with commands such as `tc filter show dev <iface> ingress`, `tc filter show dev <iface> egress`, `tc -s action ls action pedit`, and equivalent namespace-specific checks. Confirm that untrusted containers or users do not have `CAP_NET_ADMIN` and cannot create `pedit` actions. If mitigation relies on policy controls, test that attempts to add `tc ... action pedit ...` fail for non-administrative principals.

Typical attack path

1. Obtain `CAP_NET_ADMIN` or equivalent ability to create traffic-control filters/actions in a host or network namespace.
2. Install a traffic-control qdisc/filter/action that invokes `pedit` on selected traffic.
3. Use typed `pedit` keys and crafted offsets, including header-relative or negative-offset cases, to trigger a mismatch between the precomputed writable range and the actual write offset.
4. Send or route packets through the affected ingress or egress path so the vulnerable `pedit` action executes.
5. Cause shared socket-buffer/page-cache-backed memory to be modified unexpectedly, resulting in data corruption, kernel faults, or possible follow-on exploitation depending on memory layout and system conditions.

How to detect it

To determine whether this was already abused, focus on evidence of unauthorized traffic-control changes and resulting kernel/data-integrity anomalies. Review auditd, EDR, process-execution, shell-history, sudo, and systemd journal logs for `tc` commands that create or modify `pedit` actions. If netlink auditing is available, review traffic-control `RTM_NEWTFILTER`, `RTM_NEWACTION`, `RTM_DELTFILTER`, and `RTM_DELACTION` events around suspicious times. Enumerate current and historical qdisc/filter/action configuration where possible, including inside network namespaces and containers. Correlate any `pedit` rule creation with kernel logs showing oopses, BUG/WARN splats, filesystem errors, page-cache corruption symptoms, service crashes, or unexplained data corruption. There are no public actor-specific indicators for this issue, and exploitation artifacts are likely to look like legitimate traffic-control administration unless the commands, users, namespaces, timing, or offsets are abnormal.

• action pedit
• pedit munge
• tc filter add
• tc filter replace
• tc actions add action pedit
• tc actions replace action pedit
• RTM_NEWTFILTER
• RTM_NEWACTION
• act_pedit
• sch_ingress
• skb_ensure_writable
• skb_cow
• page cache corruption
• kernel: BUG
• kernel: WARNING
• kernel: Oops

What your security team should do

• Patch affected Linux kernels through vendor-supported updates and reboot into the fixed kernel.
• Prioritize systems where containers, multi-tenant workloads, CI jobs, or delegated operators may have `CAP_NET_ADMIN` or access to traffic-control configuration.
• Inventory existing `tc pedit` usage across hosts and network namespaces; remove rules that are unnecessary or not clearly owned.
• Restrict `CAP_NET_ADMIN` and avoid granting privileged networking capabilities to untrusted containers or service accounts.
• Monitor for new or unusual `tc` invocations and netlink traffic-control changes, especially creation of `pedit` actions.
• Review kernel logs for unexplained page-cache corruption, filesystem inconsistencies, kernel oopses, or crashes after traffic-control changes.
• Track distribution advisories because exact fixed package versions vary by kernel branch and vendor backport policy.