Re: [PATCH net v7 1/1] llc: fix listener child socket leaks before passive open completes

[Simon Horman <horms@kernel.org>]

On Sun, Sep 06, 2026 at 11:11:49AM +0100, Simon Horman 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.
> Full review at: https://sashiko.dev/#/patchset/0b8964c9cd294898c9657fd34c9d04cec77782eb.1788414881.git.zihanx@nebusec.ai?part=1

Sorry, I've made mistake here.

I think the issue flagged below is actually out of scope wrt the
progress of your patch.

What I meant to forward was a separate AI-generated review at
https://netdev-ai.bots.linux.dev/sashiko/#/patchset/0b8964c9cd294898c9657fd34c9d04cec77782eb.1788414881.git.zihanx%40nebusec.ai

I will do so in a separate email.

> ---
> llc: fix listener child socket leaks before passive open completes
> 
> This patch addresses a child socket leak in the LLC subsystem during passive
> opens. It ensures that children are only created for SABME commands, avoiding
> leaks caused by non-SABME frames that never complete the connection. It also
> improves teardown and lifecycle management for incoming child sockets.
> 
> > diff --git a/net/llc/llc_conn.c b/net/llc/llc_conn.c
> > index 260460d50f54c..092625e28b3bb 100644
> > --- a/net/llc/llc_conn.c
> > +++ b/net/llc/llc_conn.c
> > @@ -88,6 +89,13 @@ int llc_conn_state_process(struct sock *sk, struct sk_buff *skb)
> >  		 * skb->sk pointing to the newly created struct sock in
> >  		 * llc_conn_handler. -acme
> >  		 */
> > +		if (sk != skb->sk &&
> > +		    atomic_read(&llc_sk(skb->sk)->incoming_state) ==
> > +		    LLC_INCOMING_PENDING) {
> > +			sock_hold(skb->sk);
> > +			atomic_set(&llc_sk(skb->sk)->incoming_state,
> > +				   LLC_INCOMING_QUEUED);
> > +		}
> >  		skb_get(skb);
> >  		skb_queue_tail(&sk->sk_receive_queue, skb);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but is it possible for an attacker
> to exhaust kernel memory (OOM) via unbounded SABME flooding?
> 
> Looking at llc_conn_state_process(), the new connection skb is queued directly
> to the listener's sk_receive_queue without checking if the accept queue is
> full (for example, by checking sk_acceptq_is_full(sk)).
> 
> Because llc_conn_handler() allocates a new child socket for each SABME packet,
> could a flood of spoofed SABME frames from the local subnet cause this queue
> to grow without bound?