Cloudanix VulnDB

CVE-2026-43238

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

May 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A user with certain local network configuration permissions could crash an affected Linux system by applying a specially crafted traffic rule.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This is a Linux kernel denial-of-service flaw in the traffic control skbedit action. When skbedit is configured to select a transmit queue using a packet hash across a queue range that spans all possible 16-bit queue IDs, the computed range size can wrap to zero. When traffic later triggers that action, the kernel can execute a modulo operation with zero in tcf_skbedit_hash(), causing a divide-by-zero exception and potentially crashing the kernel or disrupting networking on the host. Exploitation requires local privileges sufficient to configure traffic control actions, typically CAP_NET_ADMIN in the relevant network namespace.

Why it matters to the business

A user or process with limited but network-administration-level privileges on a Linux system could cause a host outage or network disruption. The main risk is availability loss for workloads running on affected kernels, especially systems that allow containers, namespaces, or delegated networking controls. Public exploitation indicators are currently low: EPSS is 0.00128, the 30-day trend is flat, there is no known CISA KEV listing, and no mature public exploit is reported; however, kernel crashes can still create significant operational impact where local multi-tenant access exists.

How an attack unfolds

An attacker first needs local access with the ability to create or modify Linux traffic control configuration. They configure a tc skbedit action using hash-based transmit queue selection with an invalid edge-case queue range, such as a range from 0 through 65535. Due to the vulnerable kernel code storing the inclusive range size in a type that cannot represent 65536, the range size becomes zero. The attacker then sends or causes traffic to traverse the affected traffic control rule. When the skbedit action processes a packet, tcf_skbedit_hash() attempts to compute skb_get_hash(skb) modulo the zero value, triggering a kernel divide-by-zero fault. Depending on kernel configuration and runtime behavior, this may produce an oops, panic the system, reset networking, or otherwise degrade service availability.

How to fix it

Upgrade affected Linux kernels to a version that includes the upstream fix for net/sched act_skbedit hash queue selection. No exact vendor package versions were provided, so use the relevant distribution or appliance advisory to identify the fixed kernel build for each supported platform. Where immediate patching is not possible, reduce exposure by restricting CAP_NET_ADMIN, disabling or tightly controlling unprivileged user namespaces where appropriate, preventing untrusted containers from receiving network administration capabilities, and auditing automation that creates tc skbedit actions. Avoid configurations that use skbedit hash-based transmit queue selection over the full 16-bit queue range. Mitigations should be treated as temporary because the durable fix is the corrected kernel logic that computes the mapping range in a wider type and rejects oversized ranges.

How to confirm the fix worked

Confirm exposure by checking whether systems run an affected Linux kernel build and whether the kernel contains the act_skbedit fix. Validate remediation by installing the vendor-fixed kernel, rebooting into it, and confirming the active kernel version with standard host inventory or uname output. Review tc configuration for skbedit actions that use hash-based transmit queue selection and unusually broad queue mapping ranges. In a controlled non-production test environment only, attempting to create the previously problematic full-range configuration should be rejected or should no longer result in a kernel divide-by-zero when traffic hits the action. Also confirm that untrusted users and containers cannot obtain CAP_NET_ADMIN unless explicitly required.

Typical attack path

  1. Obtain local shell, container access, or another execution context with permission to manage traffic control settings, usually CAP_NET_ADMIN in a network namespace.
  2. Create or modify a qdisc, filter, or action that uses skbedit with hash-based transmit queue selection.
  3. Set the queue mapping range to an edge-case inclusive range that causes the internal range size to be 65536, such as 0 through 65535.
  4. Generate or wait for network traffic that matches the configured traffic control rule.
  5. When a packet reaches the skbedit action, trigger the divide-by-zero condition in tcf_skbedit_hash().
  6. Cause a kernel oops, panic, host reboot, or networking disruption, resulting in denial of service.

How to detect it

To determine whether this was already exploited, review kernel logs, system journals, crash dumps, and audit logs around unexpected reboots, kernel oops events, or networking outages. Relevant log sources include journald, /var/log/kern.log, /var/log/messages, dmesg history, kdump/vmcore records, auditd, sudo logs, shell history for administrative accounts, container runtime audit events, and orchestration audit logs showing added Linux capabilities. Look for kernel exceptions mentioning divide error, tcf_skbedit_hash, act_skbedit, skbedit, or net/sched. Correlate those events with recent tc commands or netlink configuration activity that created skbedit actions with queue mapping ranges, especially ranges including 0 and 65535. Because this flaw primarily causes a crash rather than persistent compromise, durable artifacts may be limited to logs, crash dumps, and command/audit history. Absence of logs after a reboot does not fully rule out exploitation if volatile logs were lost.

  • divide error: 0000
  • divide error
  • tcf_skbedit_hash
  • act_skbedit
  • net/sched
  • skbedit
  • SKBEDIT_F_TXQ_SKBHASH
  • skb_get_hash
  • tc filter
  • tc action
  • skbedit queue_mapping
  • queue_mapping 0
  • queue_mapping_max 65535
  • 65535
  • CAP_NET_ADMIN
  • kernel panic
  • Oops: divide error
  • BUG: unable to handle kernel
  • /var/log/kern.log
  • /var/log/messages
  • /var/crash
  • /proc/vmcore

What your security team should do

  • Prioritize patching Linux systems where untrusted users, build jobs, containers, or tenants can obtain CAP_NET_ADMIN or otherwise manage traffic control.
  • Inventory kernels across Linux fleets and map them to vendor advisories for this fix, since fixed package versions vary by distribution.
  • Audit container runtimes, orchestration policies, and sudo rules for unnecessary CAP_NET_ADMIN grants.
  • Search for existing tc skbedit configurations using hash-based transmit queue selection and broad queue mapping ranges.
  • Monitor kernel logs for divide-by-zero, oops, panic, or call traces referencing tcf_skbedit_hash or act_skbedit.
  • Treat any unexplained crash on a multi-user or containerized Linux host with matching kernel log artifacts as potentially suspicious until configuration and user activity are reviewed.

The record

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash() Commit 38a6f0865796 ("net: sched: support hash selecting tx queue") added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is computed as: mapping_mod = queue_mapping_max - queue_mapping + 1; The range size can be 65536 when the requested range covers all possible u16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX). That value cannot be represented in a u16 and previously wrapped to 0, so tcf_skbedit_hash() could trigger a divide-by-zero: queue_mapping += skb_get_hash(skb) % params->mapping_mod; Compute mapping_mod in a wider type and reject ranges larger than U16_MAX to prevent params->mapping_mod from becoming 0 and avoid the crash.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities