netdev - Re: [net-next,v9,06/15] quic: add stream management

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260205115518.2195328-1-horms@kernel.org>
Date: Thu,  5 Feb 2026 11:55:18 +0000
From: Simon Horman <horms@...nel.org>
To: lucien.xin@...il.com
Cc: Simon Horman <horms@...nel.org>,
	steved@...hat.com,
	marcelo.leitner@...il.com,
	aahringo@...hat.com,
	alibuda@...ux.alibaba.com,
	jbaron@...mai.com,
	hare@...e.de,
	kuba@...nel.org,
	tom@...pey.com,
	linux-cifs@...r.kernel.org,
	daniel@...x.se,
	quic@...ts.linux.dev,
	jlayton@...nel.org,
	tfanelli@...hat.com,
	dhowells@...hat.com,
	linkinjeon@...nel.org,
	hepengtao@...omi.com,
	pc@...guebit.com,
	kernel-tls-handshake@...ts.linux.dev,
	illiliti@...tonmail.com,
	xiyou.wangcong@...il.com,
	andrew.gospodarek@...adcom.com,
	mail@...nericson.me,
	edumazet@...gle.com,
	pabeni@...hat.com,
	matttbe@...nel.org,
	netdev@...r.kernel.org,
	smfrench@...il.com,
	metze@...ba.org,
	mbuhl@...nbsd.org,
	chuck.lever@...cle.com,
	dreibh@...ula.no,
	davem@...emloft.net,
	sd@...asysnail.net
Subject: Re: [net-next,v9,06/15] quic: add stream management

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
quic: add stream management

This patch introduces stream management infrastructure for the QUIC
protocol, including a hash table for tracking active streams, functions
for acquiring and releasing streams, and logic for detecting stream
ID limits.

> diff --git a/net/quic/socket.c b/net/quic/socket.c
> index b86989080184..d6f25669c693 100644
> --- a/net/quic/socket.c
> +++ b/net/quic/socket.c
> @@ -41,6 +41,9 @@ static int quic_init_sock(struct sock *sk)
>  	sk->sk_write_space = quic_write_space;
>  	sock_set_flag(sk, SOCK_USE_WRITE_QUEUE);
>
> +	if (quic_stream_init(quic_streams(sk)))
> +		return -ENOMEM;

If quic_stream_init() fails here, the function returns before calling
sk_sockets_allocated_inc() and sock_prot_inuse_add() below. However,
when initialization fails, inet_create() calls sk_common_release() which
invokes quic_destroy_sock():

quic_init_sock()
    quic_stream_init() fails
    return -ENOMEM
        -> sk_common_release()
            -> quic_destroy_sock()
                -> sk_sockets_allocated_dec()  // underflow
                -> sock_prot_inuse_add(..., -1)  // underflow

Can this cause counter underflow since the increments never executed but
the decrements in quic_destroy_sock() are unconditional?

> +
>  	WRITE_ONCE(sk->sk_sndbuf, READ_ONCE(sysctl_quic_wmem[1]));
>  	WRITE_ONCE(sk->sk_rcvbuf, READ_ONCE(sysctl_quic_rmem[1]));
>
> @@ -52,6 +55,8 @@ static int quic_init_sock(struct sock *sk)
>
>  static void quic_destroy_sock(struct sock *sk)
>  {
> +	quic_stream_free(quic_streams(sk));
> +
>  	quic_data_free(quic_ticket(sk));

[ ... ]