CVE-2026-31495: netfilter: ctnetlink: use netlink policy range checks
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use netlink policy range checks
Replace manual range and mask validations with netlink policy annotations in ctnetlink code paths, so that the netlink core rejects invalid values early and can generate extack errors.
- CTAPROTOINFOTCPSTATE: reject values > TCPCONNTRACKSYNSENT2 at policy level, removing the manual >= TCPCONNTRACKMAX check. - CTAPROTOINFOTCPWSCALEORIGINAL/REPLY: reject values > TCPMAXWSCALE (14). The normal TCP option parsing path already clamps to this value, but the ctnetlink path accepted 0-255, causing undefined behavior when used as a u32 shift count. - CTAFILTERORIGFLAGS/REPLYFLAGS: use NLAPOLICYMASK with CTAFILTERFALL, removing the manual mask checks. - CTAEXPECTFLAGS: use NLAPOLICYMASK with NFCTEXPECTMASK, adding a new mask define grouping all valid expect flags.
Extracted from a broader nf-next patch by Florian Westphal, scoped to ctnetlink for the fixes tree.
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to trigger this issue?
The CVSS vector indicates local access and low privileges are required, with no user interaction. Exploitation involves sending crafted ctnetlink netlink attributes containing out-of-range TCP state or window-scale values, or invalid flag bits.
Which inputs are relevant to the vulnerability?
The affected ctnetlink attributes include CTA_PROTOINFO_TCP_STATE, CTA_PROTOINFO_TCP_WSCALE_ORIGINAL, CTA_PROTOINFO_TCP_WSCALE_REPLY, CTA_FILTER_ORIG_FLAGS, CTA_FILTER_REPLY_FLAGS, and CTA_EXPECT_FLAGS. In particular, TCP window-scale values above 14 were accepted and could be used as a u32 shift count, resulting in undefined behavior.
What is the expected impact?
The reported CVSS score is 5.5 (medium) and identifies availability impact as high, with no confidentiality or integrity impact. The scope is unchanged.
How does the fix prevent exploitation?
The fix moves range and flag-mask validation into ctnetlink netlink policy annotations. This causes the netlink core to reject invalid values earlier and generate extended acknowledgement errors, instead of relying on later manual validation.