CVE-2026-53220: netfilter: revalidate bridge ports
In the Linux kernel, the following vulnerability has been resolved:
netfilter: revalidate bridge ports
ebtredirecttg() dereferences brportgetrcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject.
A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan.
If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path.
Switch to upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact:
Both nfnetlinklog and nfnetlinkqueue use CONFIGBRIDGENETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTERFAMILYBRIDGE can be enabled while the old CONFIGBRIDGENETFILTER cruft is off.
Fixes tag is a common ancestor, this was always broken.
Affected Software
Remediation
Event History
Frequently Asked Questions
What conditions are required to trigger the panic?
An attacker needs local access and low privileges, and must cause a bridge port to be removed after the original netfilter hook invocation but before an NFQUEUE packet is reinjected. Moving the device into another virtual-device configuration, such as macvlan, during that interval can also make reinjection invalid.
What is the impact of successful exploitation?
The vulnerable dereference can cause a kernel panic, resulting in a denial of service. The provided CVSS vector indicates no confidentiality or integrity impact.
Are systems using bridge-family netfilter features relevant even without the legacy bridge netfilter configuration?
Yes. The description states that NETFILTER_FAMILY_BRIDGE can be enabled while the older CONFIG_BRIDGE_NETFILTER configuration is disabled, and notes related queueing and logging behavior in that scenario.
What should be done to remediate this issue?
Apply an available patch from the referenced stable kernel commits. The fix revalidates the bridge relationship before reinjection and drops packets that can no longer be reinjected into the bridge path.