PT-2026-52315 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53220
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: revalidate bridge ports
ebt redirect tg() dereferences br port get rcu() 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 nfnetlink log and nfnetlink queue use CONFIG BRIDGE NETFILTER
too aggressive, which prevents certain logging features when queueing
in bridge family: NETFILTER FAMILY BRIDGE can be enabled while the old
CONFIG BRIDGE NETFILTER cruft is off.
Fixes tag is a common ancestor, this was always broken.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux