CVE-2026-72255: Linux Vulnerability (CVSS 7.8)

Description

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.

Metrics

CVSS 3.1

7.8/10

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS Probability

0.21%

11.0th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

Vendor	Product	Versions
Linux	Linux	>= 34666d467cbf1e2e3c7bb15a63eccfb582cdd71f, < 430521af7fe8a9c08f5a2554224a35f11f51d99e; >= 34666d467cbf1e2e3c7bb15a63eccfb582cdd71f, < 3f03a2d225c668283110ad5f9ff159ba4591e2c7; >= 34666d467cbf1e2e3c7bb15a63eccfb582cdd71f, < 01ace27af47801dd7f6b839e782b62863af979cc; >= 34666d467cbf1e2e3c7bb15a63eccfb582cdd71f, < 0ca505346c5e2905ab7b5313af801fcf38f594a8; >= 34666d467cbf1e2e3c7bb15a63eccfb582cdd71f, < 47b3af24de5fbed4bf2952de0f5294ef1a338a26; >= 34666d467cbf1e2e3c7bb15a63eccfb582cdd71f, < c9c9b37f8c5505224e8d206184df3bb668ee00cf
Linux	Linux	3.18

References

Timeline

Published: Aug 15, 2026
Last Modified: Aug 17, 2026
Status: Received

Frequently Asked Questions

What is CVE-2026-72255?

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.

How severe is CVE-2026-72255?

CVE-2026-72255 has a CVSS score of 7.8/10 (HIGH severity). The EPSS model estimates a 0.21% probability of exploitation in the next 30 days.

How do I fix CVE-2026-72255?

Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →