CVE-2026-80634: netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: avoid numencaps underflow on bridge VLAN untag
The DEVPATHBRVLANUNTAG case post-decrements info->numencaps inside WARNONONCE(). numencaps is u8, so if it's already 0 the decrement still happens and wraps it to 255. The break only leaves the inner switch -- a later path entry can set info->indev back to a real device, and we end up returning with numencaps == 255.
nftdevforwardpath() then walks info.encap[] (size 2) up to numencaps, which means an OOB stack read and a bogus count copied into the route descriptor.
Should only happen on a malformed bridge path stack, hence the WARN, but worth handling sanely. Move the decrement out of the WARN.
[ While at this, remove the WARNONONCE since this can only happen with a buggy bridge path stack --pablo ].
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The issue requires a malformed bridge path stack that reaches the DEV_PATH_BR_VLAN_UNTAG case while the encapsulation count is already zero. This is described as a condition caused by a buggy bridge path stack rather than a normal path.
What is the impact if the malformed path is processed?
The unsigned 8-bit encapsulation count can wrap from zero to 255. A later forwarding-path lookup can then walk a two-entry encapsulation array up to that inflated count, causing an out-of-bounds stack read and copying a bogus count into the route descriptor.
What remediation is identified?
The resolved fix moves the decrement outside of WARN_ON_ONCE so that the count does not underflow. The associated change also removes the warning because the condition is attributed to a buggy bridge path stack.