CVE-2026-53014: net/sched: act_mirred: fix wrong device for mac_header_xmit check in tcf_blockcast_redir
In the Linux kernel, the following vulnerability has been resolved:
net/sched: actmirred: fix wrong device for macheaderxmit check in tcfblockcastredir
In tcfblockcastredir(), when iterating block ports to redirect packets to multiple devices, the macheaderxmit flag is queried from the wrong device. The loop sends to devprev but queries devismacheaderxmit(dev) — which is the NEXT device in the iteration, not the one being sent to.
This causes tcfmirredtodev() to make incorrect decisions about whether to push or pull the MAC header. When the block contains mixed device types (e.g., an ethernet veth and a tunnel device), intermediate devices get the wrong macheaderxmit flag, leading to skb header corruption. In the worst case, skbpushrcsum with an incorrect maclen can exhaust headroom and panic.
The last device in the loop is handled correctly (line 365-366 uses devismacheaderxmit(devprev)), confirming this is a copy-paste oversight for the intermediate devices.
Fix by using devprev instead of dev for the macheaderxmit query, consistent with the device actually being sent to.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In tcf_blockcast_redir(), when iterating block ports for redirection, ensure the mac_header_xmit check uses dev_prev (the previous/intermediate device) rather than dev. This fixes the copy-paste error where the query was made on dev, causing tcf_mirred_to_dev() to make incorrect decisions about pushing/pulling the MAC header.
Linux kernel net/sched act_mirred (tcf_blockcast_redir / tcf_mirred_to_dev) mac_header_xmit device reference = Use dev_prev (instead of dev) when querying dev_is_mac_header_xmit() for the intermediate devices during block port iteration
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using Linux traffic control mirroring or redirecting through a block with multiple output ports are exposed when the block includes mixed device types, such as an Ethernet veth and a tunnel device. The faulty behavior affects intermediate devices in the iteration; the final device is handled correctly.
What access does an attacker need to trigger the vulnerability?
The CVSS vector indicates local access and low privileges are required, with no user interaction. Exploitation requires a traffic-control configuration that redirects packets across a multi-port block with mixed device types.
What is the impact if the issue is triggered?
Incorrect MAC-header push or pull decisions can corrupt skb headers. In the worst case, incorrect skb_push_rcsum headroom handling can cause a kernel panic, resulting in denial of service.
What can be done if patching is not immediately possible?
Avoid traffic-control block redirection or mirroring configurations that send packets to multiple mixed device types. In particular, avoid arrangements where intermediate output devices differ in MAC-header transmission behavior, such as combining Ethernet veth and tunnel devices in the same block.