netfilter: nft_byteorder: remove multi-register support

Description

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.

Timeline

Scores

No CVSS score yet: neither the CNA, CISA nor NVD has scored this CVE. NVD status: Received.

EPSS (exploitation in 30 days)

0.17% · top 94% of all CVEs (12 Nov 2026)

The list uses the assigner's score when there is one, then CISA's, then NVD's: Not scored.

Affected products

• Linux · Linux

  • affected c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63 – < 3c5fb3a6c8118d15e60295e76fb5b879021eef43
  • affected c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63 – < dc29c0478b8564feb9371e715b5a0016eb8903fd
  • affected c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63 – < bb061d3de41707415269be75ebf700efb03ec212
  • affected fca41e5b687e029f69e3a35a2fa31e2560e538dc
  • affected 25b42be4e067e107a2559266b54bf07fa5b094fb
  • affected 9a865a11d6890d4a789db1eaafebdc8bd092b12c
  • affected b8b514b2a6cdfac24911e4910461bcb9db15ca8d
  • affected 18a169810cff769a7a697b35058c756805f589e0
  • affected 1a605657adc58b3c8e2c1c66aaa5fecd29072135
  • affected 013deed31ab15ef287b0045e4e7bd8f250e75b94
  • affected 4.19.307 – < 4.20
  • affected 5.4.269 – < 5.5
  • affected 5.10.210 – < 5.11
  • affected 5.15.140 – < 5.16
  • affected 6.1.64 – < 6.2
  • affected 6.5.13 – < 6.6
  • affected 6.6.3 – < 6.7

• Linux · Linux

  • affected 6.7
  • unaffected < 6.7
  • unaffected 6.12.115 – ≤ 6.12.*
  • unaffected 6.18.59 – ≤ 6.18.*
  • unaffected 7.1 – ≤ *

Sources

The same CVE in the primary databases and aggregators, to check against.

• CVE.org record (opens in a new tab)
• CVE List JSON (GitHub) (opens in a new tab)
• NVD (opens in a new tab)
• FIRST EPSS (opens in a new tab)
• EUVD EUVD-2026-121397 (opens in a new tab)
• OSV.dev (opens in a new tab)
• GitHub Advisories (opens in a new tab)
• CIRCL Vulnerability-Lookup (opens in a new tab)

Badge for a README or a ticket

[![CVE-2026-99285](https://cveledger.app/badge/CVE-2026-99285.svg)](https://cveledger.app/cve/CVE-2026-99285)

Record last updated 10 Nov 2026, 17:37 UTC.