---
id: "CVE-2026-99285"
page: "https://infrastack.ai/live/CVE-2026-99285"
kind: "vulnerability"
aliases: ["CVE-2026-99285"]
title: "Linux kernel: nftables byteorder conversion over multiple registers is broken"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["linux-kernel", "netfilter", "nftables", "runtime"]
not_affected_if: ["no-nftables-rules"]
published_at: "2026-11-10T18:17:49+00:00"
first_seen_at: "2026-11-10T18:23:01+00:00"
updated_at: "2026-11-10T18:26:35+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99285", "first_seen_at": "2026-11-10T18:23:01+00:00"}]
exploit_sources: []
---

# Linux kernel: nftables byteorder conversion over multiple registers is broken

Link for people: https://infrastack.ai/live/CVE-2026-99285 (this .md is for agents)

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.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the running kernel version with `uname -r` and compare it against the fixed versions in the kernel stable branches (unknown: the sources do not list them).
- Look for nftables rules that use `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).

## Timeline

- 2026-11-10T18:23:01+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99285

## 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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_