CVE-2025-38018

What it actually does

Kernel NULL pointer dereference in net/tls TLS strip receive path when alloc_page fails, leaving frag_list detached without resetting full_len so subsequent tls_strp_check_queue_ok and tls_strp_read_sock calls dereference invalid memory.

Why it matters to the business

Linux systems handling TLS traffic can experience sudden kernel panics and crashes, leading to unplanned downtime, loss of network sessions, and potential data corruption on servers or devices running affected kernels; the 496-day-old issue remains relevant given ongoing Linux kernel deployments and listed threat actor interest in kernel flaws.

How an attack unfolds

An attacker establishes a TLS connection and sends data under memory pressure so that alloc_page fails inside tls_strp_flush_anchor_copy; the missing full_len reset causes the receive path to dereference a NULL frag_list on the next tls_strp_data_ready call, triggering the panic. Threat actors associated with Linux kernel privilege-escalation campaigns may combine this with other kernel bugs for denial-of-service or further exploitation.

How to fix it

Upgrade the Linux kernel to a version containing commit 8f7f96549bc55e4ef3a6b499bc5011e5de2f46c4 or later; for Mageia 5 systems apply the mediawiki package update 1.23.11-1.mga5 or newer equivalent kernel packages; prioritize patching on systems with TLS offload enabled.

How to confirm the fix worked

Confirm kernel version contains commit 8f7f96549bc55e4ef3a6b499bc5011e5de2f46c4; reproduce the panic scenario under memory pressure and verify absence of the NULL dereference in tls_strp_check_rcv; monitor for stable TLS receive behavior without oops.

Typical attack path

1. Establish TLS session over TCP
2. Induce memory pressure on the target system
3. Send TLS record that triggers alloc_page failure in tls_strp code
4. Trigger subsequent data_ready path to dereference detached frag_list
5. Cause kernel NULL pointer dereference and panic

How to detect it

Search kernel logs and dmesg for the call trace containing tls_strp_check_rcv, tls_strp_data_ready, tls_data_ready and the NULL pointer dereference at address 0000000000000028; correlate with TLS connection establishment under memory pressure; review threat actor TTPs involving Linux kernel privilege escalation for related artifacts.

• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
• Call trace: tls_strp_check_rcv+0x128/0x27c
• tls_strp_data_ready+0x34/0x44
• tls_data_ready+0x3c/0x1f0
• tcp_data_ready+0x9c/0xe4

What your security team should do

• Apply the referenced kernel commit or distribution update immediately on all exposed systems
• Monitor EPSS trend and threat actor activity for similar kernel memory issues
• Test TLS workloads under memory-constrained conditions after patching
• Review kernel logs for prior tls_strp NULL dereference signatures