CVE-2026-46101

What it actually does

This vulnerability is an improper input validation flaw in the Linux kernel netfilter/nftables bitwise expression handling. A malformed nft_bitwise left-shift or right-shift rule can specify a zero shift value, which the kernel previously accepted during rule initialization. When that rule is evaluated in the packet path, carry-propagation logic may compute a 32-bit shift on a 32-bit word, triggering undefined behavior in kernel space. The expected impact is local denial of service through a kernel warning, oops, panic, hang, or otherwise unstable packet-processing behavior. Exploitation requires local privileges sufficient to create or modify nftables rules, typically CAP_NET_ADMIN or equivalent capability inside a network namespace.

Why it matters to the business

A local user or compromised workload with permission to manage nftables rules could crash or destabilize an affected Linux system, causing service interruption, dropped network traffic, forced reboot, or disruption to container hosts and network appliances that rely on Linux packet filtering. The CVSS score indicates moderate severity, with high availability impact but no expected direct confidentiality or integrity impact. This issue is not listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no known public exploit maturity in the provided data, so it is generally a patch-cycle priority unless untrusted users or workloads can obtain CAP_NET_ADMIN through containers, network namespaces, or permissive user-namespace settings.

How an attack unfolds

An attacker first obtains local execution on an affected Linux system or within an environment where they can create a network namespace and acquire nftables administration capability. They then submit a crafted nftables rule that uses an nft_bitwise left-shift or right-shift expression with a zero shift operand. Vulnerable kernels fail to reject the malformed operand at rule initialization time, allowing the invalid rule into the active ruleset. When network traffic later evaluates that rule, the netfilter packet path reaches carry-propagation code that performs an undefined 32-bit shift operation. Depending on kernel build options, CPU behavior, and runtime conditions, this may lead to a kernel oops, panic, hang, or other denial-of-service condition. There is no indication from the provided intelligence that this vulnerability enables privilege escalation, data theft, or remote exploitation without prior local capability to manage nftables rules.

How to fix it

Upgrade to a Linux kernel build from the operating system or appliance vendor that includes the netfilter fix to reject zero shift operands in nft_bitwise expressions during initialization. No exact fixed package versions were provided, so use vendor advisories and kernel changelogs to identify updates containing the patch described as rejecting zero shift operands in nft_bitwise left and right shift expressions. After updating, reboot into the patched kernel and remove any unsupported or temporary kernels from boot defaults where appropriate. As compensating controls, restrict CAP_NET_ADMIN to trusted users and workloads, avoid granting privileged containers broad network administration capability, disable or restrict unprivileged user namespaces where operationally feasible, and monitor for unauthorized nftables ruleset changes. If nftables is not required on a system, reduce exposure by disabling unused packet-filtering management paths according to vendor guidance; do not rely on this instead of patching where nftables is in use.

How to confirm the fix worked

Confirm that systems are running a vendor kernel version that includes the nft_bitwise zero-shift validation fix. Validate the running kernel, not only the installed package, because Linux kernel updates usually require a reboot. Review vendor changelogs or source patches for the netfilter change that rejects zero shift operands for nft_bitwise left and right shift expressions. In a controlled non-production test environment, attempting to load a crafted nftables bitwise shift expression with a zero shift should fail during rule creation with an invalid-argument style error rather than being accepted into the ruleset. Also inspect active nftables rulesets for unexpected bitwise shift expressions and confirm that administrative permissions for nftables are limited to intended operators and services.

Typical attack path

1. Gain local code execution on an affected Linux system or in a containerized environment with access to network namespace functionality.
2. Obtain or abuse privileges sufficient to create or modify nftables rules, such as CAP_NET_ADMIN in the relevant namespace.
3. Create a malformed nftables bitwise shift expression using a zero shift operand.
4. Load the malformed rule into the kernel; vulnerable kernels accept it instead of rejecting it during initialization.
5. Cause traffic to traverse the affected nftables rule path.
6. Trigger undefined behavior in kernel packet processing, potentially causing a kernel crash, panic, hang, or service outage.

How to detect it

To determine whether this was already exploited, review kernel logs, system journals, crash dumps, and audit records around unexplained reboots, kernel panics, nftables changes, or service outages. Useful sources include journalctl kernel messages, /var/log/kern.log, /var/log/messages, dmesg output retained by log forwarding, pstore/ramoops records, kdump/vmcore artifacts, auditd logs for nft or nftables rule changes, shell history for administrative users, container runtime audit logs for privileged containers or CAP_NET_ADMIN grants, and EDR telemetry showing execution of nft or iptables-nft tooling. Look for kernel diagnostics mentioning nft_bitwise, netfilter, shift-out-of-bounds, UBSAN, undefined behavior, kernel oops, or panic near the time of ruleset changes. Also look for unexpected nftables ruleset modifications immediately before crashes or packet-processing instability. Because no public exploit indicators or actor-specific tooling are provided, detection should focus on behavioral evidence: unauthorized nftables rule creation, local capability abuse, and kernel crash artifacts involving netfilter bitwise expression handling.

• nft_bitwise
• net/netfilter/nft_bitwise.c
• UBSAN: shift-out-of-bounds
• shift exponent 32 is too large for 32-bit type 'unsigned int'
• undefined behavior in net/netfilter/nft_bitwise.c
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• nft

What your security team should do

• Inventory Linux systems and appliances using nftables/netfilter and prioritize those that allow local shell access, run multi-tenant workloads, host containers, or grant CAP_NET_ADMIN to non-root services.
• Apply vendor kernel updates that include the nft_bitwise zero-shift operand rejection fix, then reboot systems into the patched kernel.
• Harden privilege boundaries by minimizing CAP_NET_ADMIN, privileged containers, host network mode, and unprivileged user namespace usage where business requirements allow.
• Review nftables ruleset management workflows and ensure only trusted automation and administrators can modify packet-filtering rules.
• Monitor kernel logs for netfilter, nft_bitwise, UBSAN, oops, panic, or shift-out-of-bounds messages that may indicate attempted triggering or unstable behavior.
• Because this vulnerability is not KEV-listed, not known ransomware-used, and has very low EPSS in the provided data, handle it through normal vulnerability management timelines unless exposed privilege boundaries increase local attacker opportunity.