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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.