CVE-2023-28466

What it actually does

Missing lock_sock call in do_tls_getsockopt creates a race condition in the Linux kernel TLS implementation that can result in use-after-free or NULL pointer dereference.

Why it matters to the business

Local attackers may crash systems or escalate privileges on Linux servers and endpoints, disrupting operations and requiring urgent patching across large fleets.

How an attack unfolds

An attacker with local access triggers concurrent TLS socket operations to win the race in do_tls_getsockopt, corrupting kernel memory for denial of service or privilege escalation.

How to fix it

Upgrade the Linux kernel to a version containing commit afe5c8d2d3e75599abac25d9deda2735e3836ed4 or later equivalent fixes for all affected distributions.

How to confirm the fix worked

Verify the lock_sock call is present in do_tls_getsockopt in net/tls/tls_main.c after applying updates and confirm no TLS-related kernel oops occur under concurrent socket workloads.

Typical attack path

1. Obtain local user access on a vulnerable Linux system
2. Create or manipulate TLS sockets
3. Issue concurrent getsockopt calls to trigger the race
4. Leverage resulting use-after-free or NULL dereference for code execution or crash

How to detect it

Review kernel logs for oops or panic entries referencing tls_main.c or do_tls_getsockopt, and inspect system call traces for unusual concurrent TLS socket activity.

What your security team should do

• Apply kernel updates containing the referenced commit immediately on all Linux systems
• Limit untrusted local accounts and container workloads
• Monitor kernel logs for TLS subsystem crashes