CVE-2026-23240
Received Received - Intake
Race Condition in Linux Kernel TLS Causes Use-After-Free

Publication date: 2026-03-10

Last updated on: 2026-04-02

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: tls: Fix race condition in tls_sw_cancel_work_tx() This issue was discovered during a code audit. After cancel_delayed_work_sync() is called from tls_sk_proto_close(), tx_work_handler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the tx_work_handler() worker may dereference a freed TLS object. The following is a simple race scenario: cpu0 cpu1 tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0); To prevent this race condition, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync().
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-10
Last Modified
2026-04-02
Generated
2026-05-07
AI Q&A
2026-03-10
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
linux_kernel linux_kernel *
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a race condition in the Linux kernel's TLS (Transport Layer Security) implementation, specifically in the function tls_sw_cancel_work_tx().

The issue occurs because after cancel_delayed_work_sync() is called from tls_sk_proto_close(), the tx_work_handler() can still be scheduled from other paths like the Delayed ACK handler or ksoftirqd. This means the tx_work_handler() worker might try to access (dereference) a TLS object that has already been freed.

A race scenario involves two CPUs where one CPU calls tls_sk_proto_close() and cancels the delayed work, while the other CPU schedules the delayed work again, leading to the unsafe access.

The fix replaces cancel_delayed_work_sync() with disable_delayed_work_sync() to prevent this race condition.


How can this vulnerability impact me? :

This vulnerability can lead to a use-after-free condition where the kernel's TLS worker thread accesses memory that has already been freed.

Such a condition can cause system instability, crashes, or potentially allow an attacker to execute arbitrary code or cause denial of service by exploiting the race condition.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by replacing cancel_delayed_work_sync() with disable_delayed_work_sync() in the Linux kernel's TLS code to prevent the race condition.

Therefore, the immediate mitigation step is to update your Linux kernel to a version that includes this fix.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart