CVE-2026-68313

What it actually does

A netlink compat dump callback returning a negative errno is not checked, allowing the while(len) loop in __tipc_nl_compat_dumpit to spin indefinitely, permanently holding genl_mutex and starving other tasks into D state.

Why it matters to the business

Local or remote users with netlink access can trigger a kernel-level denial of service that freezes TIPC-related operations and can render the system unresponsive until reboot.

How an attack unfolds

An attacker sends a crafted netlink message that reaches the TIPC compat dump handler; the handler's dumpit routine returns an error, the unchecked negative return keeps the loop condition true, genl_mutex is never released, and other kernel tasks block indefinitely.

How to fix it

Apply the upstream fix that adds an error check on the dumpit return value and jumps to err_out on failure; update to a Linux kernel release containing the corrected __tipc_nl_compat_dumpit implementation.

How to confirm the fix worked

Confirm the running kernel source contains the error-check patch; attempt to reproduce the loop with a failing dumpit callback and verify the loop now terminates and releases the mutex.

Typical attack path

1. Obtain local or netlink socket access on a system using TIPC
2. Craft and transmit a netlink TIPC command that invokes __tipc_nl_compat_dumpit
3. Trigger the error path in the dumpit callback
4. Observe mutex starvation and D-state processes across the system

How to detect it

Review kernel logs for repeated TIPC netlink entries without completion, look for processes stuck in D state while holding genl_mutex, and correlate with netlink socket activity on TIPC families.

What your security team should do

• Prioritize kernel updates on any system exposing TIPC netlink interfaces
• Restrict unprivileged netlink access via LSM or netlink policy until patched
• Monitor for TIPC-related D-state processes as a temporary detection signal