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().
Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
| Source | ID | Title |
|---|---|---|
Debian DSA |
DSA-6238-1 | linux security update |
Wed, 20 May 2026 19:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-362 | |
| CPEs | cpe:2.3:o:linux:linux_kernel:5.3:-:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.3:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.3:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.3:rc6:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.3:rc7:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:5.3:rc8:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:* |
Thu, 02 Apr 2026 15:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
cvssV3_1
|
cvssV3_1
|
Wed, 11 Mar 2026 12:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Tue, 10 Mar 2026 18:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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(). | |
| Title | tls: Fix race condition in tls_sw_cancel_work_tx() | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-05-11T22:03:02.082Z
Reserved: 2026-01-13T15:37:45.989Z
Link: CVE-2026-23240
No data.
Status : Analyzed
Published: 2026-03-10T18:18:13.533
Modified: 2026-05-20T19:30:38.810
Link: CVE-2026-23240
OpenCVE Enrichment
Updated: 2026-05-20T20:30:39Z
No weakness.
Debian DSA