CVE-2026-52915

What it actually does

This is an out-of-bounds array access in the Linux kernel IPv6 netfilter Hop-by-Hop options match implementation, ip6t_hbh. The rule setup path accepts a user-supplied option count, optsnr, without verifying that it fits the fixed opts[16] array in struct ip6t_opts. A local user or process with permission to install IPv6 netfilter/xtables rules can submit malformed match data with an oversized option count, causing the kernel to access beyond the array boundary during rule validation. The most likely impact is kernel warning, UBSAN report, oops, or denial of service; depending on kernel build, hardening, and surrounding memory layout, out-of-bounds access in kernel code may also create memory-corruption risk.

Why it matters to the business

Systems that allow local users, administrators, automation, containers, or network appliances to modify IPv6 firewall rules may be vulnerable to a kernel-level crash or instability condition. In practical terms, this can disrupt hosts, firewalls, routers, Kubernetes nodes, VPN gateways, or appliances that rely on Linux netfilter. The EPSS score is currently low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, the issue remains important for multi-user systems, privileged container environments, and infrastructure where kernel crashes have high availability impact.

How an attack unfolds

An attacker first needs access to a local account, container, management plane, or compromised service that has CAP_NET_ADMIN or equivalent privileges to configure IPv6 netfilter rules. The attacker then crafts an IPv6 xtables/ip6tables rule using the Hop-by-Hop options match with a malformed option descriptor count greater than the kernel’s fixed array capacity of 16. When the rule is submitted through the netfilter rule installation path, the vulnerable hbh_mt6_check() logic processes the attacker-controlled count without sufficient bounds checking. The kernel then indexes past the end of the opts array, which can trigger a sanitizer warning, kernel oops, or crash. Successful exploitation is therefore most plausible as local denial of service from a privileged context or from an insufficiently restricted container granted network-administration capabilities.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the fix for netfilter: ip6t_hbh: reject oversized option lists. The corrected behavior rejects user-provided optsnr values that exceed the fixed IP6T_OPTS_OPTSNR limit of 16 during rule setup. No exact fixed package versions were provided in the input, so use vendor advisories for the deployed distribution and kernel stream. As interim mitigation, restrict CAP_NET_ADMIN to only trusted users and workloads, avoid privileged containers unless necessary, block untrusted access to firewall-management interfaces, and consider disabling or preventing use of the ip6t_hbh match module where operationally feasible. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build containing the ip6t_hbh bounds-check fix. Validate with uname -r, distribution package metadata, and vendor changelogs/advisories referencing netfilter ip6t_hbh oversized option list rejection. Review whether any workloads or users retain CAP_NET_ADMIN unnecessarily. If safe in a test environment, attempt to submit an oversized ip6t_hbh option-list rule and confirm the patched kernel rejects it cleanly instead of producing UBSAN, oops, or array-index-out-of-bounds messages. Also verify that hosts have rebooted into the fixed kernel and that old vulnerable kernels are not still selected by the bootloader.

Typical attack path

1. Obtain local code execution or shell access on a Linux system, or compromise a container/workload with CAP_NET_ADMIN or equivalent network namespace privileges.
2. Confirm IPv6 netfilter/xtables support is available and the ip6t_hbh match module can be used or autoloaded.
3. Construct a malformed IPv6 firewall rule or raw netfilter rule replacement payload with an oversized Hop-by-Hop options count.
4. Submit the rule through ip6tables, ip6tables-restore, or a direct setsockopt-based netfilter interface.
5. Trigger the vulnerable rule setup validation path in the kernel.
6. Cause an out-of-bounds access, producing a kernel UBSAN warning, oops, instability, or denial of service.

How to detect it

Look for evidence of attempted rule installation using the IPv6 Hop-by-Hop netfilter match and for kernel error messages from ip6t_hbh. Primary log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd logs, process execution telemetry, EDR command-line history, container runtime events, and firewall-management automation logs. Search for UBSAN or kernel oops messages referencing net/ipv6/netfilter/ip6t_hbh.c, array-index-out-of-bounds, index 16, hbh_mt6_check, or ip6t_hbh. Correlate those events with recent executions of ip6tables, ip6tables-restore, nft/xtables compatibility tooling, or direct setsockopt activity from processes with CAP_NET_ADMIN. On container hosts, review whether a privileged container or workload with CAP_NET_ADMIN executed ip6tables commands shortly before kernel warnings, node instability, reboot, or crash. Because legitimate firewall tooling may use ip6tables, treat command-line indicators as triage leads and prioritize cases that coincide with kernel bounds-check warnings, oopses, unexpected reboots, or malformed IPv6 hbh match usage.

• UBSAN: array-index-out-of-bounds in ../net/ipv6/netfilter/ip6t_hbh.c
• net/ipv6/netfilter/ip6t_hbh.c:110
• index 16 is out of range for type '__u16 [16]'
• hbh_mt6_check
• ip6t_hbh
• -m hbh
• --hbh-opts
• ip6tables-restore
• ip6tables
• array-index-out-of-bounds
• IP6T_SO_SET_REPLACE
• setsockopt

What your security team should do

• Prioritize patching Linux systems where untrusted users, containers, CI jobs, appliances, or automation can modify network/firewall rules.
• Inventory systems and container platforms that grant CAP_NET_ADMIN, run privileged containers, or expose firewall rule management to less-trusted operators.
• Update affected kernels through vendor-supported channels and reboot into the fixed kernel.
• Remove CAP_NET_ADMIN from workloads that do not strictly need it, and enforce least privilege for network namespace and firewall-management operations.
• Monitor kernel logs for ip6t_hbh out-of-bounds or UBSAN messages, especially on shared hosts and container nodes.
• Review recent ip6tables/ip6tables-restore activity for unusual use of the hbh match or malformed IPv6 rule updates.
• If kernel crash evidence exists, preserve vmcore, dmesg, audit logs, shell history, and container runtime events for investigation.