CVE-2026-31711: smb: server: fix active_num_conn leak on transport allocation failure

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

smb: server: fix activenumconn leak on transport allocation failure

Commit 77ffbcac4e56 ("smb: server: fix leak of activenumconn in ksmbdtcpnewconnection()") addressed the kthreadrun() failure path. The earlier alloctransport() == 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.

ksmbdkthreadfn() increments activenumconn before calling ksmbdtcpnewconnection() and discards the return value, so when alloctransport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the maxconnections pool; once cumulative failures reach the cap, atomicincreturn() 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 alloctransport() fail by holding open connections with large RFC1002 lengths up to MAXSTREAMPROTLEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly.

Mirror the existing rollback pattern in ksmbdkthreadfn(): on the alloctransport() failure path, decrement activenumconn gated on serverconf.maxconnections.

Repro details: with the patch reverted, forced alloctransport() 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.