netdev - Re: [PATCH net] af_packet: fix vlan_get_tci() vs MSG

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: <6773cdaf3f67d_534e22943e@willemb.c.googlers.com.notmuch>
Date: Tue, 31 Dec 2024 05:55:43 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Eric Dumazet <edumazet@...gle.com>, 
 "David S . Miller" <davem@...emloft.net>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, 
 Simon Horman <horms@...nel.org>, 
 Willem de Bruijn <willemb@...gle.com>, 
 eric.dumazet@...il.com, 
 Eric Dumazet <edumazet@...gle.com>, 
 syzbot+8400677f3fd43f37d3bc@...kaller.appspotmail.com, 
 Chengen Du <chengen.du@...onical.com>
Subject: Re: [PATCH net] af_packet: fix vlan_get_tci() vs MSG_PEEK

Eric Dumazet wrote:
> Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found
> by syzbot.
> 
> Rework vlan_get_tci() to not touch skb at all,
> so that it can be used from many cpus on the same skb.
> 
> Add a const qualifier to skb argument.
> 
> [1]
> skbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:<NULL>
> ------------[ cut here ]------------
>  kernel BUG at net/core/skbuff.c:206 !
> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
> CPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
>  RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]
>  RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216
> Code: 0b 8d 48 c7 c6 9e 6c 26 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 3a 5a 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
> RSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286
> RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000
> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
> RBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50
> R10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140
> R13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014
> FS:  00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>   skb_push+0xe5/0x100 net/core/skbuff.c:2636
>   vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565
>   packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616
>   sock_recvmsg_nosec net/socket.c:1044 [inline]
>   sock_recvmsg+0x22f/0x280 net/socket.c:1066
>   ____sys_recvmsg+0x1c6/0x480 net/socket.c:2814
>   ___sys_recvmsg net/socket.c:2856 [inline]
>   do_recvmmsg+0x426/0xab0 net/socket.c:2951
>   __sys_recvmmsg net/socket.c:3025 [inline]
>   __do_sys_recvmmsg net/socket.c:3048 [inline]
>   __se_sys_recvmmsg net/socket.c:3041 [inline]
>   __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> 
> Fixes: 79eecf631c14 ("af_packet: Handle outgoing VLAN packets without hardware offloading")
> Reported-by: syzbot+8400677f3fd43f37d3bc@...kaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/6772c485.050a0220.2f3838.04c6.GAE@google.com/T/#u
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Cc: Chengen Du <chengen.du@...onical.com>
> Cc: Willem de Bruijn <willemb@...gle.com>

Reviewed-by: Willem de Bruijn <willemb@...gle.com>