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.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-098723 advisory.

    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.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-102077 advisory.

    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.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-53220)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
340482	Unity Linux 20.1050a Security Update: kernel (UTSA-2026-098723)	Nessus	Unity Linux Local Security Checks	Local	medium
338564	Unity Linux 20.1050e Security Update: kernel (UTSA-2026-102077)	Nessus	Unity Linux Local Security Checks	Local	medium
328493	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-1968)	Nessus	Amazon Linux Local Security Checks	Local	high
327383	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-1925)	Nessus	Amazon Linux Local Security Checks	Local	high
323476	Linux Distros Unpatched Vulnerability : CVE-2026-53220	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-53220

medium

Tenable Plugins

medium

medium

high

high

medium