CVE-2026-53220

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: revalidate bridge ports<br /> <br /> ebt_redirect_tg() dereferences br_port_get_rcu() return without a<br /> NULL check, causing a kernel panic when the bridge port has been<br /> removed between the original hook invocation and an NFQUEUE<br /> reinject.<br /> <br /> A mere NULL check isn&amp;#39;t sufficient, however. As sashiko review<br /> points out userspace can not only remove the port from the bridge,<br /> it could also place the device in a different virtual device, e.g.<br /> macvlan.<br /> <br /> If this happens, we must drop the packet, there is no way for us to<br /> reinject it into the bridge path.<br /> <br /> Switch to _upper API, we don&amp;#39;t need the bridge port structure.<br /> Also, this fix keeps another bug intact:<br /> <br /> Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER<br /> too aggressive, which prevents certain logging features when queueing<br /> in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old<br /> CONFIG_BRIDGE_NETFILTER cruft is off.<br /> <br /> Fixes tag is a common ancestor, this was always broken.