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@xxxxxxxxxxxxxxxxxxxxxxxxx Tested-by: syzbot+f69bfae0a4eb29976e44@xxxxxxxxxxxxxxxxxxxxxxxxx I think the root cause of this syzbot report and the above bug report is the same.
