CVE-2026-43411

What it actually does

This is a local denial-of-service flaw in the Linux kernel TIPC socket implementation. A locally authenticated user can set the TIPC connection timeout to a value from 0 to 3 using TIPC_CONN_TIMEOUT; when a rejected TIPC SYN follows the overload retry path, the kernel calculates a modulo using tsk->conn_timeout / 4, which becomes zero and triggers a divide-by-zero exception. The result is a kernel oops and, depending on system configuration such as panic_on_oops and workload state, a full kernel panic or reboot. The impact is availability loss only; the vulnerability does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

A low-privileged local user or compromised local workload could crash affected Linux systems where TIPC is available, causing service interruption, node reboot, workload eviction, or cluster instability. The risk is highest on multi-user servers, shared compute platforms, container hosts, CI/CD runners, and systems that expose or enable TIPC functionality. The CVSS score is moderate, EPSS is currently very low, it is not listed in CISA KEV, and no exploit maturity is reported, but local denial-of-service bugs in the kernel can still be operationally disruptive when abused by an insider, malicious tenant, or post-compromise attacker.

How an attack unfolds

An attacker first obtains the ability to run code as a low-privileged local user on an affected Linux system. They create or use a TIPC socket and set the TIPC_CONN_TIMEOUT socket option to a value less than 4. They then initiate a TIPC connection attempt in a way that causes the kernel to process a rejected SYN with TIPC_ERR_OVERLOAD and enter the retry logic in tipc_sk_filter_connect(). In vulnerable kernels, the retry delay calculation divides the attacker-controlled timeout by 4, producing zero, and then performs a modulo operation by zero. This raises a CPU divide error in kernel context, producing a kernel oops and potentially a panic or reboot. The practical attacker objective is to disrupt availability rather than to gain additional privileges.

How to fix it

Apply the vendor-provided Linux kernel update that includes the TIPC fix which clamps conn_timeout to a minimum of 4 in tipc_sk_filter_connect(). If a fixed kernel package is not yet available for the deployed distribution, reduce exposure by disabling TIPC where it is not required. For modular kernels, unload the tipc module if safe and prevent future loading using module blacklist or install rules such as blacklisting tipc or mapping install tipc to /bin/false according to distribution policy. For systems where TIPC is built in or required, restrict local code execution, limit untrusted shell access, and use container/seccomp or workload sandboxing policies to block AF_TIPC socket creation where feasible. Do not rely on panic_on_oops settings as a primary mitigation; they may change reboot behavior but do not remove the kernel fault.

How to confirm the fix worked

Confirm the running kernel includes the upstream or distribution backport for the TIPC conn_timeout clamp. Validate by checking the installed kernel package changelog or advisory for the TIPC divide-by-zero fix and ensuring the system has rebooted into the updated kernel, not merely installed it. Check whether TIPC is present or loaded using commands such as lsmod | grep '^tipc', modinfo tipc, and kernel configuration indicators for CONFIG_TIPC. If TIPC is not required, verify it cannot be loaded after reboot and that AF_TIPC socket creation is blocked or unavailable to untrusted workloads. Avoid validating with a live proof-of-concept on production systems because successful reproduction can crash the host.

Typical attack path

1. Gain local code execution as any low-privileged user or through a compromised local workload/container with access to TIPC socket creation.
2. Create a TIPC socket and configure TIPC_CONN_TIMEOUT to 0, 1, 2, or 3.
3. Trigger a TIPC connect path that receives or processes a TIPC_ERR_OVERLOAD SYN rejection.
4. Cause tipc_sk_filter_connect() or nearby TIPC receive/filter logic to execute the vulnerable delay calculation.
5. Kernel raises a divide-by-zero exception, resulting in an oops, panic, reboot, or service interruption.

How to detect it

Look for evidence of prior exploitation in kernel logs, crash dumps, system journals, and reboot records. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, kdump/vmcore artifacts, crash utility output, audit logs, EDR process telemetry, and system reboot history. Indicators include kernel oops or panic messages showing a divide error in TIPC code paths, stack traces containing tipc_sk_filter_rcv, tipc_sk_filter_connect, tipc_sk_backlog_rcv, tipc_connect, release_sock, or net/tipc/socket.c, and crashes that coincide with local processes creating TIPC sockets or setting TIPC_CONN_TIMEOUT. If auditd or eBPF telemetry records socket activity, search for AF_TIPC socket creation by unexpected users, service accounts, build jobs, containers, or short-lived suspicious processes. Because public exploit maturity is not reported and there are no known named threat actors for this issue, prioritize correlation of TIPC-related kernel faults with local process execution and recent access events rather than network-only indicators.

• Oops: divide error
• kernel: Oops: divide error
• divide error: 0000
• RIP: 0010:tipc_sk_filter_rcv
• tipc_sk_filter_rcv
• tipc_sk_filter_connect
• tipc_sk_backlog_rcv
• tipc_connect
• net/tipc/socket.c
• TIPC_CONN_TIMEOUT
• TIPC_ERR_OVERLOAD
• Comm: poc-
• panic: Fatal exception

What your security team should do

• Prioritize patching affected Linux kernel versions on multi-user systems, container hosts, shared compute nodes, and any servers where local untrusted code can run.
• Inventory systems with TIPC enabled, loaded, or compiled into the kernel; treat those systems as higher exposure.
• Disable or blacklist the tipc kernel module wherever TIPC is not operationally required.
• Add detections for kernel oops or panic events referencing TIPC functions such as tipc_sk_filter_rcv, tipc_sk_filter_connect, tipc_sk_backlog_rcv, or divide error exceptions in net/tipc/socket.c.
• Review recent kernel logs for unexplained crashes, reboots, or divide errors involving TIPC, especially where they coincide with suspicious local user activity.
• Use sandboxing, seccomp, or container runtime controls to prevent untrusted workloads from creating AF_TIPC sockets where feasible.
• Because this is not currently KEV-listed and EPSS is low, schedule broadly according to normal kernel maintenance, but accelerate remediation for shared or externally managed compute environments.