netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP
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->in 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: 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) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.253, 5.15.203, 6.1.168, 6.12.81, 6.18.22, 6.19.12, 6.6.134
- CVEs
- CVE-2026-31424
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 05:26 UTC · Revision 1
Source evidence
netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP
core-osv · Original sourcePublished 13 Apr 2026, 13:40 UTC
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->in 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: 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) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO
osv:CVE-2026-31424
Kernel
Fixed versions: 5.10.253, 5.15.203, 6.1.168, 6.6.134, 6.12.81, 6.18.22, 6.19.12
Complete source record
{
"id": "86067dbd39276c15e316c691eb3fa32f5745711ab36b349e6c60f3722fe8c508",
"url": "https://osv.dev/vulnerability/CVE-2026-31424",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP",
"summary": "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->in 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: 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) Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO",
"evidence": "osv:CVE-2026-31424",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.10.253",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.203",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.168",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.134",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.81",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.22",
"evidence": "/affected/1/ranges"
},
{
"value": "6.19.12",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-31424",
"aliases": [
"CVE-2026-31424"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "9291747f118d6404e509747b85ff5f6dfec368d2"
},
{
"fixed": "80e3c75f71c3ea1e62fcb032382de13e00a68f8b"
},
{
"fixed": "d9a0af9e43416aa50c0595e15fa01365a1c72c49"
},
{
"fixed": "1cd6313c8644bfebbd813a05da9daa21b09dd68c"
},
{
"fixed": "f00ac65c90ea475719e08d629e2e26c8b4e6999b"
},
{
"fixed": "e7e1b6bcb389c8708003d40613a59ff2496f6b1f"
},
{
"fixed": "dc3e27dd7d76e21106b8f9bbdc31f5da74a89014"
},
{
"fixed": "3e79374b03bf9a2f282f0eb1d0ac3776f7e0f28a"
},
{
"fixed": "3d5d488f11776738deab9da336038add95d342d1"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31424.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "2.6.39"
},
{
"fixed": "5.10.253"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.203"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.168"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.134"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.81"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.22"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "6.19.12"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31424.json"
}
}
],
"modified": "2026-10-28T02:30:26.443883149Z",
"provider": "osv",
"references": [
"https://cert-portal.siemens.com/productcert/html/ssa-019113.html",
"https://cert-portal.siemens.com/productcert/html/ssa-082556.html",
"https://cert-portal.siemens.com/productcert/html/ssa-457936.html",
"https://git.kernel.org/stable/c/1cd6313c8644bfebbd813a05da9daa21b09dd68c",
"https://git.kernel.org/stable/c/3d5d488f11776738deab9da336038add95d342d1",
"https://git.kernel.org/stable/c/3e79374b03bf9a2f282f0eb1d0ac3776f7e0f28a",
"https://git.kernel.org/stable/c/80e3c75f71c3ea1e62fcb032382de13e00a68f8b",
"https://git.kernel.org/stable/c/d9a0af9e43416aa50c0595e15fa01365a1c72c49",
"https://git.kernel.org/stable/c/dc3e27dd7d76e21106b8f9bbdc31f5da74a89014",
"https://git.kernel.org/stable/c/e7e1b6bcb389c8708003d40613a59ff2496f6b1f",
"https://git.kernel.org/stable/c/f00ac65c90ea475719e08d629e2e26c8b4e6999b",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31424.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-31424",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31424.json"
}
},
"related_cves": [
{
"value": "CVE-2026-31424",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 492721,
"published_at": "2026-04-13T13:40:27.957+00:00"
}