[PATCH net v2] 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().

Fixes: f87e62d45e51 ("net/tls: remove close callback sock unlock/lock around TX work flush")
Signed-off-by: Hyunwoo Kim <redacted>
---
Changes in v2:
- Shorten the patch subject
- Target the net tree
- Add the bug discovery background and the race scenario to the commit message
- v1: https://lore.kernel.org/all/aZLotq3aZY0b-dI8@v4bel/
---
 net/tls/tls_sw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 9937d4c810f2..b1fa62de9dab 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c

@@ -2533,7 +2533,7 @@ void tls_sw_cancel_work_tx(struct tls_context *tls_ctx)
 
 	set_bit(BIT_TX_CLOSING, &ctx->tx_bitmask);
 	set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask);
-	cancel_delayed_work_sync(&ctx->tx_work.work);
+	disable_delayed_work_sync(&ctx->tx_work.work);
 }
 
 void tls_sw_release_resources_tx(struct sock *sk)

-- 
2.43.0

On Fri, Feb 20, 2026 at 06:40:36PM +0900, Hyunwoo Kim wrote:

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().

Fixes: f87e62d45e51 ("net/tls: remove close callback sock unlock/lock around TX work flush")
Signed-off-by: Hyunwoo Kim <redacted>
---
Changes in v2:
- Shorten the patch subject
- Target the net tree
- Add the bug discovery background and the race scenario to the commit message
- v1: https://lore.kernel.org/all/aZLotq3aZY0b-dI8@v4bel/

Reviewed-by: Simon Horman <horms@kernel.org>

2026-02-20, 18:40:36 +0900, Hyunwoo Kim wrote:

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);

And possibly something similar with tls_encrypt_done() if async crypto
gets delayed by just the right amount.

This seems ok.
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>

It would maybe be a bit "cleaner" to reorder the operations in
tls_sk_proto_close() to first stop all async encryptions and switch
the CBs so that tls_write_space can't be called anymore, and then
cancel the tx_work (once we know nothing can reschedule it anymore),
but this should be fine.

 }
 
 void tls_sw_release_resources_tx(struct sock *sk)
-- 
2.43.0

-- 
Sabrina

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski [off-list ref]:

On Fri, 20 Feb 2026 18:40:36 +0900 you wrote:

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.

[...]

Here is the summary with links:
  - [net,v2] tls: Fix race condition in tls_sw_cancel_work_tx()
    https://git.kernel.org/netdev/net/c/7bb09315f93d

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

To prevent this race condition, cancel_delayed_work_sync() is 
replaced with disable_delayed_work_sync().

In lower stable kernel versions no such function as
disable_delayed_work_sync(). So could it be fixed by 
testing BIT_TX_CLOSING in tls_sw_write_space() before 
calling schedule_delayed_work() ?