{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.115-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.3-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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(\u0026src[i]);                              ~~~~~ u32 *src       nft_reg_store64(\u0026dst64[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 =\u003e reg 1 ]  [ byteorder reg 1 = hton(reg 1, 4, 4) ]  [ ct load mark =\u003e 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 =\u003e reg 1 ]  [ ct load mark =\u003e 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.",
  "id": "DEBIAN-CVE-2026-99285",
  "modified": "2026-11-11T05:47:32.200941608Z",
  "published": "2026-11-10T18:17:49.147Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-99285"
    }
  ],
  "upstream": [
    "CVE-2026-99285"
  ]
}