Re: [PATCH net] net/smc: prevent NULL pointer dereference in txopt_get

Jeongjun Park
2024-08-13T04:06:50Z

[-- Attachment #1: Type: text/plain; charset=yes, Size: 3988 bytes --]

Jeongjun Park wrote:
>
> Since smc_inet6_prot does not initialize ipv6_pinfo_offset, inet6_create()
> copies an incorrect address value, sk + 0 (offset), to inet_sk(sk)->pinet6.
>
> In addition, since inet_sk(sk)->pinet6 and smc_sk(sk)->clcsock practically
> point to the same address, when smc_create_clcsk() stores the newly
> created clcsock in smc_sk(sk)->clcsock, inet_sk(sk)->pinet6 is corrupted
> into clcsock. This causes NULL pointer dereference and various other
> memory corruptions.
>
> To solve this, we need to add a smc6_sock structure for ipv6_pinfo_offset
> initialization and modify the smc_sock structure.
>
> [  278.629552][T28696] ==================================================================
> [  278.631367][T28696] BUG: KASAN: null-ptr-deref in txopt_get+0x102/0x430
> [  278.632724][T28696] Read of size 4 at addr 0000000000000200 by task syz.0.2965/28696
> [  278.634802][T28696]
> [  278.635236][T28696] CPU: 0 UID: 0 PID: 28696 Comm: syz.0.2965 Not tainted 6.11.0-rc2 #3
> [  278.637458][T28696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> [  278.639426][T28696] Call Trace:
> [  278.639833][T28696]  <TASK>
> [  278.640190][T28696]  dump_stack_lvl+0x116/0x1b0
> [  278.640844][T28696]  ? txopt_get+0x102/0x430
> [  278.641620][T28696]  kasan_report+0xbd/0xf0
> [  278.642440][T28696]  ? txopt_get+0x102/0x430
> [  278.643291][T28696]  kasan_check_range+0xf4/0x1a0
> [  278.644163][T28696]  txopt_get+0x102/0x430
> [  278.644940][T28696]  ? __pfx_txopt_get+0x10/0x10
> [  278.645877][T28696]  ? selinux_netlbl_socket_setsockopt+0x1d0/0x420
> [  278.646972][T28696]  calipso_sock_getattr+0xc6/0x3e0
> [  278.647630][T28696]  calipso_sock_getattr+0x4b/0x80
> [  278.648349][T28696]  netlbl_sock_getattr+0x63/0xc0
> [  278.649318][T28696]  selinux_netlbl_socket_setsockopt+0x1db/0x420
> [  278.650471][T28696]  ? __pfx_selinux_netlbl_socket_setsockopt+0x10/0x10
> [  278.652217][T28696]  ? find_held_lock+0x2d/0x120
> [  278.652231][T28696]  selinux_socket_setsockopt+0x66/0x90
> [  278.652247][T28696]  security_socket_setsockopt+0x57/0xb0
> [  278.652278][T28696]  do_sock_setsockopt+0xf2/0x480
> [  278.652289][T28696]  ? __pfx_do_sock_setsockopt+0x10/0x10
> [  278.652298][T28696]  ? __fget_files+0x24b/0x4a0
> [  278.652308][T28696]  ? __fget_light+0x177/0x210
> [  278.652316][T28696]  __sys_setsockopt+0x1a6/0x270
> [  278.652328][T28696]  ? __pfx___sys_setsockopt+0x10/0x10
> [  278.661787][T28696]  ? xfd_validate_state+0x5d/0x180
> [  278.662821][T28696]  __x64_sys_setsockopt+0xbd/0x160
> [  278.663719][T28696]  ? lockdep_hardirqs_on+0x7c/0x110
> [  278.664690][T28696]  do_syscall_64+0xcb/0x250
> [  278.665507][T28696]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> [  278.666618][T28696] RIP: 0033:0x7fe87ed9712d
> [  278.667236][T28696] Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> [  278.670801][T28696] RSP: 002b:00007fe87faa4fa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
> [  278.671832][T28696] RAX: ffffffffffffffda RBX: 00007fe87ef35f80 RCX: 00007fe87ed9712d
> [  278.672806][T28696] RDX: 0000000000000036 RSI: 0000000000000029 RDI: 0000000000000003
> [  278.674263][T28696] RBP: 00007fe87ee1bd8a R08: 0000000000000018 R09: 0000000000000000
> [  278.675967][T28696] R10: 0000000020000000 R11: 0000000000000246 R12: 0000000000000000
> [  278.677953][T28696] R13: 000000000000000b R14: 00007fe87ef35f80 R15: 00007fe87fa85000
> [  278.679321][T28696]  </TASK>
> [  278.679917][T28696] ==================================================================
>

Reported-by: syzbot+f69bfae0a4eb29976e44@syzkaller.appspotmail.com
Tested-by: syzbot+f69bfae0a4eb29976e44@syzkaller.appspotmail.com

I think the root cause of this syzbot report and the above bug report is the same.