CVE-2026-31711

In the Linux kernel, the following vulnerability has been resolved:

smb: server: fix active_num_conn leak on transport allocation failure

Commit 77ffbcac4e56 ("smb: server: fix leak of active_num_conn in

ksmbd_tcp_new_connection()") addressed the kthread_run() failure

path. The earlier alloc_transport() == NULL path in the same

function has the same leak, is reachable pre-authentication via any

TCP connect to port 445, and was empirically reproduced on UML

(ARCH=um, v7.0-rc7): a small number of forced allocation failures

were sufficient to put ksmbd into a state where every subsequent

connection attempt was rejected for the remainder of the boot.

ksmbd_kthread_fn() increments active_num_conn before calling

ksmbd_tcp_new_connection() and discards the return value, so when

alloc_transport() returns NULL the socket is released and -ENOMEM

returned without decrementing the counter. Each such failure

permanently consumes one slot from the max_connections pool; once

cumulative failures reach the cap, atomic_inc_return() hits the

threshold on every subsequent accept and every new connection is

rejected. The counter is only reset by module reload.

An unauthenticated remote attacker can drive the server toward the

memory pressure that makes alloc_transport() fail by holding open

connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN

(0x00FFFFFF); natural transient allocation failures on a loaded

host produce the same drift more slowly.

Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the

alloc_transport() failure path, decrement active_num_conn gated on

server_conf.max_connections.

Repro details: with the patch reverted, forced alloc_transport()

NULL returns leaked counter slots and subsequent connection

attempts -- including legitimate connects issued after the

forced-fail window had closed -- were all rejected with "Limit the

maximum number of connections". With this patch applied, the same

connect sequence produces no rejections and the counter cycles

cleanly between zero and one on every accept.