CVE intelligence

CVE-2026-53220

Vulnerability intelligence

Published Jun 25, 2026Sources checked Nov 12, 2026

5.5MEDIUMCVSS out of 10

What this means

Review the available evidence

CVE-2026-53220 and is rated Medium severity with a CVSS score of 5.5. It is not in the current CISA KEV record we collected. That does not prove exploitation has not occurred.

What to do next

Remediation and response

Microsoft Security Response Center guidance

Vendor revision: Nov 5, 2026

Release Notes

Ubuntu Security Notices guidance

Vendor revision: Oct 9, 2026

Vendor remediation details

This update corrects flaws in the following subsystems: - ARM32 architecture; - ARM64 architecture; - MIPS architecture; - x86 architecture; - Intel NPU Driver; - Auxiliary display drivers; - Compressed RAM block device driver; - GPIO subsystem; - GPU drivers; - HID subsystem; - I2C subsystem; - IIO subsystem; - InfiniBand drivers; - Input Device core drivers; - Input Device (Mouse) drivers; - Multiple devices driver; - Media drivers; - Fastrpc Driver; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - Microsoft Azure Network Adapter (MANA) driver; - Texas Instruments network drivers; - NVMEM (Non Volatile Memory) drivers; - Parport drivers; - SCSI subsystem; - SLIMbus drivers; - NVIDIA Tegra SoC drivers; - SPI subsystem; - Trusted Execution Environment drivers; -

Ubuntu Security Notices guidance

Vendor revision: Oct 9, 2026

Vendor remediation details

CISA KEVNot listedBased on the latest collected catalog

EPSS0.1%Estimated 30-day exploitation probability

Ransomware useNot markedCISA KEV ransomware field

Threat actors0Source-linked actor relationships

Overview

What is CVE-2026-53220?

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.

Source: NVD