CVE-2026-53014

What it actually does

This is a Linux kernel networking flaw in the traffic-control mirred action used for redirecting or mirroring packets across devices in a block. During blockcast redirection, the kernel checks the MAC-header transmit behavior of the wrong network device for intermediate destinations. If a traffic-control block contains mixed device types, such as Ethernet/veth devices and tunnel devices, the kernel can push or pull the packet MAC header incorrectly, corrupt the socket buffer header state, exhaust packet headroom, and trigger a kernel panic. The practical impact is local or network-namespace-scoped denial of service when an attacker or misconfigured workload can create the required traffic-control configuration and send matching packets.

Why it matters to the business

Successful exploitation can crash an affected Linux host, interrupting workloads, containers, virtual networking, and dependent services running on that system. The risk is highest for environments that allow tenants, containers, CI jobs, or local users to obtain CAP_NET_ADMIN or create network namespaces with traffic-control rules. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, kernel panics can still create material availability impact on shared infrastructure.

How an attack unfolds

An attacker first needs the ability to configure Linux networking primitives, typically through CAP_NET_ADMIN on the host or inside a sufficiently privileged network namespace. They create or use multiple network devices with different MAC-header transmit expectations, such as a veth interface and a tunnel interface. They then configure Linux traffic control with a mirred redirect or mirror action that redirects packets to a shared block containing those mixed devices. When traffic matches the configured filter, the vulnerable kernel iterates through the block and, for intermediate devices, evaluates the MAC-header behavior of the next device rather than the device actually receiving the packet. This causes incorrect socket-buffer header adjustment. Under the wrong packet/device combination, the kernel corrupts skb header state or exhausts headroom during checksum-aware header push operations, resulting in a kernel panic and denial of service.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the upstream fix for the act_mirred tcf_blockcast_redir device-selection bug. No fixed package versions were provided in the input, so use the exact fixed kernel builds published by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Where immediate patching is not possible, reduce exposure by restricting CAP_NET_ADMIN, disabling unprivileged user namespaces where operationally feasible, avoiding privileged containers, limiting container access to host networking, and preventing untrusted users or workloads from creating traffic-control mirred rules, tunnel interfaces, or mixed-device tc blocks. Mitigations should be treated as temporary because the durable fix is a patched kernel.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version, not just the installed package version, after rebooting into the patched kernel. Validate against vendor advisories or source packages that include the fix changing the mac_header_xmit query in tcf_blockcast_redir to use the device being transmitted to. Review whether untrusted users, containers, or automation have CAP_NET_ADMIN or can create network namespaces and tc rules. On representative systems, inspect traffic-control configuration with tools such as `tc qdisc show`, `tc filter show`, and `tc action show` to identify mirred redirect or mirror actions using shared blocks and mixed device types. If safe and appropriate in a lab only, reproduce the vulnerable configuration before and after patching to confirm the patched kernel no longer panics under matching traffic.

Typical attack path

1. Gain local access or code execution in a context that can configure Linux networking, such as CAP_NET_ADMIN or a privileged container/network namespace.
2. Create or identify a traffic-control block containing multiple destination devices with mixed device behavior, for example Ethernet/veth and tunnel-style interfaces.
3. Install tc qdisc/filter rules using the act_mirred redirect or mirror action to send matching traffic through the affected blockcast redirection path.
4. Generate packets that match the traffic-control filter and traverse the mixed-device redirection path.
5. Trigger incorrect MAC-header push/pull handling for an intermediate destination device.
6. Cause skb header corruption or headroom exhaustion, leading to a kernel panic and host-level denial of service.

How to detect it

To determine whether this was already exploited, review kernel logs, system journals, crash dumps, and uptime/reboot records for unexplained kernel panics after traffic-control or virtual-network changes. Relevant sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `dmesg`, kdump/vmcore analysis, container runtime audit logs, Linux auditd records for network administration activity, shell history for `tc` commands, and orchestration logs that create veth, tunnel, or traffic-control configurations. Look for panic stack traces containing act_mirred, tcf_blockcast_redir, tcf_mirred_to_dev, skb_push_rcsum, skb_push, skb_pull, or packet headroom errors. Also investigate recent creation of tc filters/actions using mirred redirect/mirror with shared blocks and mixed destination devices. Because exploitation primarily manifests as a crash rather than persistent compromise, absence of file-based artifacts does not rule out attempted triggering.

• act_mirred
• tcf_blockcast_redir
• tcf_mirred_to_dev
• skb_push_rcsum
• skb_push
• skb_pull
• kernel panic
• BUG: kernel NULL pointer dereference
• not enough headroom
• tc filter
• tc action
• mirred
• redirect dev
• mirror dev
• blockcast

What your security team should do

• Prioritize patching Linux hosts that run containers, virtual networking, multi-tenant workloads, network appliances, Kubernetes nodes, CI runners, or systems where non-root workloads may obtain CAP_NET_ADMIN.
• Inventory systems with traffic-control mirred usage, shared tc blocks, veth devices, tunnel interfaces, or advanced software-defined networking configurations.
• Restrict CAP_NET_ADMIN and privileged-container use to trusted workloads only; remove unnecessary host networking and network namespace privileges.
• Disable or tightly control unprivileged user namespaces where compatible with business requirements.
• Monitor kernel logs for panics or warnings involving act_mirred, tcf_blockcast_redir, tcf_mirred_to_dev, skb_push_rcsum, skb_push, or skb headroom failures.
• Ensure patched kernels are actually running by scheduling reboots or live-patching validation as required by the platform.
• Track vendor kernel advisories for exact fixed builds because distribution backports may not align with upstream kernel version numbers.