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: <CADvbK_fsXE6MkgF9KMVThTgsid9Tgkyjrvwyek9NM1jd0KZ4Vg@mail.gmail.com>
Date: Thu, 5 Feb 2026 13:56:01 -0500
From: Xin Long <lucien.xin@...il.com>
To: Simon Horman <horms@...nel.org>
Cc: 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

On Thu, Feb 5, 2026 at 6:55 AM Simon Horman <horms@...nel.org> wrote:
>
> 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?
This is a good catch, will fix it.

Thanks.
>
> > +
> >       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));
>
> [ ... ]