CVE-2024-26583

What it actually does

Race condition between async TLS notification completion and socket close in the Linux kernel allows the submitting thread to exit and touch already-freed memory structures after crypto handler completion.

Why it matters to the business

Affected Linux systems may experience kernel crashes or instability during TLS network operations, leading to service disruptions, unplanned reboots, and operational downtime on servers and containers.

How an attack unfolds

A local attacker initiates TLS sendmsg/recvmsg operations to trigger async crypto handling, then closes the socket before the completion callback finishes; the main thread's exit allows use-after-free access to freed data without proper reference counting.

How to fix it

Upgrade the Linux kernel to the fixed commit f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7 or apply the equivalent stable patch; rebuild and reboot with the updated kernel image.

How to confirm the fix worked

Verify the running kernel contains commit f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7; reproduce concurrent TLS operations and socket closes under load to confirm absence of use-after-free crashes.

Typical attack path

1. Obtain local access on an affected Linux system
2. Perform TLS network operations via sendmsg or recvmsg
3. Trigger async crypto handler while concurrently closing the socket
4. Cause the kernel to dereference freed memory structures

How to detect it

Review dmesg and kernel logs for oops, panic, or use-after-free messages referencing ntls, async notify, or TLS socket close; correlate with processes performing concurrent TLS operations.

What your security team should do

• Apply the kernel fix immediately on systems handling TLS traffic
• Restrict untrusted local user access until patched
• Monitor kernel logs for TLS-related oops and panics
• Test patched kernels in staging before production rollout