Linux s390 Architecture development
 help / color / mirror / Atom feed
* [PATCH net] net/smc: fix TOCTOU race between smc_listen_out() and listener close
@ 2026-08-03  7:07 Sidraya Jayagond
  2026-08-03 12:54 ` Breno Leitao
  2026-08-04  7:07 ` sashiko-bot
  0 siblings, 2 replies; 5+ messages in thread
From: Sidraya Jayagond @ 2026-08-03  7:07 UTC (permalink / raw)
  To: davem, edumazet, kuba, pabeni, alibuda, dust.li, horms, mjambigi
  Cc: tonylu, guwen, hidayath, pasic, netdev, linux-s390,
	Sidraya Jayagond

smc_listen_out() reads lsmc->sk.sk_state without the listener lock,
then acquires lock_sock_nested() only after the check passes. This
opens a window where smc_close_active() can transition the listener
to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept
queue, and release the lock, all between the lockless read and the
delayed lock acquisition:

  smc_listen_work (smc_hs_wq)          smc_close_active()
  -------------------------------      -------------------------
  release_sock(child)
  if (sk_state == SMC_LISTEN) TRUE
                                        lock_sock(listener)
                                        sk_state = SMC_CLOSED
                                        smc_close_cleanup_listen()
                                        release_sock(listener)
                                        flush_work(tcp_listen_work)
  lock_sock_nested(listener)
  smc_accept_enqueue(listener, child) /* child enqueued on dead listener */

smc_close_active() flushes only tcp_listen_work. Work items already
dispatched onto smc_hs_wq for the CLC handshake continue running
unguarded. smc_accept_enqueue() takes a sock_hold() on the child that
is never released, so the child smc_sock, its clcsock, and the
reference all leak. A remote peer that opens TCP connections while the
server calls close() can exhaust kernel memory.

Move lock_sock_nested() to before the sk_state check so that the test
and the enqueue are atomic under the listener lock.

Fixes: fd57770dd198 ("net/smc: wait for pending work before clcsock release_sock")
Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Sidraya Jayagond <sidraya@linux.ibm.com>
---
 net/smc/af_smc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index b5db69073e20..00403175b740 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1931,11 +1931,12 @@ static void smc_listen_out(struct smc_sock *new_smc)
 		atomic_dec(&lsmc->queued_smc_hs);
 
 	release_sock(newsmcsk); /* lock in smc_listen_work() */
+	lock_sock_nested(&lsmc->sk, SINGLE_DEPTH_NESTING);
 	if (lsmc->sk.sk_state == SMC_LISTEN) {
-		lock_sock_nested(&lsmc->sk, SINGLE_DEPTH_NESTING);
 		smc_accept_enqueue(&lsmc->sk, newsmcsk);
 		release_sock(&lsmc->sk);
 	} else { /* no longer listening */
+		release_sock(&lsmc->sk);
 		smc_close_non_accepted(newsmcsk);
 	}
 
-- 
2.53.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH net] net/smc: fix TOCTOU race between smc_listen_out() and listener close
  2026-08-03  7:07 [PATCH net] net/smc: fix TOCTOU race between smc_listen_out() and listener close Sidraya Jayagond
@ 2026-08-03 12:54 ` Breno Leitao
  2026-08-04  7:22   ` Sidraya Jayagond
  2026-08-04  7:07 ` sashiko-bot
  1 sibling, 1 reply; 5+ messages in thread
From: Breno Leitao @ 2026-08-03 12:54 UTC (permalink / raw)
  To: Sidraya Jayagond
  Cc: davem, edumazet, kuba, pabeni, alibuda, dust.li, horms, mjambigi,
	tonylu, guwen, hidayath, pasic, netdev, linux-s390

> @@ -1931,11 +1931,12 @@ static void smc_listen_out(struct smc_sock *new_smc)
>  		atomic_dec(&lsmc->queued_smc_hs);
>  
>  	release_sock(newsmcsk); /* lock in smc_listen_work() */
> +	lock_sock_nested(&lsmc->sk, SINGLE_DEPTH_NESTING);
>  	if (lsmc->sk.sk_state == SMC_LISTEN) {
> -		lock_sock_nested(&lsmc->sk, SINGLE_DEPTH_NESTING);
>  		smc_accept_enqueue(&lsmc->sk, newsmcsk);
>  		release_sock(&lsmc->sk);
>  	} else { /* no longer listening */
> +		release_sock(&lsmc->sk);
>  		smc_close_non_accepted(newsmcsk);
>  	}

Do you need to call smc_close_non_accepted() without the lock? otherwise
you can have the lock around the whole if/else clause.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net] net/smc: fix TOCTOU race between smc_listen_out() and listener close
  2026-08-03  7:07 [PATCH net] net/smc: fix TOCTOU race between smc_listen_out() and listener close Sidraya Jayagond
  2026-08-03 12:54 ` Breno Leitao
@ 2026-08-04  7:07 ` sashiko-bot
  1 sibling, 0 replies; 5+ messages in thread
From: sashiko-bot @ 2026-08-04  7:07 UTC (permalink / raw)
  To: Sidraya Jayagond
  Cc: Alexander Gordeev, Vasily Gorbik, linux-s390, Heiko Carstens

> smc_listen_out() reads lsmc->sk.sk_state without the listener lock,
> then acquires lock_sock_nested() only after the check passes. This
> opens a window where smc_close_active() can transition the listener
> to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept
> queue, and release the lock, all between the lockless read and the
> delayed lock acquisition:
> 
>   smc_listen_work (smc_hs_wq)          smc_close_active()
>   -------------------------------      -------------------------
>   release_sock(child)
>   if (sk_state == SMC_LISTEN) TRUE
>                                         lock_sock(listener)
>                                         sk_state = SMC_CLOSED
>                                         smc_close_cleanup_listen()
>                                         release_sock(listener)
> [ ... ]
> and the enqueue are atomic under the listener lock.
> 
> Fixes: fd57770dd198 ("net/smc: wait for pending work before clcsock release_sock")
> Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
> Signed-off-by: Sidraya Jayagond <sidraya@linux.ibm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260803070701.126339-1-sidraya@linux.ibm.com?part=1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net] net/smc: fix TOCTOU race between smc_listen_out() and listener close
  2026-08-03 12:54 ` Breno Leitao
