Skip to content
Fencer Intel
no cvss —

CVE-2026-99285 json

netfilter: nft_byteorder: remove multi-register support

published yesterday modified yesterday also EUVD-2026-121397

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 6%
public exploits
0
none known

Summary

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.

Patch / fix

  • Linux Linux 4.20, 5.5, 5.11, 5.16, 6.2, 6.6, 6.7, 7.1
  • linux Debian 13 6.12.115-1
  • linux Debian 14 7.1.3-1

debian advisories DEBIAN-CVE-2026-99285

Is CVE-2026-99285 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-99285 updated cvss 5.5

kernel: kernel: Memory corruption via multi-register byteorder conversion in netfilter

  • Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +82 more Red Hat Enterprise Linux 10 kernel Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-9 Red Hat OpenShift Container Platform 5 openshift/ose-rhel-coreos-9, openshift/ose-rhel-coreos-10
    affected: workaround, no fix available “Fix deferred”
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 kernel-rt, kernel-rt-selftests-internal Red Hat OpenShift Container Platform 4 openshift/ose-rhel-coreos-8
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.17% chance of exploitation in the next 30 days, higher than 6% of all scored CVEs (FIRST EPSS, 2026-11-11).

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.