{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.170-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.85-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.19.12-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP  Weiming Shi says:  xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING).  ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state-\u003ein being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example:   Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI  KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]  RIP: 0010:devgroup_mt+0xff/0x350  Call Trace:   \u003cTASK\u003e   nft_match_eval (net/netfilter/nft_compat.c:407)   nft_do_chain (net/netfilter/nf_tables_core.c:285)   nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61)   nf_hook_slow (net/netfilter/core.c:623)   arp_xmit (net/ipv4/arp.c:666)   \u003c/TASK\u003e  Kernel panic - not syncing: Fatal exception in interrupt  Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports:  - arpt_CLASSIFY - arpt_mangle - arpt_MARK  that provide explicit NFPROTO_ARP match/target declarations.",
  "id": "DEBIAN-CVE-2026-31424",
  "modified": "2026-09-14T16:47:42.274749343Z",
  "published": "2026-04-13T14:16:12.240Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-31424"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-31424"
  ]
}