netdev - Re: [PATCH net 1/2] net: hsr: Use the seqnr lock for frames received via interlink port.

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: <20240911174605.4ab21622@wsk>
Date: Wed, 11 Sep 2024 17:46:05 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: netdev@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 syzbot+3d602af7549af539274e@...kaller.appspotmail.com
Subject: Re: [PATCH net 1/2] net: hsr: Use the seqnr lock for frames
 received via interlink port.

Hi Sebastian Andrzej,

> syzbot reported that the seqnr_lock is not acquire for frames received
> over the interlink port. In the interlink case a new seqnr is
> generated and assigned to the frame.
> Frames, which are received over the slave port have already a sequence
> number assigned so the lock is not required.
> 
> Acquire the hsr_priv::seqnr_lock during in the invocation of
> hsr_forward_skb() if a packet has been received from the interlink
> port.
> 
> Reported-by: syzbot+3d602af7549af539274e@...kaller.appspotmail.com
> Closes:
> https://groups.google.com/g/syzkaller-bugs/c/KppVvGviGg4/m/EItSdCZdBAAJ
> Fixes: 5055cccfc2d1c ("net: hsr: Provide RedBox support (HSR-SAN)")
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de> ---
>  net/hsr/hsr_slave.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/net/hsr/hsr_slave.c b/net/hsr/hsr_slave.c
> index af6cf64a00e08..464f683e016db 100644
> --- a/net/hsr/hsr_slave.c
> +++ b/net/hsr/hsr_slave.c
> @@ -67,7 +67,16 @@ static rx_handler_result_t hsr_handle_frame(struct
> sk_buff **pskb) skb_set_network_header(skb, ETH_HLEN + HSR_HLEN);
>  	skb_reset_mac_len(skb);
>  
> -	hsr_forward_skb(skb, port);
> +	/* Only the frames received over the interlink port will
> assign a
> +	 * sequence number and require synchronisation vs other
> sender.
> +	 */
> +	if (port->type == HSR_PT_INTERLINK) {
> +		spin_lock_bh(&hsr->seqnr_lock);
> +		hsr_forward_skb(skb, port);
> +		spin_unlock_bh(&hsr->seqnr_lock);
> +	} else {
> +		hsr_forward_skb(skb, port);
> +	}
>  
>  finish_consume:
>  	return RX_HANDLER_CONSUMED;

I've run it through the QEMU + buildroot setup on net-next (SHA1:
bf73478b539b) and no regression was seen.

Thanks for preparing this patch :-)

Reviewed-by: Lukasz Majewski <lukma@...x.de>
Tested-by: Lukasz Majewski <lukma@...x.de>


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped