Bug 2516717 (CVE-2026-72255) - CVE-2026-72255 kernel: netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst
Summary: CVE-2026-72255 kernel: netfilter: nf_queue: pin bridge device while NFQUEUE h...
Keywords:
Status: NEW
Alias: CVE-2026-72255
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-15 06:27 UTC by OSIDB Bzimport
Modified: 2026-10-08 09:50 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2026:75746 0 None None None 2026-10-05 10:48:49 UTC
Red Hat Product Errata RHSA-2026:75747 0 None None None 2026-10-05 11:23:56 UTC
Red Hat Product Errata RHSA-2026:76738 0 None None None 2026-10-07 20:29:02 UTC
Red Hat Product Errata RHSA-2026:76739 0 None None None 2026-10-08 09:50:21 UTC

Description OSIDB Bzimport 2026-08-15 06:27:25 UTC
In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst

The br_netfilter fake rtable is embedded in struct net_bridge and is
attached to bridged packets with skb_dst_set_noref(). If such a packet is
queued to NFQUEUE, __nf_queue() upgrades that fake dst with
skb_dst_force().

At that point the queued skb can hold a real dst reference after bridge
teardown has started. The problem is not that every bridged packet needs
its own dst reference. The problem is that NFQUEUE can keep the bridge
private fake dst alive after unregister begins.

Fix this by keeping the bridge fake dst model unchanged and pinning the
bridge master device only while the packet sits in NFQUEUE. Record the
bridge device in nf_queue_entry when the queued skb carries a bridge fake
dst, take a device reference for the queue lifetime, and drop it when the
queue entry is freed.

Also make sure queued entries are reaped when that bridge device goes
down, and drop the redundant nf_bridge_info_exists() test from the fake
dst detection.

This keeps netdev_priv(br->dev) alive until verdict completion, so the
embedded fake rtable and its metrics backing storage cannot be freed out
from under dst_release(). It also avoids the constant refcount bump and
avoids using ipv4-specific dst helpers for IPv6 bridge traffic.

Comment 6 Akiyoshi Kurita 2026-09-01 03:41:08 UTC
FYI, a public PoC / possible LPE exploit for CVE-2026-72255 has been released:


https://github.com/NebuSec/CyberMeowfia/tree/main/security-research/Linux-CVE-2026-72255-Ubuntu-7.0.0-28


Possible relevant stable kernel fixes:

RHEL 7 / RHEL 8 / RHEL 9:
https://git.kernel.org/stable/c/430521af7fe8a9c08f5a2554224a35f11f51d99e

RHEL 10:
https://git.kernel.org/stable/c/01ace27af47801dd7f6b839e782b62863af979cc

A possible mitigation may be to prevent the nfnetlink_queue module from loading:

echo 'install nfnetlink_queue /bin/false' \
    > /etc/modprobe.d/disable-nfnetlink-queue.conf

This mitigation has not yet been fully validated.

Comment 7 Akiyoshi Kurita 2026-09-01 04:51:11 UTC
Additional update:

A demonstration video for the public CVE-2026-72255 PoC / possible LPE exploit has now been published:

https://x.com/cybermeowfia/status/2094607191907221939

Comment 8 Jon Orris 2026-10-05 10:48:48 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:75746 https://access.redhat.com/errata/RHSA-2026:75746

Comment 9 Jon Orris 2026-10-05 11:23:54 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2026:75747 https://access.redhat.com/errata/RHSA-2026:75747

Comment 10 Jon Orris 2026-10-07 20:29:02 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 10

Via RHSA-2026:76738 https://access.redhat.com/errata/RHSA-2026:76738

Comment 11 Jon Orris 2026-10-08 09:50:20 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2026:76739 https://access.redhat.com/errata/RHSA-2026:76739


Note You need to log in before you can comment on or make changes to this bug.