CVE-2024-58239

What it actually does

The flaw causes incorrect merging of TLS records during recv() when process_rx_list handles a non-DATA record and a subsequent record of the same type remains on the queue, bypassing the expected DATA record type check and leading to improper input validation in the kernel TLS layer.

Why it matters to the business

Organizations running affected Linux kernel versions may experience unreliable secure network communications, increasing operational risk for services relying on TLS without immediate high-likelihood exploitation.

How an attack unfolds

An attacker sends a sequence of TLS records starting with a non-DATA record followed by another of matching type to trigger the record merging logic after process_rx_list completes, potentially resulting in malformed data handling within the kernel's TLS receive path.

How to fix it

Upgrade the Linux kernel to commit f310143961e2d9a0479fca117ce869f8aaecc140 or later. For Chainguard packages, update openjdk-11-openj9 and related variants to version 0.53.0-r0 or newer.

How to confirm the fix worked

Verify the running kernel contains commit f310143961e2d9a0479fca117ce869f8aaecc140 via git describe or package version checks; confirm Chainguard OpenJDK packages report version 0.53.0-r0 or above and test TLS recv behavior with mixed record types.

Typical attack path

1. Establish a TLS connection to a vulnerable system
2. Transmit a non-DATA TLS record to populate the rx_list
3. Send a follow-on record of the same type while it remains queued
4. Trigger recv() processing that merges the records without type validation

How to detect it

Review kernel TLS receive logs and network traces for anomalous record merging or unexpected non-DATA handling; correlate with process activity around TLS sockets on systems prior to the listed fixes.

What your security team should do

• Prioritize kernel updates on systems handling TLS traffic within standard change windows given low EPSS
• Audit Chainguard OpenJDK deployments for the listed packages and apply 0.53.0-r0 fixes
• Monitor EPSS trend for any increase beyond the current stable low value
• Include the fixed kernel commit in vulnerability scanning baselines