PT-2026-128105

CVE-2026-99112

·

Published

2026-10-28

·

Updated

2026-10-28

Description by

Score
N/A
Not available

No 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.
Vendors
Affected products
Related identifiers
Found an issue in the description? Have something to add? Feel free to write us 👾