From: Felix Maurer <fmaurer@redhat.com>
To: Shaurya Rane <ssrane_b23@ee.vjti.ac.in>
Cc: "David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Jaakko Karrenpalo <jkarrenpalo@gmail.com>,
Arvid Brodin <arvid.brodin@alten.se>,
skhan@linuxfoundation.org, linux-kernel-mentees@lists.linux.dev,
david.hunter.linux@gmail.com, khalid@kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+2fa344348a579b779e05@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH net v3] net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()
Date: Wed, 3 Dec 2025 14:52:39 +0100 [thread overview]
Message-ID: <aTBAp3axHXSkrYKO@thinkpad> (raw)
In-Reply-To: <20251129093718.25320-1-ssrane_b23@ee.vjti.ac.in>
On Sat, Nov 29, 2025 at 03:07:18PM +0530, Shaurya Rane wrote:
> prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_std
> but doesn't check if the allocation failed. If __pskb_copy() returns
> NULL, skb_clone() is called with a NULL pointer, causing a crash:
> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTI
> KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]
> CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041
> Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0c
> RSP: 0018:ffffc9000d00f200 EFLAGS: 00010207
> RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480
> RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000
> RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1ee
> R10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000
> R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00
> FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0
> Call Trace:
> <TASK>
> hsr_forward_do net/hsr/hsr_forward.c:-1 [inline]
> hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741
> hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84
> __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966
> __netif_receive_skb_one_core net/core/dev.c:6077 [inline]
> __netif_receive_skb+0x72/0x380 net/core/dev.c:6192
> netif_receive_skb_internal net/core/dev.c:6278 [inline]
> netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337
> tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485
> tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953
> tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999
> new_sync_write fs/read_write.c:593 [inline]
> vfs_write+0x5c9/0xb30 fs/read_write.c:686
> ksys_write+0x145/0x250 fs/read_write.c:738
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f0449f8e1ff
> Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48
> RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ff
> RDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8
> RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000
> R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001
> R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003
> </TASK>
> Add a NULL check immediately after __pskb_copy() to handle allocation
> failures gracefully.
Thank you, the fix looks good to me. Just a small nit pick (this can
probably be done when applying): please add the empty lines around the
trace again. Other than that:
Reviewed-by: Felix Maurer <fmaurer@redhat.com>
Tested-by: Felix Maurer <fmaurer@redhat.com>
> Reported-by: syzbot+2fa344348a579b779e05@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=2fa344348a579b779e05
> Fixes: f266a683a480 ("net/hsr: Better frame dispatch")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shaurya Rane <ssrane_b23@ee.vjti.ac.in>
> ---
> v3:
> - Keep only prp_get_untagged_frame() fix as the other two
> NETIF_F_HW_HSR_TAG_INS checks are not needed for this bug
> - Move NULL check immediately after __pskb_copy() call
>
> v2:
> - Add stack trace to commit message
> - Target net tree with [PATCH net]
> - Add Cc: stable@vger.kernel.org
> ---
> net/hsr/hsr_forward.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
> index 339f0d220212..aefc9b6936ba 100644
> --- a/net/hsr/hsr_forward.c
> +++ b/net/hsr/hsr_forward.c
> @@ -205,6 +205,8 @@ struct sk_buff *prp_get_untagged_frame(struct hsr_frame_info *frame,
> __pskb_copy(frame->skb_prp,
> skb_headroom(frame->skb_prp),
> GFP_ATOMIC);
> + if (!frame->skb_std)
> + return NULL;
> } else {
> /* Unexpected */
> WARN_ONCE(1, "%s:%d: Unexpected frame received (port_src %s)\n",
> --
> 2.34.1
>
next prev parent reply other threads:[~2025-12-03 13:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-29 9:37 [PATCH net v3] net/hsr: fix NULL pointer dereference in prp_get_untagged_frame() Shaurya Rane
2025-12-03 13:52 ` Felix Maurer [this message]
2025-12-04 10:14 ` Paolo Abeni
2025-12-04 10:20 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aTBAp3axHXSkrYKO@thinkpad \
--to=fmaurer@redhat.com \
--cc=arvid.brodin@alten.se \
--cc=davem@davemloft.net \
--cc=david.hunter.linux@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jkarrenpalo@gmail.com \
--cc=khalid@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=skhan@linuxfoundation.org \
--cc=ssrane_b23@ee.vjti.ac.in \
--cc=stable@vger.kernel.org \
--cc=syzbot+2fa344348a579b779e05@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).