CVE-2026-99112
net/sched: cls_flower: validate mask pointer after nla_next()
- State
- Published
- Severity
- Not scored
- Published
- Oct 28, 2026
- Updated
- Oct 30, 2026
- Reserved
- Sep 25, 2026
Description
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.
Scores
The record has no CVSS score.
Weaknesses
The record names no weakness.
Affected Products
| Product | Versions |
|---|---|
LinuxLinux |
|
LinuxLinux |
|
References
- https://git.kernel.org/stable/c/a9283d006eef7e3b56f0f279a49bb63f6e5e61df
- https://git.kernel.org/stable/c/497944d534ffb1be300365523030c7c6517cbbb6
- https://git.kernel.org/stable/c/a55d84907337580d91c0d54779d9d4b934633158
- https://git.kernel.org/stable/c/cff9bf34afde46c238189cc6f7690b7e35225df1
- https://git.kernel.org/stable/c/35354bf67aa0f7bace66ffb614906124ed50d59d
- https://git.kernel.org/stable/c/45e60747a9db2307929260d9aa9c1c6cbb70ee77
- https://git.kernel.org/stable/c/bb187146c7e5c666874784e4f3fc1bc5126e6e92
- https://git.kernel.org/stable/c/fee10655709c5c597e8e9f722f3035d9ea31ff3a
Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.