[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aShmNNgam3bJ2yMO@horms.kernel.org>
Date: Thu, 27 Nov 2025 14:54:44 +0000
From: Simon Horman <horms@...nel.org>
To: ssrane_b23@...vjti.ac.in
Cc: "David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Felix Maurer <fmaurer@...hat.com>,
Jaakko Karrenpalo <jkarrenpalo@...il.com>,
Arvid Brodin <arvid.brodin@...en.se>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, skhan@...uxfoundation.org,
linux-kernel-mentees@...ts.linux.dev, david.hunter.linux@...il.com,
khalid@...nel.org,
syzbot+2fa344348a579b779e05@...kaller.appspotmail.com
Subject: Re: [PATCH] hsr: fix NULL pointer dereference in skb_clone with hw
tag insertion
On Wed, Nov 26, 2025 at 02:31:58AM +0530, ssrane_b23@...vjti.ac.in wrote:
> From: Shaurya Rane <ssrane_b23@...vjti.ac.in>
>
> When hardware HSR tag insertion is enabled (NETIF_F_HW_HSR_TAG_INS) and
> frame->skb_std is NULL, both hsr_create_tagged_frame() and
> prp_create_tagged_frame() will call skb_clone() with a NULL skb pointer,
> causing a kernel crash.
>
> Fix this by adding NULL checks for frame->skb_std before calling
> skb_clone() in the functions.
I think it would be worth including the trace reported by syzcaller here.
(Say, up to but not including the "Modules linked in" line.)
I can see it at the link. But maybe the link will go away some day.
>
> Reported-by: syzbot+2fa344348a579b779e05@...kaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=2fa344348a579b779e05
> Fixes: f266a683a480 ("net/hsr: Better frame dispatch")
> Signed-off-by: Shaurya Rane <ssrane_b23@...vjti.ac.in>
As a fix Networking code present in the net tree, this should be
targeted at the net tree. Like this.
[PATCH net] ...
> ---
> net/hsr/hsr_forward.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
> index 339f0d220212..4c1a311b900f 100644
> --- a/net/hsr/hsr_forward.c
> +++ b/net/hsr/hsr_forward.c
> @@ -211,6 +211,9 @@ struct sk_buff *prp_get_untagged_frame(struct hsr_frame_info *frame,
> __FILE__, __LINE__, port->dev->name);
> return NULL;
> }
> +
> + if (!frame->skb_std)
> + return NULL;
I think this can only occur if __pskb_copy() returns NULL.
So, for clarity, I think this condition should be moved to immediately
after the call to __pskb_copy().
> }
>
> return skb_clone(frame->skb_std, GFP_ATOMIC);
...
--
pw-bot: changes-requested
Powered by blists - more mailing lists