PT-2026-128105
CVE-2026-99112
·
Published
2026-10-28
·
Updated
2026-10-28
Description by
Score
N/A
Not availableNo severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls flower: validate mask pointer after nla next()
fl set enc opt() iterates the key's nested tunnel-option attributes
with nla for each attr() while advancing a single mask pointer via
nla next() at the bottom of each loop, so the mask cursor is driven
by the number of key attributes rather than by the mask's own
attributes. The nla ok() added by commit c96adff956191 ("cls flower:
call nla ok() before nla next()") only validates the mask pointer
that was just consumed; the pointer produced by nla next() is used by
the next iteration (fl set geneve opt() and siblings) without any
validation.
The mask's nested attributes are validated with NL VALIDATE LIBERAL,
which merely warns on trailing bytes that do not form a complete
attribute. A mask carrying one valid attribute plus 1-3 residue
bytes (or a non-aligned attribute length making msk depth negative)
therefore reaches the next iteration with msk depth != 0, so neither
the !msk depth check in fl set enc opt() nor the !depth check in the
per-type helpers fires. nla type() then reads past the mask payload
and nla parse nested deprecated() iterates with an nla len taken
from those bytes, reading well beyond the mask attribute (KASAN:
slab-out-of-bounds read in nla validate parse from fl change()).
Validate the advanced mask pointer as well: when the mask is not
legitimately exhausted (msk depth != 0) and the new pointer fails
nla ok(), reject the filter with -EINVAL. An exactly exhausted mask
still skips the check, preserving exact-match behaviour for the
remaining key attributes.
Found an issue in the description? Have something to add? Feel free to write us 👾