Answer in brief
CVE-2026-99285 records a Unknown severity vulnerability in netfilter: nft_byteorder: remove multi-register support. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63 <3c5fb3a6c8118d15e60295e76fb5b879021eef43 || >=c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63 <dc29c0478b8564feb9371e715b5a0016eb8903fd || >=c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63 <bb061d3de41707415269be75ebf700efb03ec212 || fca41e5b687e029f69e3a35a2fa31e2560e538dc || 25b42be4e067e107a2559266b54bf07fa5b094fb || 9a865a11d6890d4a789db1eaafebdc8bd092b12c || b8b514b2a6cdfac24911e4910461bcb9db15ca8d || 18a169810cff769a7a697b35058c756805f589e0 || 1a605657adc58b3c8e2c1c66aaa5fecd29072135 || 013deed31ab15ef287b0045e4e7bd8f250e75b94 || >=4.19.307 <4.20 || >=5.4.269 <5.5 || >=5.10.210 <5.11 || >=5.15.140 <5.16 || >=6.1.64 <6.2 || >=6.5.13 <6.6 || >=6.6.3 <6.7 | 3c5fb3a6c8118d15e60295e76fb5b879021eef43, dc29c0478b8564feb9371e715b5a0016eb8903fd, bb061d3de41707415269be75ebf700efb03ec212, 4.20, 5.5, 5.11, 5.16, 6.2, 6.6, 6.7 |
| Linux/Linuxgeneric | 6.7 | Not reported |
Published upstream
Nov 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Nov 10, 2026
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.
Quoted source text, attributed separately from HOL analysis.