CVE-2026-31711

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: server: fix active_num_conn leak on transport allocation failure<br /> <br /> Commit 77ffbcac4e56 ("smb: server: fix leak of active_num_conn in<br /> ksmbd_tcp_new_connection()") addressed the kthread_run() failure<br /> path. The earlier alloc_transport() == NULL path in the same<br /> function has the same leak, is reachable pre-authentication via any<br /> TCP connect to port 445, and was empirically reproduced on UML<br /> (ARCH=um, v7.0-rc7): a small number of forced allocation failures<br /> were sufficient to put ksmbd into a state where every subsequent<br /> connection attempt was rejected for the remainder of the boot.<br /> <br /> ksmbd_kthread_fn() increments active_num_conn before calling<br /> ksmbd_tcp_new_connection() and discards the return value, so when<br /> alloc_transport() returns NULL the socket is released and -ENOMEM<br /> returned without decrementing the counter. Each such failure<br /> permanently consumes one slot from the max_connections pool; once<br /> cumulative failures reach the cap, atomic_inc_return() hits the<br /> threshold on every subsequent accept and every new connection is<br /> rejected. The counter is only reset by module reload.<br /> <br /> An unauthenticated remote attacker can drive the server toward the<br /> memory pressure that makes alloc_transport() fail by holding open<br /> connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN<br /> (0x00FFFFFF); natural transient allocation failures on a loaded<br /> host produce the same drift more slowly.<br /> <br /> Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the<br /> alloc_transport() failure path, decrement active_num_conn gated on<br /> server_conf.max_connections.<br /> <br /> Repro details: with the patch reverted, forced alloc_transport()<br /> NULL returns leaked counter slots and subsequent connection<br /> attempts -- including legitimate connects issued after the<br /> forced-fail window had closed -- were all rejected with "Limit the<br /> maximum number of connections". With this patch applied, the same<br /> connect sequence produces no rejections and the counter cycles<br /> cleanly between zero and one on every accept.