CVE-2024-0641

What it actually does

Local process with user privileges can invoke tipc_crypto_key_revoke in the TIPC subsystem and induce a deadlock that leads to kernel panic or system crash.

Why it matters to the business

Guest virtual machines or containers sharing a host can be used to trigger repeated crashes, causing unplanned downtime and loss of service availability for workloads running on affected Linux kernels.

How an attack unfolds

An attacker with local access inside a guest obtains a user account, loads or exercises the TIPC module, and calls the vulnerable key-revoke path to create a deadlock condition that halts the kernel.

How to fix it

Update the Linux kernel to the commit 08e50cf071847323414df0835109b6f3560d44f5 or later; apply the vendor-supplied package that contains this fix and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel contains commit 08e50cf071847323414df0835109b6f3560d44f5 or a back-port that removes the deadlock condition; re-test the TIPC key-revoke path under load to verify absence of deadlock.

Typical attack path

1. Obtain local user privileges inside a guest or container on a host running an affected kernel
2. Ensure the TIPC subsystem is present and can be exercised
3. Trigger tipc_crypto_key_revoke with crafted parameters that induce the deadlock
4. Observe kernel panic or system reboot

How to detect it

Review kernel panic logs, dmesg output, and systemd journal entries around the time of unexpected reboots for TIPC crypto function stack traces; correlate with process execution of local users inside guests.

What your security team should do

• Prioritize patching of all systems exposing TIPC to untrusted local users within the next maintenance window
• Restrict TIPC module loading via kernel module blacklisting where the protocol is not required
• Monitor kernel crash logs for TIPC-related deadlocks until patches are deployed