CVE-2024-35908

What it actually does

Reference leak on psock in tls_sw_recvmsg when tls_rx_reader_lock fails after the reference is acquired but before any release path executes.

Why it matters to the business

Linux kernel systems handling TLS traffic may experience gradual resource exhaustion, leading to degraded network performance or denial of service over sustained operation; the issue is not known to be under active exploitation.

How an attack unfolds

An attacker sends crafted TLS records that trigger repeated failures in rxlock acquisition during receive processing, causing the kernel to leak references without exhausting the reference count or triggering cleanup.

How to fix it

Upgrade the Linux kernel to the commit 30fabe50a7ace3e9d57cf7f9288f33ea408491c8 or later stable releases containing the fix; apply vendor kernel updates that reorder the reference acquisition after successful locking.

How to confirm the fix worked

Confirm the presence of commit 30fabe50a7ace3e9d57cf7f9288f33ea408491c8 in the kernel source tree or verify the patched order of psock reference and rxlock calls via code review or kernel build inspection.

Typical attack path

1. Establish a TLS connection to a vulnerable kernel endpoint
2. Send TLS records crafted to induce tls_rx_reader_lock failure in tls_sw_recvmsg
3. Repeat to accumulate unreleased psock references
4. Monitor for resource depletion or system instability

How to detect it

Examine kernel logs and memory accounting for anomalous psock reference growth during TLS receive operations; no public indicators of prior exploitation are known.

What your security team should do

• Prioritize kernel updates on systems exposing TLS endpoints
• Monitor upstream stable kernel releases for backports of the referenced commit
• Review TLS receive path usage in custom or embedded kernel configurations