@ 2026-08-04  7:22   ` Sidraya Jayagond
  2026-08-04  8:02     ` Breno Leitao
  0 siblings, 1 reply; 5+ messages in thread
From: Sidraya Jayagond @ 2026-08-04  7:22 UTC (permalink / raw)
  To: Breno Leitao
  Cc: davem, edumazet, kuba, pabeni, alibuda, dust.li, horms, mjambigi,
	tonylu, guwen, hidayath, pasic, netdev, linux-s390



On 03/08/26 6:24 pm, Breno Leitao wrote:
>> @@ -1931,11 +1931,12 @@ static void smc_listen_out(struct smc_sock *new_smc)
>>  		atomic_dec(&lsmc->queued_smc_hs);
>>  
>>  	release_sock(newsmcsk); /* lock in smc_listen_work() */
>> +	lock_sock_nested(&lsmc->sk, SINGLE_DEPTH_NESTING);
>>  	if (lsmc->sk.sk_state == SMC_LISTEN) {
>> -		lock_sock_nested(&lsmc->sk, SINGLE_DEPTH_NESTING);
>>  		smc_accept_enqueue(&lsmc->sk, newsmcsk);
>>  		release_sock(&lsmc->sk);
>>  	} else { /* no longer listening */
>> +		release_sock(&lsmc->sk);
>>  		smc_close_non_accepted(newsmcsk);
>>  	}
> 
> Do you need to call smc_close_non_accepted() without the lock? otherwise
> you can have the lock around the whole if/else clause.

Yes, smc_close_non_accepted() calls __smc_release() in turn calls
smc_close_active(), which in the SMC_ACTIVE case hits
smc_close_stream_wait() a blocking wait that can sleep up to
SMC_MAX_STREAM_WAIT_TIMEOUT (2 minutes). Holding the listener lock
across that would stall any concurrent smc_accept(), smc_listen_out(),
or smc_release() on the listener for the same duration.

The release_sock() is intentionally placed before
smc_close_non_accepted() to keep the critical section minimal:
lock
  check state
    enqueue or not
      unlock
        then do the slow close work without the listener lock held.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net] net/smc: fix TOCTOU race between smc_listen_out() and listener close
  2026-08-04  7:22   ` Sidraya Jayagond
@ 2026-08-04  8:02     ` Breno Leitao
  0 siblings, 0 replies; 5+ messages in thread
From: Breno Leitao @ 2026-08-04  8:02 UTC (permalink / raw)
  To: Sidraya Jayagond
  Cc: davem, edumazet, kuba, pabeni, alibuda, dust.li, horms, mjambigi,
	tonylu, guwen, hidayath, pasic, netdev, linux-s390

On Tue, Aug 04, 2026 at 12:52:12PM +0530, Sidraya Jayagond wrote:
> 
> 
> On 03/08/26 6:24 pm, Breno Leitao wrote:
> >> @@ -1931,11 +1931,12 @@ static void smc_listen_out(struct smc_sock *new_smc)
> >>  		atomic_dec(&lsmc->queued_smc_hs);
> >>  
> >>  	release_sock(newsmcsk); /* lock in smc_listen_work() */
> >> +	lock_sock_nested(&lsmc->sk, SINGLE_DEPTH_NESTING);
> >>  	if (lsmc->sk.sk_state == SMC_LISTEN) {
> >> -		lock_sock_nested(&lsmc->sk, SINGLE_DEPTH_NESTING);
> >>  		smc_accept_enqueue(&lsmc->sk, newsmcsk);
> >>  		release_sock(&lsmc->sk);
> >>  	} else { /* no longer listening */
> >> +		release_sock(&lsmc->sk);
> >>  		smc_close_non_accepted(newsmcsk);
> >>  	}
> > 
> > Do you need to call smc_close_non_accepted() without the lock? otherwise
> > you can have the lock around the whole if/else clause.
> 
> Yes, smc_close_non_accepted() calls __smc_release() in turn calls
> smc_close_active(), which in the SMC_ACTIVE case hits
> smc_close_stream_wait() a blocking wait that can sleep up to
> SMC_MAX_STREAM_WAIT_TIMEOUT (2 minutes). Holding the listener lock
> across that would stall any concurrent smc_accept(), smc_listen_out(),
> or smc_release() on the listener for the same duration.
> 
> The release_sock() is intentionally placed before
> smc_close_non_accepted() to keep the critical section minimal:
> lock
>   check state
>     enqueue or not
>       unlock
>         then do the slow close work without the listener lock held.

That makes sense.

Reviewed-by: Breno Leitao <leitao@debian.org>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-08-04  8:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-03  7:07 [PATCH net] net/smc: fix TOCTOU race between smc_listen_out() and listener close Sidraya Jayagond
2026-08-03 12:54 ` Breno Leitao
2026-08-04  7:22   ` Sidraya Jayagond
2026-08-04  8:02     ` Breno Leitao
2026-08-04  7:07 ` sashiko-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox