CVE-2026-99285 · Runtime
NO FIX YET
The Linux kernel's nftables byteorder conversion code mishandles 64-bit conversions across several registers because the source register array advances in 4-byte steps. The kernel fix removes multi-register byteorder support entirely; the sources do not describe an attacker-controlled outcome.
first public Nov 10, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
The sources describe a Linux kernel nftables byteorder bug affecting multi-register conversions, which nftables rules such as concatenations with ct mark and meta mark may use. The sources also note that rulesets generated by nftables before 1.1.0 can produce incorrect byteorder conversions that fail to load with this kernel change. Systems that do not use nftables byteorder expressions are not described as affected.
Not affected if no-nftables-rules
Who cares linux-kernel, netfilter, nftables
uname -r and compare it against the fixed versions in the kernel stable branches (unknown: the sources do not list them).byteorder with multiple registers (unknown: the sources do not say which rules are affected beyond the note about rulesets from nftables before 1.1.0).Unknown from the sources.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_byteorder: remove multi-register support
64bit byteorder conversion is broken when several registers need to be converted because the source register array advances in steps for 4 bytes instead of 8:
for (i = ... src64 = nft_reg_load64(&src[i]); ~~~~~ u32 *src nft_reg_store64(&dst64[i],
Remove the multi-register support, it has other issues as well:
Pablo points out that commit caf3ef7468f7 ("netfilter: nf_tables: prevent OOB access in nft_byteorder_eval") alters semantics: before the loop operated on registers, i.e. for ( ... ) dst32[i] = htons((u16)src32[i])
.. but after the patch it will operate on bytes, which makes this useless to convert e.g. concatenations, which store each compound in its own register.
Multi-convert of u32 has one theoretical application:
ct mark . meta mark . tcp dport @intervalset
Because ct mark and meta mark are host byte order, use with intervals has to convert the byteorder for ct/meta mark value to network byte order (bigendian).
nftables emits this: [ meta load mark => reg 1 ] [ byteorder reg 1 = hton(reg 1, 4, 4) ] [ ct load mark => reg 9 ] [ byteorder reg 9 = hton(reg 9, 4, 4) ] ...
I.e. two separate calls. Theoretically it could be changed to do: [ meta load mark => reg 1 ] [ ct load mark => reg 9 ] [ byteorder reg 1 = htonl(reg 1, 4, 8) ] ...
But then all it would take to change the set to meta mark . tcp dport . ct mark
... and we'd be back to two "byteorder" calls. IOW, support to convert a range of registers is both dysfunctional and dubious.
Simplify this: remove the feature.
Pablo Neira Ayuso points out that nftables before 1.1.0 can generate incorrect byteorder conversions, see 9fe58952c45a, "evaluate: skip byteorder conversion for selector smaller than 2 bytes" in nftables.git). Affected rulesets fail to load with this change and old userspace due to 'len != size' check.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.