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

[Simon Horman <horms@kernel.org>]

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
---
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?