[syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    fbdaffe41adc Merge branch 'am-qt2025-phy-rust'
git tree:       net-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=13d7c44d980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=996585887acdadb3
dashboard link: https://syzkaller.appspot.com/bug?extid=8811381d455e3e9ec788
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14b395db980000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16d3fc53980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/feaa1b13b490/disk-fbdaffe4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/8e5dccd0377a/vmlinux-fbdaffe4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/75151f74f4c9/bzImage-fbdaffe4.xz

Bisection is inconclusive: the first bad commit could be any of:

06ab21c3cb6e dt-bindings: net: mediatek,net: add top-level constraints
70d16e13368c dt-bindings: net: renesas,etheravb: add top-level constraints

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=11d42e63980000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8811381d455e3e9ec788@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959
Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235

CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959
 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640
 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778
 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996
 sock_recvmsg_nosec net/socket.c:1046 [inline]
 sock_recvmsg+0x22f/0x280 net/socket.c:1068
 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816
 ___sys_recvmsg net/socket.c:2858 [inline]
 __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5360d6b4e9
Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9
RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003
RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001
 </TASK>

Allocated by task 5235:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 unpoison_slab_object mm/kasan/common.c:312 [inline]
 __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
 kasan_slab_alloc include/linux/kasan.h:201 [inline]
 slab_post_alloc_hook mm/slub.c:3988 [inline]
 slab_alloc_node mm/slub.c:4037 [inline]
 kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080
 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667
 alloc_skb include/linux/skbuff.h:1320 [inline]
 alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528
 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815
 sock_alloc_send_skb include/net/sock.h:1778 [inline]
 queue_oob+0x108/0x680 net/unix/af_unix.c:2198
 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x221/0x270 net/socket.c:745
 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
 ___sys_sendmsg net/socket.c:2651 [inline]
 __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 5235:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2252 [inline]
 slab_free mm/slub.c:4473 [inline]
 kmem_cache_free+0x145/0x350 mm/slub.c:4548
 unix_stream_read_generic+0x1ef6/0x2520 net/unix/af_unix.c:2917
 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996
 sock_recvmsg_nosec net/socket.c:1046 [inline]
 sock_recvmsg+0x22f/0x280 net/socket.c:1068
 __sys_recvfrom+0x256/0x3e0 net/socket.c:2255
 __do_sys_recvfrom net/socket.c:2273 [inline]
 __se_sys_recvfrom net/socket.c:2269 [inline]
 __x64_sys_recvfrom+0xde/0x100 net/socket.c:2269
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff8880326abc80
 which belongs to the cache skbuff_head_cache of size 240
The buggy address is located 68 bytes inside of
 freed 240-byte region [ffff8880326abc80, ffff8880326abd70)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x326ab
ksm flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xfdffffff(slab)
raw: 00fff00000000000 ffff88801eaee780 ffffea0000b7dc80 dead000000000003
raw: 0000000000000000 00000000800c000c 00000001fdffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 4686, tgid 4686 (udevadm), ts 32357469485, free_ts 28829011109
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493
 prep_new_page mm/page_alloc.c:1501 [inline]
 get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439
 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695
 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
 alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
 alloc_slab_page+0x5f/0x120 mm/slub.c:2321
 allocate_slab+0x5a/0x2f0 mm/slub.c:2484
 new_slab mm/slub.c:2537 [inline]
 ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3723
 __slab_alloc+0x58/0xa0 mm/slub.c:3813
 __slab_alloc_node mm/slub.c:3866 [inline]
 slab_alloc_node mm/slub.c:4025 [inline]
 kmem_cache_alloc_node_noprof+0x1fe/0x320 mm/slub.c:4080
 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667
 alloc_skb include/linux/skbuff.h:1320 [inline]
 alloc_uevent_skb+0x74/0x230 lib/kobject_uevent.c:289
 uevent_net_broadcast_untagged lib/kobject_uevent.c:326 [inline]
 kobject_uevent_net_broadcast+0x2fd/0x580 lib/kobject_uevent.c:410
 kobject_uevent_env+0x57d/0x8e0 lib/kobject_uevent.c:608
 kobject_synth_uevent+0x4ef/0xae0 lib/kobject_uevent.c:207
 uevent_store+0x4b/0x70 drivers/base/bus.c:633
 kernfs_fop_write_iter+0x3a1/0x500 fs/kernfs/file.c:334
 new_sync_write fs/read_write.c:497 [inline]
 vfs_write+0xa72/0xc90 fs/read_write.c:590
page last free pid 1 tgid 1 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1094 [inline]
 free_unref_page+0xd22/0xea0 mm/page_alloc.c:2612
 kasan_depopulate_vmalloc_pte+0x74/0x90 mm/kasan/shadow.c:408
 apply_to_pte_range mm/memory.c:2797 [inline]
 apply_to_pmd_range mm/memory.c:2841 [inline]
 apply_to_pud_range mm/memory.c:2877 [inline]
 apply_to_p4d_range mm/memory.c:2913 [inline]
 __apply_to_page_range+0x8a8/0xe50 mm/memory.c:2947
 kasan_release_vmalloc+0x9a/0xb0 mm/kasan/shadow.c:525
 purge_vmap_node+0x3e3/0x770 mm/vmalloc.c:2208
 __purge_vmap_area_lazy+0x708/0xae0 mm/vmalloc.c:2290
 _vm_unmap_aliases+0x79d/0x840 mm/vmalloc.c:2885
 change_page_attr_set_clr+0x2fe/0xdb0 arch/x86/mm/pat/set_memory.c:1881
 change_page_attr_set arch/x86/mm/pat/set_memory.c:1922 [inline]
 set_memory_nx+0xf2/0x130 arch/x86/mm/pat/set_memory.c:2110
 free_init_pages arch/x86/mm/init.c:924 [inline]
 free_kernel_image_pages arch/x86/mm/init.c:943 [inline]
 free_initmem+0x79/0x110 arch/x86/mm/init.c:970
 kernel_init+0x31/0x2b0 init/main.c:1476
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Memory state around the buggy address:
 ffff8880326abb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8880326abc00: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
>ffff8880326abc80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                           ^
 ffff8880326abd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc
 ffff8880326abd80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Eric Dumazet]

On Wed, Sep 4, 2024 at 5:13 PM syzbot
<syzbot+8811381d455e3e9ec788@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    fbdaffe41adc Merge branch 'am-qt2025-phy-rust'
> git tree:       net-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=13d7c44d980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=996585887acdadb3
> dashboard link: https://syzkaller.appspot.com/bug?extid=8811381d455e3e9ec788
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14b395db980000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16d3fc53980000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/feaa1b13b490/disk-fbdaffe4.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/8e5dccd0377a/vmlinux-fbdaffe4.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/75151f74f4c9/bzImage-fbdaffe4.xz
>
> Bisection is inconclusive: the first bad commit could be any of:
>
> 06ab21c3cb6e dt-bindings: net: mediatek,net: add top-level constraints
> 70d16e13368c dt-bindings: net: renesas,etheravb: add top-level constraints
>
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=11d42e63980000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+8811381d455e3e9ec788@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959
> Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235
>
> CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:93 [inline]
>  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
>  print_address_description mm/kasan/report.c:377 [inline]
>  print_report+0x169/0x550 mm/kasan/report.c:488
>  kasan_report+0x143/0x180 mm/kasan/report.c:601
>  unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959
>  unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640
>  unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778
>  unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996
>  sock_recvmsg_nosec net/socket.c:1046 [inline]
>  sock_recvmsg+0x22f/0x280 net/socket.c:1068
>  ____sys_recvmsg+0x1db/0x470 net/socket.c:2816
>  ___sys_recvmsg net/socket.c:2858 [inline]
>  __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f5360d6b4e9
> Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 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 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
> RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9
> RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003
> RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
> R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001
>  </TASK>
>
> Allocated by task 5235:
>  kasan_save_stack mm/kasan/common.c:47 [inline]
>  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>  unpoison_slab_object mm/kasan/common.c:312 [inline]
>  __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
>  kasan_slab_alloc include/linux/kasan.h:201 [inline]
>  slab_post_alloc_hook mm/slub.c:3988 [inline]
>  slab_alloc_node mm/slub.c:4037 [inline]
>  kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080
>  __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667
>  alloc_skb include/linux/skbuff.h:1320 [inline]
>  alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528
>  sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815
>  sock_alloc_send_skb include/net/sock.h:1778 [inline]
>  queue_oob+0x108/0x680 net/unix/af_unix.c:2198
>  unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351
>  sock_sendmsg_nosec net/socket.c:730 [inline]
>  __sock_sendmsg+0x221/0x270 net/socket.c:745
>  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
>  ___sys_sendmsg net/socket.c:2651 [inline]
>  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Freed by task 5235:
>  kasan_save_stack mm/kasan/common.c:47 [inline]
>  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
>  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
>  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
>  kasan_slab_free include/linux/kasan.h:184 [inline]
>  slab_free_hook mm/slub.c:2252 [inline]
>  slab_free mm/slub.c:4473 [inline]
>  kmem_cache_free+0x145/0x350 mm/slub.c:4548
>  unix_stream_read_generic+0x1ef6/0x2520 net/unix/af_unix.c:2917
>  unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996
>  sock_recvmsg_nosec net/socket.c:1046 [inline]
>  sock_recvmsg+0x22f/0x280 net/socket.c:1068
>  __sys_recvfrom+0x256/0x3e0 net/socket.c:2255
>  __do_sys_recvfrom net/socket.c:2273 [inline]
>  __se_sys_recvfrom net/socket.c:2269 [inline]
>  __x64_sys_recvfrom+0xde/0x100 net/socket.c:2269
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> The buggy address belongs to the object at ffff8880326abc80
>  which belongs to the cache skbuff_head_cache of size 240
> The buggy address is located 68 bytes inside of
>  freed 240-byte region [ffff8880326abc80, ffff8880326abd70)
>
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x326ab
> ksm flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
> page_type: 0xfdffffff(slab)
> raw: 00fff00000000000 ffff88801eaee780 ffffea0000b7dc80 dead000000000003
> raw: 0000000000000000 00000000800c000c 00000001fdffffff 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 4686, tgid 4686 (udevadm), ts 32357469485, free_ts 28829011109
>  set_page_owner include/linux/page_owner.h:32 [inline]
>  post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493
>  prep_new_page mm/page_alloc.c:1501 [inline]
>  get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439
>  __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695
>  __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
>  alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
>  alloc_slab_page+0x5f/0x120 mm/slub.c:2321
>  allocate_slab+0x5a/0x2f0 mm/slub.c:2484
>  new_slab mm/slub.c:2537 [inline]
>  ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3723
>  __slab_alloc+0x58/0xa0 mm/slub.c:3813
>  __slab_alloc_node mm/slub.c:3866 [inline]
>  slab_alloc_node mm/slub.c:4025 [inline]
>  kmem_cache_alloc_node_noprof+0x1fe/0x320 mm/slub.c:4080
>  __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667
>  alloc_skb include/linux/skbuff.h:1320 [inline]
>  alloc_uevent_skb+0x74/0x230 lib/kobject_uevent.c:289
>  uevent_net_broadcast_untagged lib/kobject_uevent.c:326 [inline]
>  kobject_uevent_net_broadcast+0x2fd/0x580 lib/kobject_uevent.c:410
>  kobject_uevent_env+0x57d/0x8e0 lib/kobject_uevent.c:608
>  kobject_synth_uevent+0x4ef/0xae0 lib/kobject_uevent.c:207
>  uevent_store+0x4b/0x70 drivers/base/bus.c:633
>  kernfs_fop_write_iter+0x3a1/0x500 fs/kernfs/file.c:334
>  new_sync_write fs/read_write.c:497 [inline]
>  vfs_write+0xa72/0xc90 fs/read_write.c:590
> page last free pid 1 tgid 1 stack trace:
>  reset_page_owner include/linux/page_owner.h:25 [inline]
>  free_pages_prepare mm/page_alloc.c:1094 [inline]
>  free_unref_page+0xd22/0xea0 mm/page_alloc.c:2612
>  kasan_depopulate_vmalloc_pte+0x74/0x90 mm/kasan/shadow.c:408
>  apply_to_pte_range mm/memory.c:2797 [inline]
>  apply_to_pmd_range mm/memory.c:2841 [inline]
>  apply_to_pud_range mm/memory.c:2877 [inline]
>  apply_to_p4d_range mm/memory.c:2913 [inline]
>  __apply_to_page_range+0x8a8/0xe50 mm/memory.c:2947
>  kasan_release_vmalloc+0x9a/0xb0 mm/kasan/shadow.c:525
>  purge_vmap_node+0x3e3/0x770 mm/vmalloc.c:2208
>  __purge_vmap_area_lazy+0x708/0xae0 mm/vmalloc.c:2290
>  _vm_unmap_aliases+0x79d/0x840 mm/vmalloc.c:2885
>  change_page_attr_set_clr+0x2fe/0xdb0 arch/x86/mm/pat/set_memory.c:1881
>  change_page_attr_set arch/x86/mm/pat/set_memory.c:1922 [inline]
>  set_memory_nx+0xf2/0x130 arch/x86/mm/pat/set_memory.c:2110
>  free_init_pages arch/x86/mm/init.c:924 [inline]
>  free_kernel_image_pages arch/x86/mm/init.c:943 [inline]
>  free_initmem+0x79/0x110 arch/x86/mm/init.c:970
>  kernel_init+0x31/0x2b0 init/main.c:1476
>  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
>
> Memory state around the buggy address:
>  ffff8880326abb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff8880326abc00: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
> >ffff8880326abc80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                                            ^
>  ffff8880326abd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc
>  ffff8880326abd80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup


Another af_unix OOB issue.

Rao can you take a look ?

Thanks.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/4/2024 8:32 AM, Eric Dumazet wrote:
> On Wed, Sep 4, 2024 at 5:13 PM syzbot
> <syzbot+8811381d455e3e9ec788@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    fbdaffe41adc Merge branch 'am-qt2025-phy-rust'
>> git tree:       net-next
>> console+strace: https://urldefense.com/v3/__https://syzkaller.appspot.com/x/log.txt?x=13d7c44d980000__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCinyPp6_w$
>> kernel config:  https://urldefense.com/v3/__https://syzkaller.appspot.com/x/.config?x=996585887acdadb3__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChXq35SIA$
>> dashboard link: https://urldefense.com/v3/__https://syzkaller.appspot.com/bug?extid=8811381d455e3e9ec788__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCgeHsuB4Q$
>> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>> syz repro:      https://urldefense.com/v3/__https://syzkaller.appspot.com/x/repro.syz?x=14b395db980000__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChfSXV14A$
>> C reproducer:   https://urldefense.com/v3/__https://syzkaller.appspot.com/x/repro.c?x=16d3fc53980000__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChGWZhDug$
>>
>> Downloadable assets:
>> disk image: https://urldefense.com/v3/__https://storage.googleapis.com/syzbot-assets/feaa1b13b490/disk-fbdaffe4.raw.xz__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChjbj6XGw$
>> vmlinux: https://urldefense.com/v3/__https://storage.googleapis.com/syzbot-assets/8e5dccd0377a/vmlinux-fbdaffe4.xz__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChlarTUfA$
>> kernel image: https://urldefense.com/v3/__https://storage.googleapis.com/syzbot-assets/75151f74f4c9/bzImage-fbdaffe4.xz__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCgl9hRVww$
>>
>> Bisection is inconclusive: the first bad commit could be any of:
>>
>> 06ab21c3cb6e dt-bindings: net: mediatek,net: add top-level constraints
>> 70d16e13368c dt-bindings: net: renesas,etheravb: add top-level constraints
>>
>> bisection log:  https://urldefense.com/v3/__https://syzkaller.appspot.com/x/bisect.txt?x=11d42e63980000__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCjDvB9Flg$
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+8811381d455e3e9ec788@syzkaller.appspotmail.com
>>
>> ==================================================================
>> BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959
>> Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235
>>
>> CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
>> Call Trace:
>>   <TASK>
>>   __dump_stack lib/dump_stack.c:93 [inline]
>>   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
>>   print_address_description mm/kasan/report.c:377 [inline]
>>   print_report+0x169/0x550 mm/kasan/report.c:488
>>   kasan_report+0x143/0x180 mm/kasan/report.c:601
>>   unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959
>>   unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640
>>   unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778
>>   unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996
>>   sock_recvmsg_nosec net/socket.c:1046 [inline]
>>   sock_recvmsg+0x22f/0x280 net/socket.c:1068
>>   ____sys_recvmsg+0x1db/0x470 net/socket.c:2816
>>   ___sys_recvmsg net/socket.c:2858 [inline]
>>   __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888
>>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>>   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>> RIP: 0033:0x7f5360d6b4e9
>> Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 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 b8 ff ff ff f7 d8 64 89 01 48
>> RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
>> RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9
>> RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003
>> RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
>> R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001
>>   </TASK>
>>
>> Allocated by task 5235:
>>   kasan_save_stack mm/kasan/common.c:47 [inline]
>>   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>>   unpoison_slab_object mm/kasan/common.c:312 [inline]
>>   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
>>   kasan_slab_alloc include/linux/kasan.h:201 [inline]
>>   slab_post_alloc_hook mm/slub.c:3988 [inline]
>>   slab_alloc_node mm/slub.c:4037 [inline]
>>   kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080
>>   __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667
>>   alloc_skb include/linux/skbuff.h:1320 [inline]
>>   alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528
>>   sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815
>>   sock_alloc_send_skb include/net/sock.h:1778 [inline]
>>   queue_oob+0x108/0x680 net/unix/af_unix.c:2198
>>   unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351
>>   sock_sendmsg_nosec net/socket.c:730 [inline]
>>   __sock_sendmsg+0x221/0x270 net/socket.c:745
>>   ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
>>   ___sys_sendmsg net/socket.c:2651 [inline]
>>   __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
>>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>>   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>
>> Freed by task 5235:
>>   kasan_save_stack mm/kasan/common.c:47 [inline]
>>   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>>   kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
>>   poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
>>   __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
>>   kasan_slab_free include/linux/kasan.h:184 [inline]
>>   slab_free_hook mm/slub.c:2252 [inline]
>>   slab_free mm/slub.c:4473 [inline]
>>   kmem_cache_free+0x145/0x350 mm/slub.c:4548
>>   unix_stream_read_generic+0x1ef6/0x2520 net/unix/af_unix.c:2917
>>   unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996
>>   sock_recvmsg_nosec net/socket.c:1046 [inline]
>>   sock_recvmsg+0x22f/0x280 net/socket.c:1068
>>   __sys_recvfrom+0x256/0x3e0 net/socket.c:2255
>>   __do_sys_recvfrom net/socket.c:2273 [inline]
>>   __se_sys_recvfrom net/socket.c:2269 [inline]
>>   __x64_sys_recvfrom+0xde/0x100 net/socket.c:2269
>>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>>   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>
>> The buggy address belongs to the object at ffff8880326abc80
>>   which belongs to the cache skbuff_head_cache of size 240
>> The buggy address is located 68 bytes inside of
>>   freed 240-byte region [ffff8880326abc80, ffff8880326abd70)
>>
>> The buggy address belongs to the physical page:
>> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x326ab
>> ksm flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
>> page_type: 0xfdffffff(slab)
>> raw: 00fff00000000000 ffff88801eaee780 ffffea0000b7dc80 dead000000000003
>> raw: 0000000000000000 00000000800c000c 00000001fdffffff 0000000000000000
>> page dumped because: kasan: bad access detected
>> page_owner tracks the page as allocated
>> page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 4686, tgid 4686 (udevadm), ts 32357469485, free_ts 28829011109
>>   set_page_owner include/linux/page_owner.h:32 [inline]
>>   post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493
>>   prep_new_page mm/page_alloc.c:1501 [inline]
>>   get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439
>>   __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695
>>   __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
>>   alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
>>   alloc_slab_page+0x5f/0x120 mm/slub.c:2321
>>   allocate_slab+0x5a/0x2f0 mm/slub.c:2484
>>   new_slab mm/slub.c:2537 [inline]
>>   ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3723
>>   __slab_alloc+0x58/0xa0 mm/slub.c:3813
>>   __slab_alloc_node mm/slub.c:3866 [inline]
>>   slab_alloc_node mm/slub.c:4025 [inline]
>>   kmem_cache_alloc_node_noprof+0x1fe/0x320 mm/slub.c:4080
>>   __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667
>>   alloc_skb include/linux/skbuff.h:1320 [inline]
>>   alloc_uevent_skb+0x74/0x230 lib/kobject_uevent.c:289
>>   uevent_net_broadcast_untagged lib/kobject_uevent.c:326 [inline]
>>   kobject_uevent_net_broadcast+0x2fd/0x580 lib/kobject_uevent.c:410
>>   kobject_uevent_env+0x57d/0x8e0 lib/kobject_uevent.c:608
>>   kobject_synth_uevent+0x4ef/0xae0 lib/kobject_uevent.c:207
>>   uevent_store+0x4b/0x70 drivers/base/bus.c:633
>>   kernfs_fop_write_iter+0x3a1/0x500 fs/kernfs/file.c:334
>>   new_sync_write fs/read_write.c:497 [inline]
>>   vfs_write+0xa72/0xc90 fs/read_write.c:590
>> page last free pid 1 tgid 1 stack trace:
>>   reset_page_owner include/linux/page_owner.h:25 [inline]
>>   free_pages_prepare mm/page_alloc.c:1094 [inline]
>>   free_unref_page+0xd22/0xea0 mm/page_alloc.c:2612
>>   kasan_depopulate_vmalloc_pte+0x74/0x90 mm/kasan/shadow.c:408
>>   apply_to_pte_range mm/memory.c:2797 [inline]
>>   apply_to_pmd_range mm/memory.c:2841 [inline]
>>   apply_to_pud_range mm/memory.c:2877 [inline]
>>   apply_to_p4d_range mm/memory.c:2913 [inline]
>>   __apply_to_page_range+0x8a8/0xe50 mm/memory.c:2947
>>   kasan_release_vmalloc+0x9a/0xb0 mm/kasan/shadow.c:525
>>   purge_vmap_node+0x3e3/0x770 mm/vmalloc.c:2208
>>   __purge_vmap_area_lazy+0x708/0xae0 mm/vmalloc.c:2290
>>   _vm_unmap_aliases+0x79d/0x840 mm/vmalloc.c:2885
>>   change_page_attr_set_clr+0x2fe/0xdb0 arch/x86/mm/pat/set_memory.c:1881
>>   change_page_attr_set arch/x86/mm/pat/set_memory.c:1922 [inline]
>>   set_memory_nx+0xf2/0x130 arch/x86/mm/pat/set_memory.c:2110
>>   free_init_pages arch/x86/mm/init.c:924 [inline]
>>   free_kernel_image_pages arch/x86/mm/init.c:943 [inline]
>>   free_initmem+0x79/0x110 arch/x86/mm/init.c:970
>>   kernel_init+0x31/0x2b0 init/main.c:1476
>>   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
>>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
>>
>> Memory state around the buggy address:
>>   ffff8880326abb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>   ffff8880326abc00: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
>>> ffff8880326abc80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>                                             ^
>>   ffff8880326abd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc
>>   ffff8880326abd80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
>> ==================================================================
>>
>>
>> ---
>> This report is generated by a bot. It may contain errors.
>> See https://urldefense.com/v3/__https://goo.gl/tpsmEJ__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCj0yiM5oA$  for more information about syzbot.
>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this issue. See:
>> https://urldefense.com/v3/__https://goo.gl/tpsmEJ*status__;Iw!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCglGrElYg$  for how to communicate with syzbot.
>> For information about bisection process see: https://urldefense.com/v3/__https://goo.gl/tpsmEJ*bisection__;Iw!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChS6eLfFw$
>>
>> If the report is already addressed, let syzbot know by replying with:
>> #syz fix: exact-commit-title
>>
>> If you want syzbot to run the reproducer, reply with:
>> #syz test: git://repo/address.git branch-or-commit-hash
>> If you attach or paste a git patch, syzbot will apply it before testing.
>>
>> If you want to overwrite report's subsystems, reply with:
>> #syz set subsystems: new-subsystem
>> (See the list of subsystem names on the web dashboard)
>>
>> If the report is a duplicate of another one, reply with:
>> #syz dup: exact-subject-of-another-report
>>
>> If you want to undo deduplication, reply with:
>> #syz undup
>
> Another af_unix OOB issue.
>
> Rao can you take a look ?
>
> Thanks.

Sure I will take a look.

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Lizhi Xu]

The sock queue oob twice, the first manage_oob (in unix_stream_read_generic) peek next skb only,
and the next skb is the oob skb, so if skb is oob skb we need use manage_oob dealwith it.

#syz test

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 0be0dcb07f7b..2821a8b5dea9 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2918,6 +2918,14 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
 
 		/* Mark read part of skb as used */
 		if (!(flags & MSG_PEEK)) {
+#if IS_ENABLED(CONFIG_AF_UNIX_OOB)
+			if (skb == u->oob_skb) {
+				skb = manage_oob(skb, sk, flags, copied);
+				if (!skb && copied) {
+					break;
+				}
+			}
+#endif
 			UNIXCB(skb).consumed += chunk;
 
 			sk_peek_offset_bwd(sk, chunk);

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

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

Tested on:

commit:         43b77244 Merge tag 'wireless-next-2024-09-04' of git:/..
git tree:       net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=137509eb980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=996585887acdadb3
dashboard link: https://syzkaller.appspot.com/bug?extid=8811381d455e3e9ec788
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=1196cfdb980000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Lizhi Xu <lizhi.xu@windriver.com>
Date: Thu, 5 Sep 2024 13:25:32 +0800
> The sock queue oob twice, the first manage_oob (in unix_stream_read_generic) peek next skb only,
> and the next skb is the oob skb, so if skb is oob skb we need use manage_oob dealwith it.

I think the correct fix should be like this.

The issue happens only when the head oob is consumed (!unix_skb_len(skb))
and the next skb is peeked.  Then, we can fallback to the else branch in
manage_oob().

#syz test

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index a1894019ebd5..9913a447b758 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2654,51 +2654,49 @@ static int unix_stream_recv_urg(struct unix_stream_read_state *state)
 static struct sk_buff *manage_oob(struct sk_buff *skb, struct sock *sk,
 				  int flags, int copied)
 {
+	struct sk_buff *consumed_skb = NULL;
+	struct sk_buff *unread_skb = NULL;
 	struct unix_sock *u = unix_sk(sk);
 
-	if (!unix_skb_len(skb)) {
-		struct sk_buff *unlinked_skb = NULL;
-
-		spin_lock(&sk->sk_receive_queue.lock);
+	spin_lock(&sk->sk_receive_queue.lock);
 
+	if (!unix_skb_len(skb)) {
 		if (copied && (!u->oob_skb || skb == u->oob_skb)) {
 			skb = NULL;
 		} else if (flags & MSG_PEEK) {
 			skb = skb_peek_next(skb, &sk->sk_receive_queue);
 		} else {
-			unlinked_skb = skb;
+			consumed_skb = skb;
 			skb = skb_peek_next(skb, &sk->sk_receive_queue);
-			__skb_unlink(unlinked_skb, &sk->sk_receive_queue);
+			__skb_unlink(consumed_skb, &sk->sk_receive_queue);
 		}
 
-		spin_unlock(&sk->sk_receive_queue.lock);
-
-		consume_skb(unlinked_skb);
-	} else {
-		struct sk_buff *unlinked_skb = NULL;
+		if (!u->oob_skb || skb != u->oob_skb)
+			goto unlock;
+	}
 
-		spin_lock(&sk->sk_receive_queue.lock);
+	if (skb == u->oob_skb) {
+		if (copied) {
+			skb = NULL;
+		} else if (!(flags & MSG_PEEK)) {
+			WRITE_ONCE(u->oob_skb, NULL);
 
-		if (skb == u->oob_skb) {
-			if (copied) {
-				skb = NULL;
-			} else if (!(flags & MSG_PEEK)) {
-				WRITE_ONCE(u->oob_skb, NULL);
-
-				if (!sock_flag(sk, SOCK_URGINLINE)) {
-					__skb_unlink(skb, &sk->sk_receive_queue);
-					unlinked_skb = skb;
-					skb = skb_peek(&sk->sk_receive_queue);
-				}
-			} else if (!sock_flag(sk, SOCK_URGINLINE)) {
-				skb = skb_peek_next(skb, &sk->sk_receive_queue);
+			if (!sock_flag(sk, SOCK_URGINLINE)) {
+				__skb_unlink(skb, &sk->sk_receive_queue);
+				unread_skb = skb;
+				skb = skb_peek(&sk->sk_receive_queue);
 			}
+		} else if (!sock_flag(sk, SOCK_URGINLINE)) {
+			skb = skb_peek_next(skb, &sk->sk_receive_queue);
 		}
+	}
 
-		spin_unlock(&sk->sk_receive_queue.lock);
+unlock:
+	spin_unlock(&sk->sk_receive_queue.lock);
+
+	consume_skb(consumed_skb);
+	kfree_skb(unread_skb);
 
-		kfree_skb(unlinked_skb);
-	}
 	return skb;
 }
 #endif

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/4/2024 10:32 AM, Shoaib Rao wrote:
>
> On 9/4/2024 8:32 AM, Eric Dumazet wrote:
>> On Wed, Sep 4, 2024 at 5:13 PM syzbot
>> <syzbot+8811381d455e3e9ec788@syzkaller.appspotmail.com> wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:    fbdaffe41adc Merge branch 'am-qt2025-phy-rust'
>>> git tree:       net-next
>>> console+strace: 
>>> https://urldefense.com/v3/__https://syzkaller.appspot.com/x/log.txt?x=13d7c44d980000__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCinyPp6_w$
>>> kernel config: 
>>> https://urldefense.com/v3/__https://syzkaller.appspot.com/x/.config?x=996585887acdadb3__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChXq35SIA$
>>> dashboard link: 
>>> https://urldefense.com/v3/__https://syzkaller.appspot.com/bug?extid=8811381d455e3e9ec788__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCgeHsuB4Q$
>>> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils 
>>> for Debian) 2.40
>>> syz repro: 
>>> https://urldefense.com/v3/__https://syzkaller.appspot.com/x/repro.syz?x=14b395db980000__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChfSXV14A$
>>> C reproducer: 
>>> https://urldefense.com/v3/__https://syzkaller.appspot.com/x/repro.c?x=16d3fc53980000__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChGWZhDug$
>>>
>>> Downloadable assets:
>>> disk image: 
>>> https://urldefense.com/v3/__https://storage.googleapis.com/syzbot-assets/feaa1b13b490/disk-fbdaffe4.raw.xz__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChjbj6XGw$
>>> vmlinux: 
>>> https://urldefense.com/v3/__https://storage.googleapis.com/syzbot-assets/8e5dccd0377a/vmlinux-fbdaffe4.xz__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChlarTUfA$
>>> kernel image: 
>>> https://urldefense.com/v3/__https://storage.googleapis.com/syzbot-assets/75151f74f4c9/bzImage-fbdaffe4.xz__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCgl9hRVww$
>>>
>>> Bisection is inconclusive: the first bad commit could be any of:
>>>
>>> 06ab21c3cb6e dt-bindings: net: mediatek,net: add top-level constraints
>>> 70d16e13368c dt-bindings: net: renesas,etheravb: add top-level 
>>> constraints
>>>
>>> bisection log: 
>>> https://urldefense.com/v3/__https://syzkaller.appspot.com/x/bisect.txt?x=11d42e63980000__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCjDvB9Flg$
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the 
>>> commit:
>>> Reported-by: syzbot+8811381d455e3e9ec788@syzkaller.appspotmail.com
>>>
>>> ==================================================================
>>> BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 
>>> net/unix/af_unix.c:2959
>>> Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235
>>>
>>> CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 
>>> 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, 
>>> BIOS Google 08/06/2024
>>> Call Trace:
>>>   <TASK>
>>>   __dump_stack lib/dump_stack.c:93 [inline]
>>>   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
>>>   print_address_description mm/kasan/report.c:377 [inline]
>>>   print_report+0x169/0x550 mm/kasan/report.c:488
>>>   kasan_report+0x143/0x180 mm/kasan/report.c:601
>>>   unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959
>>>   unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640
>>>   unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778
>>>   unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996
>>>   sock_recvmsg_nosec net/socket.c:1046 [inline]
>>>   sock_recvmsg+0x22f/0x280 net/socket.c:1068
>>>   ____sys_recvmsg+0x1db/0x470 net/socket.c:2816
>>>   ___sys_recvmsg net/socket.c:2858 [inline]
>>>   __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888
>>>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>>>   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>>>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>> RIP: 0033:0x7f5360d6b4e9
>>> Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 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 b8 ff ff ff f7 d8 64 89 01 48
>>> RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
>>> RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9
>>> RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003
>>> RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
>>> R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001
>>>   </TASK>
>>>
>>> Allocated by task 5235:
>>>   kasan_save_stack mm/kasan/common.c:47 [inline]
>>>   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>>>   unpoison_slab_object mm/kasan/common.c:312 [inline]
>>>   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
>>>   kasan_slab_alloc include/linux/kasan.h:201 [inline]
>>>   slab_post_alloc_hook mm/slub.c:3988 [inline]
>>>   slab_alloc_node mm/slub.c:4037 [inline]
>>>   kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080
>>>   __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667
>>>   alloc_skb include/linux/skbuff.h:1320 [inline]
>>>   alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528
>>>   sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815
>>>   sock_alloc_send_skb include/net/sock.h:1778 [inline]
>>>   queue_oob+0x108/0x680 net/unix/af_unix.c:2198
>>>   unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351
>>>   sock_sendmsg_nosec net/socket.c:730 [inline]
>>>   __sock_sendmsg+0x221/0x270 net/socket.c:745
>>>   ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
>>>   ___sys_sendmsg net/socket.c:2651 [inline]
>>>   __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
>>>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>>>   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>>>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>>
>>> Freed by task 5235:
>>>   kasan_save_stack mm/kasan/common.c:47 [inline]
>>>   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>>>   kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
>>>   poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
>>>   __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
>>>   kasan_slab_free include/linux/kasan.h:184 [inline]
>>>   slab_free_hook mm/slub.c:2252 [inline]
>>>   slab_free mm/slub.c:4473 [inline]
>>>   kmem_cache_free+0x145/0x350 mm/slub.c:4548
>>>   unix_stream_read_generic+0x1ef6/0x2520 net/unix/af_unix.c:2917
>>>   unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996
>>>   sock_recvmsg_nosec net/socket.c:1046 [inline]
>>>   sock_recvmsg+0x22f/0x280 net/socket.c:1068
>>>   __sys_recvfrom+0x256/0x3e0 net/socket.c:2255
>>>   __do_sys_recvfrom net/socket.c:2273 [inline]
>>>   __se_sys_recvfrom net/socket.c:2269 [inline]
>>>   __x64_sys_recvfrom+0xde/0x100 net/socket.c:2269
>>>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>>>   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>>>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>>
>>> The buggy address belongs to the object at ffff8880326abc80
>>>   which belongs to the cache skbuff_head_cache of size 240
>>> The buggy address is located 68 bytes inside of
>>>   freed 240-byte region [ffff8880326abc80, ffff8880326abd70)
>>>
>>> The buggy address belongs to the physical page:
>>> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 
>>> pfn:0x326ab
>>> ksm flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
>>> page_type: 0xfdffffff(slab)
>>> raw: 00fff00000000000 ffff88801eaee780 ffffea0000b7dc80 
>>> dead000000000003
>>> raw: 0000000000000000 00000000800c000c 00000001fdffffff 
>>> 0000000000000000
>>> page dumped because: kasan: bad access detected
>>> page_owner tracks the page as allocated
>>> page last allocated via order 0, migratetype Unmovable, gfp_mask 
>>> 0x52cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 4686, 
>>> tgid 4686 (udevadm), ts 32357469485, free_ts 28829011109
>>>   set_page_owner include/linux/page_owner.h:32 [inline]
>>>   post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493
>>>   prep_new_page mm/page_alloc.c:1501 [inline]
>>>   get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439
>>>   __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695
>>>   __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
>>>   alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
>>>   alloc_slab_page+0x5f/0x120 mm/slub.c:2321
>>>   allocate_slab+0x5a/0x2f0 mm/slub.c:2484
>>>   new_slab mm/slub.c:2537 [inline]
>>>   ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3723
>>>   __slab_alloc+0x58/0xa0 mm/slub.c:3813
>>>   __slab_alloc_node mm/slub.c:3866 [inline]
>>>   slab_alloc_node mm/slub.c:4025 [inline]
>>>   kmem_cache_alloc_node_noprof+0x1fe/0x320 mm/slub.c:4080
>>>   __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667
>>>   alloc_skb include/linux/skbuff.h:1320 [inline]
>>>   alloc_uevent_skb+0x74/0x230 lib/kobject_uevent.c:289
>>>   uevent_net_broadcast_untagged lib/kobject_uevent.c:326 [inline]
>>>   kobject_uevent_net_broadcast+0x2fd/0x580 lib/kobject_uevent.c:410
>>>   kobject_uevent_env+0x57d/0x8e0 lib/kobject_uevent.c:608
>>>   kobject_synth_uevent+0x4ef/0xae0 lib/kobject_uevent.c:207
>>>   uevent_store+0x4b/0x70 drivers/base/bus.c:633
>>>   kernfs_fop_write_iter+0x3a1/0x500 fs/kernfs/file.c:334
>>>   new_sync_write fs/read_write.c:497 [inline]
>>>   vfs_write+0xa72/0xc90 fs/read_write.c:590
>>> page last free pid 1 tgid 1 stack trace:
>>>   reset_page_owner include/linux/page_owner.h:25 [inline]
>>>   free_pages_prepare mm/page_alloc.c:1094 [inline]
>>>   free_unref_page+0xd22/0xea0 mm/page_alloc.c:2612
>>>   kasan_depopulate_vmalloc_pte+0x74/0x90 mm/kasan/shadow.c:408
>>>   apply_to_pte_range mm/memory.c:2797 [inline]
>>>   apply_to_pmd_range mm/memory.c:2841 [inline]
>>>   apply_to_pud_range mm/memory.c:2877 [inline]
>>>   apply_to_p4d_range mm/memory.c:2913 [inline]
>>>   __apply_to_page_range+0x8a8/0xe50 mm/memory.c:2947
>>>   kasan_release_vmalloc+0x9a/0xb0 mm/kasan/shadow.c:525
>>>   purge_vmap_node+0x3e3/0x770 mm/vmalloc.c:2208
>>>   __purge_vmap_area_lazy+0x708/0xae0 mm/vmalloc.c:2290
>>>   _vm_unmap_aliases+0x79d/0x840 mm/vmalloc.c:2885
>>>   change_page_attr_set_clr+0x2fe/0xdb0 
>>> arch/x86/mm/pat/set_memory.c:1881
>>>   change_page_attr_set arch/x86/mm/pat/set_memory.c:1922 [inline]
>>>   set_memory_nx+0xf2/0x130 arch/x86/mm/pat/set_memory.c:2110
>>>   free_init_pages arch/x86/mm/init.c:924 [inline]
>>>   free_kernel_image_pages arch/x86/mm/init.c:943 [inline]
>>>   free_initmem+0x79/0x110 arch/x86/mm/init.c:970
>>>   kernel_init+0x31/0x2b0 init/main.c:1476
>>>   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
>>>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
>>>
>>> Memory state around the buggy address:
>>>   ffff8880326abb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>>   ffff8880326abc00: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
>>>> ffff8880326abc80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>>                                             ^
>>>   ffff8880326abd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc
>>>   ffff8880326abd80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
>>> ==================================================================
>>>
>>>
>>> ---
>>> This report is generated by a bot. It may contain errors.
>>> See 
>>> https://urldefense.com/v3/__https://goo.gl/tpsmEJ__;!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCj0yiM5oA$ 
>>> for more information about syzbot.
>>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>>
>>> syzbot will keep track of this issue. See:
>>> https://urldefense.com/v3/__https://goo.gl/tpsmEJ*status__;Iw!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmCglGrElYg$ 
>>> for how to communicate with syzbot.
>>> For information about bisection process see: 
>>> https://urldefense.com/v3/__https://goo.gl/tpsmEJ*bisection__;Iw!!ACWV5N9M2RV99hQ!O_wYwGadsms5089A9E28Dxx6WaVGOgSJ31BkCSFGtWTEPW52si4mQ-gN_xDf6oRUivpWe5nrmChS6eLfFw$
>>>
>>> If the report is already addressed, let syzbot know by replying with:
>>> #syz fix: exact-commit-title
>>>
>>> If you want syzbot to run the reproducer, reply with:
>>> #syz test: git://repo/address.git branch-or-commit-hash
>>> If you attach or paste a git patch, syzbot will apply it before 
>>> testing.
>>>
>>> If you want to overwrite report's subsystems, reply with:
>>> #syz set subsystems: new-subsystem
>>> (See the list of subsystem names on the web dashboard)
>>>
>>> If the report is a duplicate of another one, reply with:
>>> #syz dup: exact-subject-of-another-report
>>>
>>> If you want to undo deduplication, reply with:
>>> #syz undup
>>
>> Another af_unix OOB issue.
>>
>> Rao can you take a look ?
>>
>> Thanks.
>
> Sure I will take a look.
>
> Shoaib
>
Hi All,

I am not able to reproduce the issue. I have run the C program at least 
100 times in a loop. In the I do get an EFAULT, not sure if that is 
intentional or not but no panic. Should I be doing something 
differently? The kernel version I am using is 
v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.

[rshoaib@turbo-2 debug_pnic]$ gcc cause_panic.c -o panic_sys
[rshoaib@turbo-2 debug_pnic]$ strace -f ./panic_sys
execve("./panic_sys", ["./panic_sys"], 0x7ffe7d271d38 /* 63 vars */) = 0
brk(NULL)                               = 0x18104000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffe134f7880) = -1 EINVAL (Invalid 
argument)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=94859, ...}) = 0
mmap(NULL, 94859, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7feb7dd0f000
close(3)                                = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\251\3\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2164792, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7feb7dd0d000
lseek(3, 808, SEEK_SET)                 = 808
read(3, 
"\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32) = 32
mmap(NULL, 4020448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 
0) = 0x7feb7d728000
mprotect(0x7feb7d8f5000, 2093056, PROT_NONE) = 0
mmap(0x7feb7daf4000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1cc000) = 0x7feb7daf4000
mmap(0x7feb7dafa000, 14560, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7feb7dafa000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7feb7dd0e500) = 0
mprotect(0x7feb7daf4000, 16384, PROT_READ) = 0
mprotect(0x600000, 4096, PROT_READ)     = 0
mprotect(0x7feb7dd2d000, 4096, PROT_READ) = 0
munmap(0x7feb7dd0f000, 94859)           = 0
mmap(0x1ffff000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x1ffff000
mmap(0x20000000, 16777216, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000
mmap(0x21000000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x21000000
write(1, "executing program\n", 18executing program
)     = 18
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", 
iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 
MSG_OOB|MSG_DONTWAIT) = 1
recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, 
msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", 
iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 
MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC, NULL, NULL) = 1
recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad 
address)     <======
exit_group(0)                           = ?
+++ exited with 0 +++

Regards,

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

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

Tested on:

commit:         43b77244 Merge tag 'wireless-next-2024-09-04' of git:/..
git tree:       net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1582bfdb980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=996585887acdadb3
dashboard link: https://syzkaller.appspot.com/bug?extid=8811381d455e3e9ec788
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=12d22d63980000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Eric Dumazet]

On Thu, Sep 5, 2024 at 9:35 AM Shoaib Rao <rao.shoaib@oracle.com> wrote:
>

> >
> Hi All,
>
> I am not able to reproduce the issue. I have run the C program at least
> 100 times in a loop. In the I do get an EFAULT, not sure if that is
> intentional or not but no panic. Should I be doing something
> differently? The kernel version I am using is
> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.


Have you selected ASAN in your kernel build ?

CONFIG_KASAN=y
CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX=y
CONFIG_KASAN_GENERIC=y
CONFIG_KASAN_INLINE=y
CONFIG_KASAN_STACK=y
CONFIG_KASAN_VMALLOC=y

>
> [rshoaib@turbo-2 debug_pnic]$ gcc cause_panic.c -o panic_sys
> [rshoaib@turbo-2 debug_pnic]$ strace -f ./panic_sys
> execve("./panic_sys", ["./panic_sys"], 0x7ffe7d271d38 /* 63 vars */) = 0
> brk(NULL)                               = 0x18104000

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/5/2024 1:04 AM, Eric Dumazet wrote:
> On Thu, Sep 5, 2024 at 9:35 AM Shoaib Rao <rao.shoaib@oracle.com> wrote:
>> Hi All,
>>
>> I am not able to reproduce the issue. I have run the C program at least
>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
>> intentional or not but no panic. Should I be doing something
>> differently? The kernel version I am using is
>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
>
> Have you selected ASAN in your kernel build ?
>
> CONFIG_KASAN=y
> CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX=y
> CONFIG_KASAN_GENERIC=y
> CONFIG_KASAN_INLINE=y
> CONFIG_KASAN_STACK=y
> CONFIG_KASAN_VMALLOC=y
>
>> [rshoaib@turbo-2 debug_pnic]$ gcc cause_panic.c -o panic_sys
>> [rshoaib@turbo-2 debug_pnic]$ strace -f ./panic_sys
>> execve("./panic_sys", ["./panic_sys"], 0x7ffe7d271d38 /* 63 vars */) = 0
>> brk(NULL)                               = 0x18104000

Hi Eric,

Yes. The config is

[rshoaib@turbo-2 ~]$ grep KASAN /boot/config-`uname -r`
++ uname -r
+ grep --color=auto KASAN /boot/config-6.11.0-rao-rc6-gc763c4339688-dirty
CONFIG_KASAN_SHADOW_OFFSET=0xdffffc0000000000
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_HAVE_ARCH_KASAN_VMALLOC=y
CONFIG_CC_HAS_KASAN_GENERIC=y
CONFIG_KASAN=y
CONFIG_KASAN_GENERIC=y
# CONFIG_KASAN_OUTLINE is not set
CONFIG_KASAN_INLINE=y
CONFIG_KASAN_STACK=y
CONFIG_KASAN_VMALLOC=y

The only config missing is

CONFIG_CC_HAS_KASAN_MEMINTRINSIC_PREFIX

I do not have that option.

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Thu, 5 Sep 2024 00:35:35 -0700
> Hi All,
> 
> I am not able to reproduce the issue. I have run the C program at least 
> 100 times in a loop. In the I do get an EFAULT, not sure if that is 
> intentional or not but no panic. Should I be doing something 
> differently? The kernel version I am using is 
> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.

The -EFAULT is the bug meaning that we were trying to read an consumed skb.

But the first bug is in recvfrom() that shouldn't be able to read OOB skb
without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
something bad happens.

  socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
  sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
  recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
  sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, NULL) = 1
  recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)

I posted a fix officially:
https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@oracle.com>
> Date: Thu, 5 Sep 2024 00:35:35 -0700
>> Hi All,
>>
>> I am not able to reproduce the issue. I have run the C program at least
>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
>> intentional or not but no panic. Should I be doing something
>> differently? The kernel version I am using is
>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
> The -EFAULT is the bug meaning that we were trying to read an consumed skb.
>
> But the first bug is in recvfrom() that shouldn't be able to read OOB skb
> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
> something bad happens.
>
>    socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
>    sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
>    recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
>    sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, NULL) = 1
>    recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)
>
> I posted a fix officially:
> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$

Thanks that is great. Isn't EFAULT,  normally indicative of an issue 
with the user provided address of the buffer, not the kernel buffer.

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Thu, 5 Sep 2024 13:15:18 -0700
> On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
> > From: Shoaib Rao <rao.shoaib@oracle.com>
> > Date: Thu, 5 Sep 2024 00:35:35 -0700
> >> Hi All,
> >>
> >> I am not able to reproduce the issue. I have run the C program at least
> >> 100 times in a loop. In the I do get an EFAULT, not sure if that is
> >> intentional or not but no panic. Should I be doing something
> >> differently? The kernel version I am using is
> >> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
> > The -EFAULT is the bug meaning that we were trying to read an consumed skb.
> >
> > But the first bug is in recvfrom() that shouldn't be able to read OOB skb
> > without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
> > something bad happens.
> >
> >    socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
> >    sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
> >    recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
> >    sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
> >> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, NULL) = 1
> >    recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)
> >
> > I posted a fix officially:
> > https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$
> 
> Thanks that is great. Isn't EFAULT,  normally indicative of an issue 
> with the user provided address of the buffer, not the kernel buffer.

Normally, it's used when copy_to_user() or copy_from_user() or
something similar failed.

But this time, if you turn KASAN off, you'll see the last recvmsg()
returns 1-byte garbage instead of -EFAULT, so actually KASAN worked
on your host, I guess.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/5/2024 1:15 PM, Shoaib Rao wrote:
>
> On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
>> From: Shoaib Rao <rao.shoaib@oracle.com>
>> Date: Thu, 5 Sep 2024 00:35:35 -0700
>>> Hi All,
>>>
>>> I am not able to reproduce the issue. I have run the C program at least
>>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
>>> intentional or not but no panic. Should I be doing something
>>> differently? The kernel version I am using is
>>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
>> The -EFAULT is the bug meaning that we were trying to read an 
>> consumed skb.
>>
>> But the first bug is in recvfrom() that shouldn't be able to read OOB 
>> skb
>> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
>> something bad happens.
>>
>>    socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
>>    sendmsg(4, {msg_name=NULL, msg_namelen=0, 
>> msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, 
>> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
>>    recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, 
>> msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, 
>> MSG_OOB|MSG_WAITFORONE) = 1
>>    sendmsg(4, {msg_name=NULL, msg_namelen=0, 
>> msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, 
>> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
>>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, 
>>> NULL) = 1
>>    recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad 
>> address)
>>
>> I posted a fix officially:
>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$ 
>>
>
> Thanks that is great. Isn't EFAULT,  normally indicative of an issue 
> with the user provided address of the buffer, not the kernel buffer.
>
> Shoaib
>
Can you provide the full test case that you used to reproduce the issue.

Thanks,

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/5/2024 1:37 PM, Shoaib Rao wrote:
>
> On 9/5/2024 1:15 PM, Shoaib Rao wrote:
>>
>> On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>> Date: Thu, 5 Sep 2024 00:35:35 -0700
>>>> Hi All,
>>>>
>>>> I am not able to reproduce the issue. I have run the C program at 
>>>> least
>>>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
>>>> intentional or not but no panic. Should I be doing something
>>>> differently? The kernel version I am using is
>>>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
>>> The -EFAULT is the bug meaning that we were trying to read an 
>>> consumed skb.
>>>
>>> But the first bug is in recvfrom() that shouldn't be able to read 
>>> OOB skb
>>> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
>>> something bad happens.
>>>
>>>    socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
>>>    sendmsg(4, {msg_name=NULL, msg_namelen=0, 
>>> msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, 
>>> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
>>>    recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, 
>>> msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, 
>>> MSG_OOB|MSG_WAITFORONE) = 1
>>>    sendmsg(4, {msg_name=NULL, msg_namelen=0, 
>>> msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, 
>>> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
>>>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, 
>>>> NULL) = 1
>>>    recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT 
>>> (Bad address)
>>>
>>> I posted a fix officially:
>>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$ 
>>>
>>
>> Thanks that is great. Isn't EFAULT,  normally indicative of an issue 
>> with the user provided address of the buffer, not the kernel buffer.
>>
>> Shoaib
>>
> Can you provide the full test case that you used to reproduce the issue.
>
> Thanks,
>
> Shoaib
>
>
 From the recvmsg man page


    Return Value

These calls return the number of bytes received, or -1 if an error 
occurred. The return value will be 0 when the peer has performed an 
orderly shutdown.

*EFAULT*

The receive buffer*pointer*(s) point outside the process's address space.

I still do not understand why if I had all the check on and the issue 
occured, why the kernel did not panic. Maybe, running the exact test 
case will help me understand.

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Thu, 5 Sep 2024 13:37:06 -0700
> On 9/5/2024 1:15 PM, Shoaib Rao wrote:
> >
> > On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
> >> From: Shoaib Rao <rao.shoaib@oracle.com>
> >> Date: Thu, 5 Sep 2024 00:35:35 -0700
> >>> Hi All,
> >>>
> >>> I am not able to reproduce the issue. I have run the C program at least
> >>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
> >>> intentional or not but no panic. Should I be doing something
> >>> differently? The kernel version I am using is
> >>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
> >> The -EFAULT is the bug meaning that we were trying to read an 
> >> consumed skb.
> >>
> >> But the first bug is in recvfrom() that shouldn't be able to read OOB 
> >> skb
> >> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
> >> something bad happens.
> >>
> >>    socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
> >>    sendmsg(4, {msg_name=NULL, msg_namelen=0, 
> >> msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, 
> >> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
> >>    recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, 
> >> msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, 
> >> MSG_OOB|MSG_WAITFORONE) = 1
> >>    sendmsg(4, {msg_name=NULL, msg_namelen=0, 
> >> msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, 
> >> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
> >>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, 
> >>> NULL) = 1
> >>    recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad 
> >> address)
> >>
> >> I posted a fix officially:
> >> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$ 
> >>
> >
> > Thanks that is great. Isn't EFAULT,  normally indicative of an issue 
> > with the user provided address of the buffer, not the kernel buffer.
> >
> > Shoaib
> >
> Can you provide the full test case that you used to reproduce the issue.

I used the syzbot's repro, but you can check a new test case added
in my patch.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/5/2024 1:35 PM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@oracle.com>
> Date: Thu, 5 Sep 2024 13:15:18 -0700
>> On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>> Date: Thu, 5 Sep 2024 00:35:35 -0700
>>>> Hi All,
>>>>
>>>> I am not able to reproduce the issue. I have run the C program at least
>>>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
>>>> intentional or not but no panic. Should I be doing something
>>>> differently? The kernel version I am using is
>>>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
>>> The -EFAULT is the bug meaning that we were trying to read an consumed skb.
>>>
>>> But the first bug is in recvfrom() that shouldn't be able to read OOB skb
>>> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
>>> something bad happens.
>>>
>>>     socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
>>>     sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
>>>     recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
>>>     sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
>>>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, NULL) = 1
>>>     recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)
>>>
>>> I posted a fix officially:
>>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$
>> Thanks that is great. Isn't EFAULT,  normally indicative of an issue
>> with the user provided address of the buffer, not the kernel buffer.
> Normally, it's used when copy_to_user() or copy_from_user() or
> something similar failed.
>
> But this time, if you turn KASAN off, you'll see the last recvmsg()
> returns 1-byte garbage instead of -EFAULT, so actually KASAN worked
> on your host, I guess.

No it did not work. As soon as KASAN detected read after free it should 
have paniced as it did in the report and I have been running the 
syzbot's C program in a continuous loop. I would like to reproduce the 
issue before we can accept the fix -- If that is alright with you. I 
will try your new test case later and report back. Thanks for the patch 
though.

Regards,

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Thu, 5 Sep 2024 13:48:16 -0700
> On 9/5/2024 1:35 PM, Kuniyuki Iwashima wrote:
> > From: Shoaib Rao <rao.shoaib@oracle.com>
> > Date: Thu, 5 Sep 2024 13:15:18 -0700
> >> On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
> >>> From: Shoaib Rao <rao.shoaib@oracle.com>
> >>> Date: Thu, 5 Sep 2024 00:35:35 -0700
> >>>> Hi All,
> >>>>
> >>>> I am not able to reproduce the issue. I have run the C program at least
> >>>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
> >>>> intentional or not but no panic. Should I be doing something
> >>>> differently? The kernel version I am using is
> >>>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
> >>> The -EFAULT is the bug meaning that we were trying to read an consumed skb.
> >>>
> >>> But the first bug is in recvfrom() that shouldn't be able to read OOB skb
> >>> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
> >>> something bad happens.
> >>>
> >>>     socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
> >>>     sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
> >>>     recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
> >>>     sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
> >>>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, NULL) = 1
> >>>     recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)
> >>>
> >>> I posted a fix officially:
> >>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$
> >> Thanks that is great. Isn't EFAULT,  normally indicative of an issue
> >> with the user provided address of the buffer, not the kernel buffer.
> > Normally, it's used when copy_to_user() or copy_from_user() or
> > something similar failed.
> >
> > But this time, if you turn KASAN off, you'll see the last recvmsg()
> > returns 1-byte garbage instead of -EFAULT, so actually KASAN worked
> > on your host, I guess.
> 
> No it did not work. As soon as KASAN detected read after free it should 
> have paniced as it did in the report and I have been running the 
> syzbot's C program in a continuous loop. I would like to reproduce the 
> issue before we can accept the fix -- If that is alright with you. I 
> will try your new test case later and report back. Thanks for the patch 
> though.

The splat is handy, you may want to check the returned value of recvfrom()
with KASAN on and off and then focus on the root cause.  When UAF happens,
the real bug always happens before that.

FWIW, I was able to see the splat on my setup and it disappeared with
my patch.  Also, syzbot has already tested the equivalent change.
https://lore.kernel.org/netdev/00000000000064fbcb06215a7bbc@google.com/

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Eric Dumazet]

On Thu, Sep 5, 2024 at 10:48 PM Shoaib Rao <rao.shoaib@oracle.com> wrote:
>
>
> On 9/5/2024 1:35 PM, Kuniyuki Iwashima wrote:
> > From: Shoaib Rao <rao.shoaib@oracle.com>
> > Date: Thu, 5 Sep 2024 13:15:18 -0700
> >> On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
> >>> From: Shoaib Rao <rao.shoaib@oracle.com>
> >>> Date: Thu, 5 Sep 2024 00:35:35 -0700
> >>>> Hi All,
> >>>>
> >>>> I am not able to reproduce the issue. I have run the C program at least
> >>>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
> >>>> intentional or not but no panic. Should I be doing something
> >>>> differently? The kernel version I am using is
> >>>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
> >>> The -EFAULT is the bug meaning that we were trying to read an consumed skb.
> >>>
> >>> But the first bug is in recvfrom() that shouldn't be able to read OOB skb
> >>> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
> >>> something bad happens.
> >>>
> >>>     socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
> >>>     sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
> >>>     recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
> >>>     sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
> >>>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, NULL) = 1
> >>>     recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)
> >>>
> >>> I posted a fix officially:
> >>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$
> >> Thanks that is great. Isn't EFAULT,  normally indicative of an issue
> >> with the user provided address of the buffer, not the kernel buffer.
> > Normally, it's used when copy_to_user() or copy_from_user() or
> > something similar failed.
> >
> > But this time, if you turn KASAN off, you'll see the last recvmsg()
> > returns 1-byte garbage instead of -EFAULT, so actually KASAN worked
> > on your host, I guess.
>
> No it did not work. As soon as KASAN detected read after free it should
> have paniced as it did in the report and I have been running the
> syzbot's C program in a continuous loop. I would like to reproduce the
> issue before we can accept the fix -- If that is alright with you. I
> will try your new test case later and report back. Thanks for the patch
> though.

KASAN does not panic unless you request it.

Documentation/dev-tools/kasan.rst

KASAN is affected by the generic ``panic_on_warn`` command line parameter.
When it is enabled, KASAN panics the kernel after printing a bug report.

By default, KASAN prints a bug report only for the first invalid memory access.
With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
effectively disables ``panic_on_warn`` for KASAN reports.

Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` boot
parameter can be used to control panic and reporting behaviour:

- ``kasan.fault=report``, ``=panic``, or ``=panic_on_write`` controls whether
  to only print a KASAN report, panic the kernel, or panic the kernel on
  invalid writes only (default: ``report``). The panic happens even if
  ``kasan_multi_shot`` is enabled. Note that when using asynchronous mode of
  Hardware Tag-Based KASAN, ``kasan.fault=panic_on_write`` always panics on
  asynchronously checked accesses (including reads).

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/6/2024 5:37 AM, Eric Dumazet wrote:
> On Thu, Sep 5, 2024 at 10:48 PM Shoaib Rao <rao.shoaib@oracle.com> wrote:
>>
>> On 9/5/2024 1:35 PM, Kuniyuki Iwashima wrote:
>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>> Date: Thu, 5 Sep 2024 13:15:18 -0700
>>>> On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
>>>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>>>> Date: Thu, 5 Sep 2024 00:35:35 -0700
>>>>>> Hi All,
>>>>>>
>>>>>> I am not able to reproduce the issue. I have run the C program at least
>>>>>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
>>>>>> intentional or not but no panic. Should I be doing something
>>>>>> differently? The kernel version I am using is
>>>>>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
>>>>> The -EFAULT is the bug meaning that we were trying to read an consumed skb.
>>>>>
>>>>> But the first bug is in recvfrom() that shouldn't be able to read OOB skb
>>>>> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
>>>>> something bad happens.
>>>>>
>>>>>      socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
>>>>>      sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
>>>>>      recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
>>>>>      sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
>>>>>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, NULL) = 1
>>>>>      recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)
>>>>>
>>>>> I posted a fix officially:
>>>>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$
>>>> Thanks that is great. Isn't EFAULT,  normally indicative of an issue
>>>> with the user provided address of the buffer, not the kernel buffer.
>>> Normally, it's used when copy_to_user() or copy_from_user() or
>>> something similar failed.
>>>
>>> But this time, if you turn KASAN off, you'll see the last recvmsg()
>>> returns 1-byte garbage instead of -EFAULT, so actually KASAN worked
>>> on your host, I guess.
>> No it did not work. As soon as KASAN detected read after free it should
>> have paniced as it did in the report and I have been running the
>> syzbot's C program in a continuous loop. I would like to reproduce the
>> issue before we can accept the fix -- If that is alright with you. I
>> will try your new test case later and report back. Thanks for the patch
>> though.
> KASAN does not panic unless you request it.
>
> Documentation/dev-tools/kasan.rst
>
> KASAN is affected by the generic ``panic_on_warn`` command line parameter.
> When it is enabled, KASAN panics the kernel after printing a bug report.
>
> By default, KASAN prints a bug report only for the first invalid memory access.
> With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
> effectively disables ``panic_on_warn`` for KASAN reports.
>
> Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` boot
> parameter can be used to control panic and reporting behaviour:
>
> - ``kasan.fault=report``, ``=panic``, or ``=panic_on_write`` controls whether
>    to only print a KASAN report, panic the kernel, or panic the kernel on
>    invalid writes only (default: ``report``). The panic happens even if
>    ``kasan_multi_shot`` is enabled. Note that when using asynchronous mode of
>    Hardware Tag-Based KASAN, ``kasan.fault=panic_on_write`` always panics on
>    asynchronously checked accesses (including reads).

Hi Eric,

Thanks for the update. I forgot to mention that I I did set 
/proc/sys/kernel/panic_on_warn to 1. I ran the program over night in two 
separate windows, there are no reports and no panic. I first try to 
reproduce the issue, because if I can not, how can I be sure that I have 
fixed that bug? I may find another issue and fix it but not the one that 
I was trying to. Please be assured that I am not done, I continue to 
investigate the issue.

If someone has a way of reproducing the failure please kindly let me know.

Kind regards,

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/6/2024 9:48 AM, Shoaib Rao wrote:
>
> On 9/6/2024 5:37 AM, Eric Dumazet wrote:
>> On Thu, Sep 5, 2024 at 10:48 PM Shoaib Rao <rao.shoaib@oracle.com> 
>> wrote:
>>>
>>> On 9/5/2024 1:35 PM, Kuniyuki Iwashima wrote:
>>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>>> Date: Thu, 5 Sep 2024 13:15:18 -0700
>>>>> On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
>>>>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>>>>> Date: Thu, 5 Sep 2024 00:35:35 -0700
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I am not able to reproduce the issue. I have run the C program 
>>>>>>> at least
>>>>>>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
>>>>>>> intentional or not but no panic. Should I be doing something
>>>>>>> differently? The kernel version I am using is
>>>>>>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
>>>>>> The -EFAULT is the bug meaning that we were trying to read an 
>>>>>> consumed skb.
>>>>>>
>>>>>> But the first bug is in recvfrom() that shouldn't be able to read 
>>>>>> OOB skb
>>>>>> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
>>>>>> something bad happens.
>>>>>>
>>>>>>      socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
>>>>>>      sendmsg(4, {msg_name=NULL, msg_namelen=0, 
>>>>>> msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, 
>>>>>> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
>>>>>>      recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, 
>>>>>> msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, 
>>>>>> MSG_OOB|MSG_WAITFORONE) = 1
>>>>>>      sendmsg(4, {msg_name=NULL, msg_namelen=0, 
>>>>>> msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, 
>>>>>> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
>>>>>>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, 
>>>>>>> NULL, NULL) = 1
>>>>>>      recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 
>>>>>> EFAULT (Bad address)
>>>>>>
>>>>>> I posted a fix officially:
>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$ 
>>>>>>
>>>>> Thanks that is great. Isn't EFAULT,  normally indicative of an issue
>>>>> with the user provided address of the buffer, not the kernel buffer.
>>>> Normally, it's used when copy_to_user() or copy_from_user() or
>>>> something similar failed.
>>>>
>>>> But this time, if you turn KASAN off, you'll see the last recvmsg()
>>>> returns 1-byte garbage instead of -EFAULT, so actually KASAN worked
>>>> on your host, I guess.
>>> No it did not work. As soon as KASAN detected read after free it should
>>> have paniced as it did in the report and I have been running the
>>> syzbot's C program in a continuous loop. I would like to reproduce the
>>> issue before we can accept the fix -- If that is alright with you. I
>>> will try your new test case later and report back. Thanks for the patch
>>> though.
>> KASAN does not panic unless you request it.
>>
>> Documentation/dev-tools/kasan.rst
>>
>> KASAN is affected by the generic ``panic_on_warn`` command line 
>> parameter.
>> When it is enabled, KASAN panics the kernel after printing a bug report.
>>
>> By default, KASAN prints a bug report only for the first invalid 
>> memory access.
>> With ``kasan_multi_shot``, KASAN prints a report on every invalid 
>> access. This
>> effectively disables ``panic_on_warn`` for KASAN reports.
>>
>> Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` 
>> boot
>> parameter can be used to control panic and reporting behaviour:
>>
>> - ``kasan.fault=report``, ``=panic``, or ``=panic_on_write`` controls 
>> whether
>>    to only print a KASAN report, panic the kernel, or panic the 
>> kernel on
>>    invalid writes only (default: ``report``). The panic happens even if
>>    ``kasan_multi_shot`` is enabled. Note that when using asynchronous 
>> mode of
>>    Hardware Tag-Based KASAN, ``kasan.fault=panic_on_write`` always 
>> panics on
>>    asynchronously checked accesses (including reads).
>
> Hi Eric,
>
> Thanks for the update. I forgot to mention that I I did set 
> /proc/sys/kernel/panic_on_warn to 1. I ran the program over night in 
> two separate windows, there are no reports and no panic. I first try 
> to reproduce the issue, because if I can not, how can I be sure that I 
> have fixed that bug? I may find another issue and fix it but not the 
> one that I was trying to. Please be assured that I am not done, I 
> continue to investigate the issue.
>
> If someone has a way of reproducing the failure please kindly let me 
> know.
>
> Kind regards,
>
> Shoaib
>
I have tried reproducing using the newly added tests but no luck. I will 
keep trying but if there is another occurrence please let me know. I am 
using an AMD system but that should not have any impact.

Shoaib

[root@turbo-2 af_unix]# git diff msg_oob.c
diff --git a/tools/testing/selftests/net/af_unix/msg_oob.c 
b/tools/testing/selftests/net/af_unix/msg_oob.c
index 535eb2c3d7d1..5fedb55adcf2 100644
--- a/tools/testing/selftests/net/af_unix/msg_oob.c
+++ b/tools/testing/selftests/net/af_unix/msg_oob.c
@@ -525,6 +525,30 @@ TEST_F(msg_oob, ex_oob_drop_2)
       }
  }
+TEST_F(msg_oob, ex_oob_oob)
+{
+       sendpair("x", 1, MSG_OOB);
+       epollpair(true);
+       siocatmarkpair(true);
+
+       recvpair("x", 1, 1, MSG_OOB);
+       epollpair(false);
+       siocatmarkpair(true);
+
+       sendpair("y", 1, MSG_OOB);
+       epollpair(true);
+       siocatmarkpair(true);
+
+       recvpair("", -EAGAIN, 1, 0);
+       epollpair(false);
+       siocatmarkpair(false);
+
+       recvpair("", -EINVAL, 1, MSG_OOB);
+       epollpair(false);
+       siocatmarkpair(false);
+}
+
+
  TEST_F(msg_oob, ex_oob_ahead_break)
  {
       sendpair("hello", 5, MSG_OOB);

[root@turbo-2 af_unix]# rm msg_oob
rm: remove regular file 'msg_oob'? y
[root@turbo-2 af_unix]# make msg_oob
gcc -isystem 
/home/rshoaib/debug_pnic/linux/tools/testing/selftests/../../../usr/include 
-D_GNU_SOURCE=     msg_oob.c   -o msg_oob

root@turbo-2 af_unix]# echo 1 > /proc/sys/kernel/panic_on_warn

./msg_oob
TAP version 13
1..40
# Starting 40 tests from 2 test cases.
#  RUN           msg_oob.no_peek.non_oob ...
#            OK  msg_oob.no_peek.non_oob
ok 1 msg_oob.no_peek.non_oob
#  RUN           msg_oob.no_peek.oob ...
#            OK  msg_oob.no_peek.oob
ok 2 msg_oob.no_peek.oob
#  RUN           msg_oob.no_peek.oob_drop ...
#            OK  msg_oob.no_peek.oob_drop
ok 3 msg_oob.no_peek.oob_drop
#  RUN           msg_oob.no_peek.oob_ahead ...
#            OK  msg_oob.no_peek.oob_ahead
ok 4 msg_oob.no_peek.oob_ahead
#  RUN           msg_oob.no_peek.oob_break ...
#            OK  msg_oob.no_peek.oob_break
ok 5 msg_oob.no_peek.oob_break
#  RUN           msg_oob.no_peek.oob_ahead_break ...
#            OK  msg_oob.no_peek.oob_ahead_break
ok 6 msg_oob.no_peek.oob_ahead_break
#  RUN           msg_oob.no_peek.oob_break_drop ...
#            OK  msg_oob.no_peek.oob_break_drop
ok 7 msg_oob.no_peek.oob_break_drop
#  RUN           msg_oob.no_peek.ex_oob_break ...
#            OK  msg_oob.no_peek.ex_oob_break
ok 8 msg_oob.no_peek.ex_oob_break
#  RUN           msg_oob.no_peek.ex_oob_drop ...
# msg_oob.c:242:ex_oob_drop:AF_UNIX :x
# msg_oob.c:243:ex_oob_drop:TCP     :Resource temporarily unavailable
# msg_oob.c:242:ex_oob_drop:AF_UNIX :y
# msg_oob.c:243:ex_oob_drop:TCP     :Invalid argument
#            OK  msg_oob.no_peek.ex_oob_drop
ok 9 msg_oob.no_peek.ex_oob_drop
#  RUN           msg_oob.no_peek.ex_oob_drop_2 ...
# msg_oob.c:242:ex_oob_drop_2:AF_UNIX :x
# msg_oob.c:243:ex_oob_drop_2:TCP     :Resource temporarily unavailable
#            OK  msg_oob.no_peek.ex_oob_drop_2
ok 10 msg_oob.no_peek.ex_oob_drop_2
#  RUN           msg_oob.no_peek.ex_oob_oob ...
# msg_oob.c:305:ex_oob_oob:Expected answ[0] (0) == oob_head (1)
# ex_oob_oob: Test terminated by assertion
#          FAIL  msg_oob.no_peek.ex_oob_oob
<...>
ok 38 msg_oob.peek.inline_ex_oob_no_drop
#  RUN           msg_oob.peek.inline_ex_oob_drop ...
# msg_oob.c:267:inline_ex_oob_drop:AF_UNIX :x
# msg_oob.c:268:inline_ex_oob_drop:TCP     :y
# msg_oob.c:267:inline_ex_oob_drop:AF_UNIX :x
# msg_oob.c:268:inline_ex_oob_drop:TCP     :y
# msg_oob.c:242:inline_ex_oob_drop:AF_UNIX :y
# msg_oob.c:243:inline_ex_oob_drop:TCP     :Resource temporarily unavailable
# msg_oob.c:242:inline_ex_oob_drop:AF_UNIX :y
# msg_oob.c:243:inline_ex_oob_drop:TCP     :Resource temporarily unavailable
#            OK  msg_oob.peek.inline_ex_oob_drop
ok 39 msg_oob.peek.inline_ex_oob_drop
#  RUN           msg_oob.peek.inline_ex_oob_siocatmark ...
#            OK  msg_oob.peek.inline_ex_oob_siocatmark
ok 40 msg_oob.peek.inline_ex_oob_siocatmark
# FAILED: 38 / 40 tests passed.
# Totals: pass:38 fail:2 xfail:0 xpass:0 skip:0 error:0

[root@turbo-2 af_unix]# uname -r
6.11.0-rao-rc6-gc763c4339688-dirty

[root@turbo-2 af_unix]# journalctl -r | grep -i kasan
Sep  6 21:15:25 turbo-2 kernel: kasan: KernelAddressSanitizer initialized

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Fri, 6 Sep 2024 22:06:27 -0700
> I have tried reproducing using the newly added tests but no luck. I will 
> keep trying but if there is another occurrence please let me know. I am 
> using an AMD system but that should not have any impact.
[...]
> +TEST_F(msg_oob, ex_oob_oob)
> +{
> +       sendpair("x", 1, MSG_OOB);
> +       epollpair(true);
> +       siocatmarkpair(true);
> +
> +       recvpair("x", 1, 1, MSG_OOB);
> +       epollpair(false);
> +       siocatmarkpair(true);
> +
> +       sendpair("y", 1, MSG_OOB);
> +       epollpair(true);
> +       siocatmarkpair(true);

The test fails on this line because SIOCATMARK has yet another bug
triggered by the same pattern, and my patch also fixes that.

If you remove this line, you'll see this failure on the following
recvpair("", -EAGAIN, 1, 0).

---8<---
# msg_oob.c:234:ex_oob_oob:AF_UNIX :y
# msg_oob.c:235:ex_oob_oob:Expected:Resource temporarily unavailable
# msg_oob.c:237:ex_oob_oob:Expected ret[0] (1) == expected_len (-1)
# ex_oob_oob: Test terminated by assertion
#          FAIL  msg_oob.peek.ex_oob_oob
not ok 31 msg_oob.peek.ex_oob_oob
---8<---

This failure means recv() without MSG_OOB expects -EAGAIN because
no data has been sent on the normal stream, but actually the recv()
returns 1 byte OOB data.

This is the same result triggered by the syzbot's repro.

I don't know why KASAN does not show a splat on your setup, but what
we need to do is not run the syz repro blindly and just wait a splat,
rather carefully analyse the sequence of syscalls and each consequence.

Sometimes I fixes bugs from the syzkaller's strace log without repro.

This time, the fact that recv() without MSG_OOB returns OOB data is
the clear sign that something went wrong.

You need not rely on KASAN.


> +
> +       recvpair("", -EAGAIN, 1, 0);
> +       epollpair(false);
> +       siocatmarkpair(false);
> +
> +       recvpair("", -EINVAL, 1, MSG_OOB);
> +       epollpair(false);
> +       siocatmarkpair(false);
> +}
[...]
> #  RUN           msg_oob.no_peek.ex_oob_oob ...
> # msg_oob.c:305:ex_oob_oob:Expected answ[0] (0) == oob_head (1)
> # ex_oob_oob: Test terminated by assertion
> #          FAIL  msg_oob.no_peek.ex_oob_oob

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/6/2024 10:06 PM, Shoaib Rao wrote:
> 
> On 9/6/2024 9:48 AM, Shoaib Rao wrote:
>>
>> On 9/6/2024 5:37 AM, Eric Dumazet wrote:
>>> On Thu, Sep 5, 2024 at 10:48 PM Shoaib Rao <rao.shoaib@oracle.com> 
>>> wrote:
>>>>
>>>> On 9/5/2024 1:35 PM, Kuniyuki Iwashima wrote:
>>>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>>>> Date: Thu, 5 Sep 2024 13:15:18 -0700
>>>>>> On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
>>>>>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>>>>>> Date: Thu, 5 Sep 2024 00:35:35 -0700
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I am not able to reproduce the issue. I have run the C program 
>>>>>>>> at least
>>>>>>>> 100 times in a loop. In the I do get an EFAULT, not sure if that is
>>>>>>>> intentional or not but no panic. Should I be doing something
>>>>>>>> differently? The kernel version I am using is
>>>>>>>> v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
>>>>>>> The -EFAULT is the bug meaning that we were trying to read an 
>>>>>>> consumed skb.
>>>>>>>
>>>>>>> But the first bug is in recvfrom() that shouldn't be able to read 
>>>>>>> OOB skb
>>>>>>> without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
>>>>>>> something bad happens.
>>>>>>>
>>>>>>>      socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
>>>>>>>      sendmsg(4, {msg_name=NULL, msg_namelen=0, 
>>>>>>> msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, 
>>>>>>> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
>>>>>>>      recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, 
>>>>>>> msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB| 
>>>>>>> MSG_WAITFORONE) = 1
>>>>>>>      sendmsg(4, {msg_name=NULL, msg_namelen=0, 
>>>>>>> msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, 
>>>>>>> msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
>>>>>>>> recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, 
>>>>>>>> NULL, NULL) = 1
>>>>>>>      recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 
>>>>>>> EFAULT (Bad address)
>>>>>>>
>>>>>>> I posted a fix officially:
>>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/ 
>>>>>>> netdev/20240905193240.17565-5-kuniyu@amazon.com/__;!! 
>>>>>>> ACWV5N9M2RV99hQ! 
>>>>>>> IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$
>>>>>> Thanks that is great. Isn't EFAULT,  normally indicative of an issue
>>>>>> with the user provided address of the buffer, not the kernel buffer.
>>>>> Normally, it's used when copy_to_user() or copy_from_user() or
>>>>> something similar failed.
>>>>>
>>>>> But this time, if you turn KASAN off, you'll see the last recvmsg()
>>>>> returns 1-byte garbage instead of -EFAULT, so actually KASAN worked
>>>>> on your host, I guess.
>>>> No it did not work. As soon as KASAN detected read after free it should
>>>> have paniced as it did in the report and I have been running the
>>>> syzbot's C program in a continuous loop. I would like to reproduce the
>>>> issue before we can accept the fix -- If that is alright with you. I
>>>> will try your new test case later and report back. Thanks for the patch
>>>> though.
>>> KASAN does not panic unless you request it.
>>>
>>> Documentation/dev-tools/kasan.rst
>>>
>>> KASAN is affected by the generic ``panic_on_warn`` command line 
>>> parameter.
>>> When it is enabled, KASAN panics the kernel after printing a bug report.
>>>
>>> By default, KASAN prints a bug report only for the first invalid 
>>> memory access.
>>> With ``kasan_multi_shot``, KASAN prints a report on every invalid 
>>> access. This
>>> effectively disables ``panic_on_warn`` for KASAN reports.
>>>
>>> Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` 
>>> boot
>>> parameter can be used to control panic and reporting behaviour:
>>>
>>> - ``kasan.fault=report``, ``=panic``, or ``=panic_on_write`` controls 
>>> whether
>>>    to only print a KASAN report, panic the kernel, or panic the 
>>> kernel on
>>>    invalid writes only (default: ``report``). The panic happens even if
>>>    ``kasan_multi_shot`` is enabled. Note that when using asynchronous 
>>> mode of
>>>    Hardware Tag-Based KASAN, ``kasan.fault=panic_on_write`` always 
>>> panics on
>>>    asynchronously checked accesses (including reads).
>>
>> Hi Eric,
>>
>> Thanks for the update. I forgot to mention that I I did set /proc/sys/ 
>> kernel/panic_on_warn to 1. I ran the program over night in two 
>> separate windows, there are no reports and no panic. I first try to 
>> reproduce the issue, because if I can not, how can I be sure that I 
>> have fixed that bug? I may find another issue and fix it but not the 
>> one that I was trying to. Please be assured that I am not done, I 
>> continue to investigate the issue.
>>
>> If someone has a way of reproducing the failure please kindly let me 
>> know.
>>
>> Kind regards,
>>
>> Shoaib
>>
> I have tried reproducing using the newly added tests but no luck. I will 
> keep trying but if there is another occurrence please let me know. I am 
> using an AMD system but that should not have any impact.
> 
> Shoaib
> 

I have some more time investigating the issue. The sequence of packet 
arrival and consumption definitely points to an issue with OOB handling 
and I will be submitting a patch for that.

kasan does not report any issue because there are none. While the 
handling is incorrect, at no point freed memory is accessed. EFAULT 
error code is returned from __skb_datagram_iter()

/* This is not really a user copy fault, but rather someone 

  * gave us a bogus length on the skb.  We should probably 

  * print a warning here as it may indicate a kernel bug. 

  */ 


fault: 

     iov_iter_revert(to, offset - start_off); 

     return -EFAULT;

As the comment says, the issue is that the skb in question has a bogus 
length. Due to the bug in handling, the OOB byte has already been read 
as a regular byte, but oob pointer is not cleared, So when a read with 
OOB flag is issued, the code calls __skb_datagram_iter with the skb 
pointer which has a length of zero. The code detects it and returns the 
error. Any doubts can be verified by checking the refcnt on the skb.

My conclusion is that the bug report by syzbot is not caused by the 
mishandling of OOB, unless there was code added to disregard the skb 
length and read a byte.

The error being returned is confusing. The callers should not pass this 
error to the application. They should process the error.

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Mon, 9 Sep 2024 17:29:04 -0700
> I have some more time investigating the issue. The sequence of packet 
> arrival and consumption definitely points to an issue with OOB handling 
> and I will be submitting a patch for that.

It seems a bit late.
My patches were applied few minutes before this mail was sent.
https://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@kernel.org/


> 
> kasan does not report any issue because there are none. While the 
> handling is incorrect, at no point freed memory is accessed. EFAULT 
> error code is returned from __skb_datagram_iter()
> 
> /* This is not really a user copy fault, but rather someone 
> 
>   * gave us a bogus length on the skb.  We should probably 
> 
>   * print a warning here as it may indicate a kernel bug. 
> 
>   */ 
> 
> 
> fault: 
> 
>      iov_iter_revert(to, offset - start_off); 
> 
>      return -EFAULT;
> 
> As the comment says, the issue is that the skb in question has a bogus 
> length. Due to the bug in handling, the OOB byte has already been read 
> as a regular byte, but oob pointer is not cleared, So when a read with 
> OOB flag is issued, the code calls __skb_datagram_iter with the skb 
> pointer which has a length of zero. The code detects it and returns the 
> error. Any doubts can be verified by checking the refcnt on the skb.
> 
> My conclusion is that the bug report by syzbot is not caused by the 
> mishandling of OOB,

It _is_ caused by mishandling of OOB as you wrote in your patch.

  ---8<---
  Send OOB
  Read OOB
  Send OOB
  Read (Without OOB flag)

  The last read returns the OOB byte, which is incorrect.
  ---8<---


> unless there was code added to disregard the skb 
> length and read a byte.
> 
> The error being returned is confusing. The callers should not pass this 
> error to the application. They should process the error.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/9/2024 5:48 PM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@oracle.com>
> Date: Mon, 9 Sep 2024 17:29:04 -0700
>> I have some more time investigating the issue. The sequence of packet
>> arrival and consumption definitely points to an issue with OOB handling
>> and I will be submitting a patch for that.
> 
> It seems a bit late.
> My patches were applied few minutes before this mail was sent.
> https://urldefense.com/v3/__https://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@kernel.org/__;!!ACWV5N9M2RV99hQ!M806VrqNEGFgGXEoWG85msKAdFPXup7RzHy9Kt4q_HOfpPWsjNHn75KyFK3a3jWvOb9EEQuFGOjpqgk$
> 

That is a subpar fix. I am not sure why the maintainers accepted the fix 
when it was clear that I was still looking into the issue. Plus the 
claim that it fixes the panic is absolutely wrong.
> 
>>
>> kasan does not report any issue because there are none. While the
>> handling is incorrect, at no point freed memory is accessed. EFAULT
>> error code is returned from __skb_datagram_iter()
>>
>> /* This is not really a user copy fault, but rather someone
>>
>>    * gave us a bogus length on the skb.  We should probably
>>
>>    * print a warning here as it may indicate a kernel bug.
>>
>>    */
>>
>>
>> fault:
>>
>>       iov_iter_revert(to, offset - start_off);
>>
>>       return -EFAULT;
>>
>> As the comment says, the issue is that the skb in question has a bogus
>> length. Due to the bug in handling, the OOB byte has already been read
>> as a regular byte, but oob pointer is not cleared, So when a read with
>> OOB flag is issued, the code calls __skb_datagram_iter with the skb
>> pointer which has a length of zero. The code detects it and returns the
>> error. Any doubts can be verified by checking the refcnt on the skb.
>>
>> My conclusion is that the bug report by syzbot is not caused by the
>> mishandling of OOB,
> 
> It _is_ caused by mishandling of OOB as you wrote in your patch.
> 
>    ---8<---
>    Send OOB
>    Read OOB
>    Send OOB
>    Read (Without OOB flag)
> 
>    The last read returns the OOB byte, which is incorrect.
>    ---8<---
> 

I never said that the panic was caused by the mishandling of the OOB. I 
specifically said it was NOT caused by the mishandling of the OOB.

I don't have time to argue about the fix. I am just disappointed that 
the maintainers accepted a patch that was still being discussed and is 
not the best fix.

Shoaib

> 
>> unless there was code added to disregard the skb
>> length and read a byte.
>>
>> The error being returned is confusing. The callers should not pass this
>> error to the application. They should process the error.
> 

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Tue, 10 Sep 2024 09:55:03 -0700
> On 9/9/2024 5:48 PM, Kuniyuki Iwashima wrote:
> > From: Shoaib Rao <rao.shoaib@oracle.com>
> > Date: Mon, 9 Sep 2024 17:29:04 -0700
> >> I have some more time investigating the issue. The sequence of packet
> >> arrival and consumption definitely points to an issue with OOB handling
> >> and I will be submitting a patch for that.
> > 
> > It seems a bit late.
> > My patches were applied few minutes before this mail was sent.
> > https://urldefense.com/v3/__https://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@kernel.org/__;!!ACWV5N9M2RV99hQ!M806VrqNEGFgGXEoWG85msKAdFPXup7RzHy9Kt4q_HOfpPWsjNHn75KyFK3a3jWvOb9EEQuFGOjpqgk$
> > 
> 
> That is a subpar fix. I am not sure why the maintainers accepted the fix 
> when it was clear that I was still looking into the issue.

Just because it's not a subpar fix and you were slow and wrong,
clining to triggering the KASAN splat without thinking much.


> Plus the 
> claim that it fixes the panic is absolutely wrong.

The _root_ cause of the splat is mishandling of OOB in manage_oob()
which causes UAF later in another recvmsg().

Honestly your patch is rather a subpar fix to me, few points:

  1. The change conflicts with net-next as we have already removed
     the additional unnecessary refcnt for OOB skb that has caused
     so many issue reported by syzkaller

  2. Removing OOB skb in queue_oob() relies on the unneeded refcnt
     but it's not mentioned; if merge was done wrongly, another UAF
     will be introduced in recvmsg()

  3. Even the removing logic is completely unnecessary if manage_oob()
     is changed

  4. The scan_again: label is misplaced; two consecutive empty OOB skbs
     never exist at the head of recvq

  5. ioctl() is not fixed

  6. No test added

  7. Fixes: tag is bogus

  8. Subject lacks target tree and af_unix prefix

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/10/2024 10:57 AM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@oracle.com>
> Date: Tue, 10 Sep 2024 09:55:03 -0700
>> On 9/9/2024 5:48 PM, Kuniyuki Iwashima wrote:
>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>> Date: Mon, 9 Sep 2024 17:29:04 -0700
>>>> I have some more time investigating the issue. The sequence of packet
>>>> arrival and consumption definitely points to an issue with OOB handling
>>>> and I will be submitting a patch for that.
>>>
>>> It seems a bit late.
>>> My patches were applied few minutes before this mail was sent.
>>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@kernel.org/__;!!ACWV5N9M2RV99hQ!M806VrqNEGFgGXEoWG85msKAdFPXup7RzHy9Kt4q_HOfpPWsjNHn75KyFK3a3jWvOb9EEQuFGOjpqgk$
>>>
>>
>> That is a subpar fix. I am not sure why the maintainers accepted the fix
>> when it was clear that I was still looking into the issue.
> 
> Just because it's not a subpar fix and you were slow and wrong,
> clining to triggering the KASAN splat without thinking much.
> 
> 
>> Plus the
>> claim that it fixes the panic is absolutely wrong.
> 
> The _root_ cause of the splat is mishandling of OOB in manage_oob()
> which causes UAF later in another recvmsg().
> 
> Honestly your patch is rather a subpar fix to me, few points:
> 
>    1. The change conflicts with net-next as we have already removed
>       the additional unnecessary refcnt for OOB skb that has caused
>       so many issue reported by syzkaller
> 
>    2. Removing OOB skb in queue_oob() relies on the unneeded refcnt
>       but it's not mentioned; if merge was done wrongly, another UAF
>       will be introduced in recvmsg()
> 
>    3. Even the removing logic is completely unnecessary if manage_oob()
>       is changed
> 
>    4. The scan_again: label is misplaced; two consecutive empty OOB skbs
>       never exist at the head of recvq
> 
>    5. ioctl() is not fixed
> 
>    6. No test added
> 
>    7. Fixes: tag is bogus
> 
>    8. Subject lacks target tree and af_unix prefix

If you want to nit pick, nit pick away, Just because the patch email 
lacks proper formatting does not make the patch technically inferior. My 
fix is a proper fix not a hack. The change in queue_oob is sufficient to 
fix all issues including SIOCATMARK. The fix in manage_oob is just for 
correctness. In your fix I specifically did not like the change made to 
fix SIOCATMARK.

What is most worrying is claim to fixing a panic when it can not even 
happen with the bug. Please note I am not pushing that my patch be 
accepted, I have done what I am suppose to do, it is upto the 
maintainers to decide what is best for the code.


Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Tue, 10 Sep 2024 11:16:59 -0700
> On 9/10/2024 10:57 AM, Kuniyuki Iwashima wrote:
> > From: Shoaib Rao <rao.shoaib@oracle.com>
> > Date: Tue, 10 Sep 2024 09:55:03 -0700
> >> On 9/9/2024 5:48 PM, Kuniyuki Iwashima wrote:
> >>> From: Shoaib Rao <rao.shoaib@oracle.com>
> >>> Date: Mon, 9 Sep 2024 17:29:04 -0700
> >>>> I have some more time investigating the issue. The sequence of packet
> >>>> arrival and consumption definitely points to an issue with OOB handling
> >>>> and I will be submitting a patch for that.
> >>>
> >>> It seems a bit late.
> >>> My patches were applied few minutes before this mail was sent.
> >>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@kernel.org/__;!!ACWV5N9M2RV99hQ!M806VrqNEGFgGXEoWG85msKAdFPXup7RzHy9Kt4q_HOfpPWsjNHn75KyFK3a3jWvOb9EEQuFGOjpqgk$
> >>>
> >>
> >> That is a subpar fix. I am not sure why the maintainers accepted the fix
> >> when it was clear that I was still looking into the issue.
> > 
> > Just because it's not a subpar fix and you were slow and wrong,
> > clining to triggering the KASAN splat without thinking much.
> > 
> > 
> >> Plus the
> >> claim that it fixes the panic is absolutely wrong.
> > 
> > The _root_ cause of the splat is mishandling of OOB in manage_oob()
> > which causes UAF later in another recvmsg().
> > 
> > Honestly your patch is rather a subpar fix to me, few points:
> > 
> >    1. The change conflicts with net-next as we have already removed
> >       the additional unnecessary refcnt for OOB skb that has caused
> >       so many issue reported by syzkaller
> > 
> >    2. Removing OOB skb in queue_oob() relies on the unneeded refcnt
> >       but it's not mentioned; if merge was done wrongly, another UAF
> >       will be introduced in recvmsg()
> > 
> >    3. Even the removing logic is completely unnecessary if manage_oob()
> >       is changed
> > 
> >    4. The scan_again: label is misplaced; two consecutive empty OOB skbs
> >       never exist at the head of recvq
> > 
> >    5. ioctl() is not fixed
> > 
> >    6. No test added
> > 
> >    7. Fixes: tag is bogus
> > 
> >    8. Subject lacks target tree and af_unix prefix
> 
> If you want to nit pick, nit pick away, Just because the patch email 
> lacks proper formatting does not make the patch technically inferior.

Ironically you just nit picked 8.


> My 
> fix is a proper fix not a hack. The change in queue_oob is sufficient to 
> fix all issues including SIOCATMARK. The fix in manage_oob is just for 
> correctness.

Then, it should be WARN_ON_ONCE() not to confuse future readers.


> In your fix I specifically did not like the change made to 
> fix SIOCATMARK.

I don't like that part too, but it's needed to avoid the additional refcnt
that is much worse as syzbot has been demonstrating.


> 
> What is most worrying is claim to fixing a panic when it can not even 
> happen with the bug.

It's only on your setup.  syzbot and I were able to trigger that with
the bug.


> Please note I am not pushing that my patch be 
> accepted, I have done what I am suppose to do, it is upto the 
> maintainers to decide what is best for the code.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/10/2024 11:33 AM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@oracle.com>
> Date: Tue, 10 Sep 2024 11:16:59 -0700
>> On 9/10/2024 10:57 AM, Kuniyuki Iwashima wrote:
>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>> Date: Tue, 10 Sep 2024 09:55:03 -0700
>>>> On 9/9/2024 5:48 PM, Kuniyuki Iwashima wrote:
>>>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>>>> Date: Mon, 9 Sep 2024 17:29:04 -0700
>>>>>> I have some more time investigating the issue. The sequence of packet
>>>>>> arrival and consumption definitely points to an issue with OOB handling
>>>>>> and I will be submitting a patch for that.
>>>>>
>>>>> It seems a bit late.
>>>>> My patches were applied few minutes before this mail was sent.
>>>>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@kernel.org/__;!!ACWV5N9M2RV99hQ!M806VrqNEGFgGXEoWG85msKAdFPXup7RzHy9Kt4q_HOfpPWsjNHn75KyFK3a3jWvOb9EEQuFGOjpqgk$
>>>>>
>>>>
>>>> That is a subpar fix. I am not sure why the maintainers accepted the fix
>>>> when it was clear that I was still looking into the issue.
>>>
>>> Just because it's not a subpar fix and you were slow and wrong,
>>> clining to triggering the KASAN splat without thinking much.
>>>
>>>
>>>> Plus the
>>>> claim that it fixes the panic is absolutely wrong.
>>>
>>> The _root_ cause of the splat is mishandling of OOB in manage_oob()
>>> which causes UAF later in another recvmsg().
>>>
>>> Honestly your patch is rather a subpar fix to me, few points:
>>>
>>>     1. The change conflicts with net-next as we have already removed
>>>        the additional unnecessary refcnt for OOB skb that has caused
>>>        so many issue reported by syzkaller
>>>
>>>     2. Removing OOB skb in queue_oob() relies on the unneeded refcnt
>>>        but it's not mentioned; if merge was done wrongly, another UAF
>>>        will be introduced in recvmsg()
>>>
>>>     3. Even the removing logic is completely unnecessary if manage_oob()
>>>        is changed
>>>
>>>     4. The scan_again: label is misplaced; two consecutive empty OOB skbs
>>>        never exist at the head of recvq
>>>
>>>     5. ioctl() is not fixed
>>>
>>>     6. No test added
>>>
>>>     7. Fixes: tag is bogus
>>>
>>>     8. Subject lacks target tree and af_unix prefix
>>
>> If you want to nit pick, nit pick away, Just because the patch email
>> lacks proper formatting does not make the patch technically inferior.
> 
> Ironically you just nit picked 8.
> 
> 

I have no idea what you mean. I am more worried about technical 
correctness than formatting -- That does not mean formatting is not 
necessary.

>> My
>> fix is a proper fix not a hack. The change in queue_oob is sufficient to
>> fix all issues including SIOCATMARK. The fix in manage_oob is just for
>> correctness.
> 
> Then, it should be WARN_ON_ONCE() not to confuse future readers.
> 
> 
>> In your fix I specifically did not like the change made to
>> fix SIOCATMARK.
> 
> I don't like that part too, but it's needed to avoid the additional refcnt
> that is much worse as syzbot has been demonstrating.
> 

syzbot has nothing to do with doing a proper fix. One has to understand 
the code though to do the fix at the proper location.

> 
>>
>> What is most worrying is claim to fixing a panic when it can not even
>> happen with the bug.
> 
> It's only on your setup.  syzbot and I were able to trigger that with
> the bug.
> 

Really, what is so special about my setup that kasan does not like? Can 
you point me to the exact location where the access is made?

I am at least glad that you have backed off your assertion that my 
change does not fix the ioctl. I am sure if I keep pressing you, you 
will back off the panic claim as well. You yourself admitted you did not 
know why kasan was not panicing, Has anyone else hit the same panic?

If you can pin point the exact location where the illegal access is 
made, please do so and I will accept that I am wrong, other than that I 
am not interested in this constant back and forth with no technical 
details just fluff.

Shoaib

> 
>> Please note I am not pushing that my patch be
>> accepted, I have done what I am suppose to do, it is upto the
>> maintainers to decide what is best for the code.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Tue, 10 Sep 2024 11:49:20 -0700
> On 9/10/2024 11:33 AM, Kuniyuki Iwashima wrote:
> > From: Shoaib Rao <rao.shoaib@oracle.com>
> > Date: Tue, 10 Sep 2024 11:16:59 -0700
> >> On 9/10/2024 10:57 AM, Kuniyuki Iwashima wrote:
> >>> From: Shoaib Rao <rao.shoaib@oracle.com>
> >>> Date: Tue, 10 Sep 2024 09:55:03 -0700
> >>>> On 9/9/2024 5:48 PM, Kuniyuki Iwashima wrote:
> >>>>> From: Shoaib Rao <rao.shoaib@oracle.com>
> >>>>> Date: Mon, 9 Sep 2024 17:29:04 -0700
> >>>>>> I have some more time investigating the issue. The sequence of packet
> >>>>>> arrival and consumption definitely points to an issue with OOB handling
> >>>>>> and I will be submitting a patch for that.
> >>>>>
> >>>>> It seems a bit late.
> >>>>> My patches were applied few minutes before this mail was sent.
> >>>>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@kernel.org/__;!!ACWV5N9M2RV99hQ!M806VrqNEGFgGXEoWG85msKAdFPXup7RzHy9Kt4q_HOfpPWsjNHn75KyFK3a3jWvOb9EEQuFGOjpqgk$
> >>>>>
> >>>>
> >>>> That is a subpar fix. I am not sure why the maintainers accepted the fix
> >>>> when it was clear that I was still looking into the issue.
> >>>
> >>> Just because it's not a subpar fix and you were slow and wrong,
> >>> clining to triggering the KASAN splat without thinking much.
> >>>
> >>>
> >>>> Plus the
> >>>> claim that it fixes the panic is absolutely wrong.
> >>>
> >>> The _root_ cause of the splat is mishandling of OOB in manage_oob()
> >>> which causes UAF later in another recvmsg().
> >>>
> >>> Honestly your patch is rather a subpar fix to me, few points:
> >>>
> >>>     1. The change conflicts with net-next as we have already removed
> >>>        the additional unnecessary refcnt for OOB skb that has caused
> >>>        so many issue reported by syzkaller
> >>>
> >>>     2. Removing OOB skb in queue_oob() relies on the unneeded refcnt
> >>>        but it's not mentioned; if merge was done wrongly, another UAF
> >>>        will be introduced in recvmsg()
> >>>
> >>>     3. Even the removing logic is completely unnecessary if manage_oob()
> >>>        is changed
> >>>
> >>>     4. The scan_again: label is misplaced; two consecutive empty OOB skbs
> >>>        never exist at the head of recvq
> >>>
> >>>     5. ioctl() is not fixed
> >>>
> >>>     6. No test added
> >>>
> >>>     7. Fixes: tag is bogus
> >>>
> >>>     8. Subject lacks target tree and af_unix prefix
> >>
> >> If you want to nit pick, nit pick away, Just because the patch email
> >> lacks proper formatting does not make the patch technically inferior.
> > 
> > Ironically you just nit picked 8.
> > 
> > 
> 
> I have no idea what you mean. I am more worried about technical 
> correctness than formatting -- That does not mean formatting is not 
> necessary.

I started pointing out technical stuff and ended with nit-pick because
"I am more worried about technical correctness", but you started nit
picking from the last point.  That's unfortunate.


> 
> >> My
> >> fix is a proper fix not a hack. The change in queue_oob is sufficient to
> >> fix all issues including SIOCATMARK. The fix in manage_oob is just for
> >> correctness.
> > 
> > Then, it should be WARN_ON_ONCE() not to confuse future readers.
> > 
> > 
> >> In your fix I specifically did not like the change made to
> >> fix SIOCATMARK.
> > 
> > I don't like that part too, but it's needed to avoid the additional refcnt
> > that is much worse as syzbot has been demonstrating.
> > 
> 
> syzbot has nothing to do with doing a proper fix.

You don't understand my point.  syzbot has been finding many real issues
that were caused by poor handling of the additional refcount.

Also, removing it discovered another bug in manage_oob().  That's a enough
reason to explain why we should remove the unnecessary refcnt.


> One has to understand 
> the code though to do the fix at the proper location.

I'm not saying that the patch is correct if it silences syzbot.

Actually, I said KASAN is handy but you need not rely on it.

Rather it's you who argued the splat was needed even without trying
to understand the code.

I really don't understand why you are saying this to me now.


> 
> > 
> >>
> >> What is most worrying is claim to fixing a panic when it can not even
> >> happen with the bug.
> > 
> > It's only on your setup.  syzbot and I were able to trigger that with
> > the bug.
> > 
> 
> Really, what is so special about my setup that kasan does not like? Can 
> you point me to the exact location where the access is made?

I don't know, it's your job.

> 
> I am at least glad that you have backed off your assertion that my 
> change does not fix the ioctl.

Okay, I was wrong about that, and what about other points, fragile
refcnt, non-WARN_ON_ONCE(), misplaced label, no test, bogus tag ?


> I am sure if I keep pressing you, you 
> will back off the panic claim as well.

I also don't understand what you are saying and why you still can't
correlate the splat and the sequences of syscalls in the repro.


> You yourself admitted you did not 
> know why kasan was not panicing, Has anyone else hit the same panic?
> 
> If you can pin point the exact location where the illegal access is 
> made, please do so and I will accept that I am wrong, other than that I 
> am not interested in this constant back and forth with no technical 
> details just fluff.

Please read my changelog (and mails) carefully that pin-point the
exact location and reason where/why the illegal access happens.

This will be the last mail from me in this thread.  I don't want to
waste time on someone who doesn't read mails.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/10/2024 12:49 PM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@oracle.com>
> Date: Tue, 10 Sep 2024 11:49:20 -0700
>> On 9/10/2024 11:33 AM, Kuniyuki Iwashima wrote:
>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>> Date: Tue, 10 Sep 2024 11:16:59 -0700
>>>> On 9/10/2024 10:57 AM, Kuniyuki Iwashima wrote:
>>>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>>>> Date: Tue, 10 Sep 2024 09:55:03 -0700
>>>>>> On 9/9/2024 5:48 PM, Kuniyuki Iwashima wrote:
>>>>>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>>>>>> Date: Mon, 9 Sep 2024 17:29:04 -0700
>>>>>>>> I have some more time investigating the issue. The sequence of packet
>>>>>>>> arrival and consumption definitely points to an issue with OOB handling
>>>>>>>> and I will be submitting a patch for that.
>>>>>>>
>>>>>>> It seems a bit late.
>>>>>>> My patches were applied few minutes before this mail was sent.
>>>>>>> https://urldefense.com/v3/__https://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@kernel.org/__;!!ACWV5N9M2RV99hQ!M806VrqNEGFgGXEoWG85msKAdFPXup7RzHy9Kt4q_HOfpPWsjNHn75KyFK3a3jWvOb9EEQuFGOjpqgk$
>>>>>>>
>>>>>>
>>>>>> That is a subpar fix. I am not sure why the maintainers accepted the fix
>>>>>> when it was clear that I was still looking into the issue.
>>>>>
>>>>> Just because it's not a subpar fix and you were slow and wrong,
>>>>> clining to triggering the KASAN splat without thinking much.
>>>>>
>>>>>
>>>>>> Plus the
>>>>>> claim that it fixes the panic is absolutely wrong.
>>>>>
>>>>> The _root_ cause of the splat is mishandling of OOB in manage_oob()
>>>>> which causes UAF later in another recvmsg().
>>>>>
>>>>> Honestly your patch is rather a subpar fix to me, few points:
>>>>>
>>>>>      1. The change conflicts with net-next as we have already removed
>>>>>         the additional unnecessary refcnt for OOB skb that has caused
>>>>>         so many issue reported by syzkaller
>>>>>
>>>>>      2. Removing OOB skb in queue_oob() relies on the unneeded refcnt
>>>>>         but it's not mentioned; if merge was done wrongly, another UAF
>>>>>         will be introduced in recvmsg()
>>>>>
>>>>>      3. Even the removing logic is completely unnecessary if manage_oob()
>>>>>         is changed
>>>>>
>>>>>      4. The scan_again: label is misplaced; two consecutive empty OOB skbs
>>>>>         never exist at the head of recvq
>>>>>
>>>>>      5. ioctl() is not fixed
>>>>>
>>>>>      6. No test added
>>>>>
>>>>>      7. Fixes: tag is bogus
>>>>>
>>>>>      8. Subject lacks target tree and af_unix prefix
>>>>
>>>> If you want to nit pick, nit pick away, Just because the patch email
>>>> lacks proper formatting does not make the patch technically inferior.
>>>
>>> Ironically you just nit picked 8.
>>>
>>>
>>
>> I have no idea what you mean. I am more worried about technical
>> correctness than formatting -- That does not mean formatting is not
>> necessary.
> 
> I started pointing out technical stuff and ended with nit-pick because
> "I am more worried about technical correctness", but you started nit
> picking from the last point.  That's unfortunate.
> 
> 
>>
>>>> My
>>>> fix is a proper fix not a hack. The change in queue_oob is sufficient to
>>>> fix all issues including SIOCATMARK. The fix in manage_oob is just for
>>>> correctness.
>>>
>>> Then, it should be WARN_ON_ONCE() not to confuse future readers.
>>>
>>>
>>>> In your fix I specifically did not like the change made to
>>>> fix SIOCATMARK.
>>>
>>> I don't like that part too, but it's needed to avoid the additional refcnt
>>> that is much worse as syzbot has been demonstrating.
>>>
>>
>> syzbot has nothing to do with doing a proper fix.
> 
> You don't understand my point.  syzbot has been finding many real issues
> that were caused by poor handling of the additional refcount.
> 
> Also, removing it discovered another bug in manage_oob().  That's a enough
> reason to explain why we should remove the unnecessary refcnt.
> 
> 
>> One has to understand
>> the code though to do the fix at the proper location.
> 
> I'm not saying that the patch is correct if it silences syzbot.
> 
> Actually, I said KASAN is handy but you need not rely on it.
> 
> Rather it's you who argued the splat was needed even without trying
> to understand the code.
> 
> I really don't understand why you are saying this to me now.
> 
> 
>>
>>>
>>>>
>>>> What is most worrying is claim to fixing a panic when it can not even
>>>> happen with the bug.
>>>
>>> It's only on your setup.  syzbot and I were able to trigger that with
>>> the bug.
>>>
>>
>> Really, what is so special about my setup that kasan does not like? Can
>> you point me to the exact location where the access is made?
> 
> I don't know, it's your job.
> 
>>
>> I am at least glad that you have backed off your assertion that my
>> change does not fix the ioctl.
> 
> Okay, I was wrong about that, and what about other points, fragile
> refcnt, non-WARN_ON_ONCE(), misplaced label, no test, bogus tag ?
> 
> 
>> I am sure if I keep pressing you, you
>> will back off the panic claim as well.
> 
> I also don't understand what you are saying and why you still can't
> correlate the splat and the sequences of syscalls in the repro.
> 
> 
>> You yourself admitted you did not
>> know why kasan was not panicing, Has anyone else hit the same panic?
>>
>> If you can pin point the exact location where the illegal access is
>> made, please do so and I will accept that I am wrong, other than that I
>> am not interested in this constant back and forth with no technical
>> details just fluff.
> 
> Please read my changelog (and mails) carefully that pin-point the
> exact location and reason where/why the illegal access happens.

This is the explanation in the email:

 >
 > No it did not work. As soon as KASAN detected read after free it should
 > have paniced as it did in the report and I have been running the
 > syzbot's C program in a continuous loop. I would like to reproduce the
 > issue before we can accept the fix -- If that is alright with you. I
 > will try your new test case later and report back. Thanks for the patch
 > though.

The commit Message:

syzbot reported use-after-free in unix_stream_recv_urg(). [0]

The scenario is

   1. send(MSG_OOB)
   2. recv(MSG_OOB)
      -> The consumed OOB remains in recv queue
   3. send(MSG_OOB)
   4. recv()
      -> manage_oob() returns the next skb of the consumed OOB
      -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared
   5. recv(MSG_OOB)
      -> unix_sk(sk)->oob_skb is used but already freed

The recent commit 8594d9b85c07 ("af_unix: Don't call skb_get() for OOB
skb.") uncovered the issue.

If the OOB skb is consumed and the next skb is peeked in manage_oob(),
we still need to check if the skb is OOB.

Let's do so by falling back to the following checks in manage_oob()
and add the test case in selftest.

Note that we need to add a similar check for SIOCATMARK.

And this

* [PATCH v1 net-next] af_unix: Don't call skb_get() for OOB skb.
@ 2024-08-16 23:39 Kuniyuki Iwashima
   2024-08-20 23:00 ` patchwork-bot+netdevbpf
   0 siblings, 1 reply; 2+ messages in thread
From: Kuniyuki Iwashima @ 2024-08-16 23:39 UTC (permalink / raw)
   To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
   Cc: Kuniyuki Iwashima, Kuniyuki Iwashima, netdev

Since introduced, OOB skb holds an additional reference count with no
special reason and caused many issues.

Also, kfree_skb() and consume_skb() are used to decrement the count,
which is confusing.

Let's drop the unnecessary skb_get() in queue_oob() and corresponding
kfree_skb(), consume_skb(), and skb_unref().

Now unix_sk(sk)->oob_skb is just a pointer to skb in the receive queue,
so special handing is no longer needed in GC.


And more:

The splat is handy, you may want to check the returned value of recvfrom()
with KASAN on and off and then focus on the root cause.  When UAF happens,
the real bug always happens before that.

FWIW, I was able to see the splat on my setup and it disappeared with
my patch.  Also, syzbot has already tested the equivalent change.
https://urldefense.com/v3/__https://lore.kernel.org/netdev/00000000000064fbcb06215a7bbc@google.com/__;!!ACWV5N9M2RV99hQ!MiZQCdyNumVmB3YeKfZxVbJFPsouXDCN7ie5DBfjBiurJib1D7k4bO_Jg1cAie9KIkAgXezFUaGOFhg$

None of this points to where the skb is "dereferenced" The test case 
added will never panic the kernel.

In the organizations that I have worked with, just because a change 
stops a panic does not mean the issue is fixed. You have to explicitly 
show where and how. That is what i am asking, Yes there is a bug, but it 
will not cause the panic, so if you are just high and might engiineer, 
show where and how?
> 
> This will be the last mail from me in this thread.  I don't want to
> waste time on someone who doesn't read mails.
Yes please don't if you do not have anything technical to say, all your 
comments are "smart comments". This email thread would end if you could 
just say, here is line XXXX where the skb is de referenced, but you have 
not because you have no idea.

BTTW Your comment about holding the extra refcnt without any reason just 
shows that you DO NOT understand the code. And the confusion to refcnts 
has been caused by your changes, I am concerned your changes have broken 
the code.

I am willing to accept that I may be wrong but only if I am shown the 
location of de-reference. Please do not respond if you can not point to 
the exact location.

Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Tue, 10 Sep 2024 13:57:04 -0700
> The commit Message:
> 
> syzbot reported use-after-free in unix_stream_recv_urg(). [0]
> 
> The scenario is
> 
>    1. send(MSG_OOB)
>    2. recv(MSG_OOB)
>       -> The consumed OOB remains in recv queue
>    3. send(MSG_OOB)
>    4. recv()
>       -> manage_oob() returns the next skb of the consumed OOB
>       -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared
>    5. recv(MSG_OOB)
>       -> unix_sk(sk)->oob_skb is used but already freed

How did you miss this ?

Again, please read my patch and mails **carefully**.

unix_sk(sk)->oob_sk wasn't cleared properly and illegal access happens
in unix_stream_recv_urg(), where ->oob_skb is dereferenced.

Here's _technical_ thing that you want.

---8<---
# ./oob
executing program
[   25.773750] queued OOB: ff1100000947ba40
[   25.774110] reading OOB: ff1100000947ba40
[   25.774401] queued OOB: ff1100000947bb80
[   25.774669] free skb: ff1100000947bb80
[   25.774919] reading OOB: ff1100000947bb80
[   25.775172] ==================================================================
[   25.775654] BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0x86/0xb0
---8<---

---8<---
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index a1894019ebd5..ccd9c47160a5 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2230,6 +2230,7 @@ static int queue_oob(struct socket *sock, struct msghdr *msg, struct sock *other
 	__skb_queue_tail(&other->sk_receive_queue, skb);
 	spin_unlock(&other->sk_receive_queue.lock);
 
+	printk(KERN_ERR "queued OOB: %px\n", skb);
 	sk_send_sigurg(other);
 	unix_state_unlock(other);
 	other->sk_data_ready(other);
@@ -2637,6 +2638,7 @@ static int unix_stream_recv_urg(struct unix_stream_read_state *state)
 	spin_unlock(&sk->sk_receive_queue.lock);
 	unix_state_unlock(sk);
 
+	printk(KERN_ERR "reading OOB: %px\n", oob_skb);
 	chunk = state->recv_actor(oob_skb, 0, chunk, state);
 
 	if (!(state->flags & MSG_PEEK))
@@ -2915,7 +2917,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
 
 			skb_unlink(skb, &sk->sk_receive_queue);
 			consume_skb(skb);
-
+			printk(KERN_ERR "free skb: %px\n", skb);
 			if (scm.fp)
 				break;
 		} else {
---8<---

[...]
> None of this points to where the skb is "dereferenced" The test case 
> added will never panic the kernel.
> 
> In the organizations that I have worked with, just because a change 
> stops a panic does not mean the issue is fixed. You have to explicitly 
> show where and how. That is what i am asking, Yes there is a bug, but it 
> will not cause the panic, so if you are just high and might engiineer, 
> show where and how?
> > 
> > This will be the last mail from me in this thread.  I don't want to
> > waste time on someone who doesn't read mails.
> Yes please don't if you do not have anything technical to say, all your 
> comments are "smart comments". This email thread would end if you could 
> just say, here is line XXXX where the skb is de referenced, but you have 
> not because you have no idea.
> 
> BTTW Your comment about holding the extra refcnt without any reason just 
> shows that you DO NOT understand the code. And the confusion to refcnts 
> has been caused by your changes, I am concerned your changes have broken 
> the code.
> 
> I am willing to accept that I may be wrong but only if I am shown the 
> location of de-reference. Please do not respond if you can not point to 
> the exact location.

Please do not respond if you just ask without thinking.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

My fellow engineer let's first take a breath and calm down. We both are 
trying to do the right thing. Now read my comments below and if I still 
don't get it, please be patient, maybe I am not as smart as you are.

On 9/10/2024 2:53 PM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@oracle.com>
> Date: Tue, 10 Sep 2024 13:57:04 -0700
>> The commit Message:
>>
>> syzbot reported use-after-free in unix_stream_recv_urg(). [0]
>>
>> The scenario is
>>
>>     1. send(MSG_OOB)
>>     2. recv(MSG_OOB)
>>        -> The consumed OOB remains in recv queue
>>     3. send(MSG_OOB)
>>     4. recv()
>>        -> manage_oob() returns the next skb of the consumed OOB
>>        -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared
>>     5. recv(MSG_OOB)
>>        -> unix_sk(sk)->oob_skb is used but already freed
> 
> How did you miss this ?
> 
> Again, please read my patch and mails **carefully**.
> 
> unix_sk(sk)->oob_sk wasn't cleared properly and illegal access happens
> in unix_stream_recv_urg(), where ->oob_skb is dereferenced.
> 
> Here's _technical_ thing that you want.

This is exactly what I am trying to point out to you.
The skb has proper references and is NOT de-referenced because 
__skb_datagram_iter() detects that the length is zero and returns EFAULT.

See more below
> 
> ---8<---
> # ./oob
> executing program
> [   25.773750] queued OOB: ff1100000947ba40
> [   25.774110] reading OOB: ff1100000947ba40
> [   25.774401] queued OOB: ff1100000947bb80
> [   25.774669] free skb: ff1100000947bb80
> [   25.774919] reading OOB: ff1100000947bb80
> [   25.775172] ==================================================================
> [   25.775654] BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0x86/0xb0
> ---8<---
> 
> ---8<---
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index a1894019ebd5..ccd9c47160a5 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -2230,6 +2230,7 @@ static int queue_oob(struct socket *sock, struct msghdr *msg, struct sock *other
>   	__skb_queue_tail(&other->sk_receive_queue, skb);
>   	spin_unlock(&other->sk_receive_queue.lock);
>   
> +	printk(KERN_ERR "queued OOB: %px\n", skb);
>   	sk_send_sigurg(other);
>   	unix_state_unlock(other);
>   	other->sk_data_ready(other);
> @@ -2637,6 +2638,7 @@ static int unix_stream_recv_urg(struct unix_stream_read_state *state)
>   	spin_unlock(&sk->sk_receive_queue.lock);
>   	unix_state_unlock(sk);
>   
> +	printk(KERN_ERR "reading OOB: %px\n", oob_skb);
>   	chunk = state->recv_actor(oob_skb, 0, chunk, state);
>   
>   	if (!(state->flags & MSG_PEEK))
> @@ -2915,7 +2917,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
>   
>   			skb_unlink(skb, &sk->sk_receive_queue);
>   			consume_skb(skb);
> -
> +			printk(KERN_ERR "free skb: %px\n", skb);

This printk is wrongly placed because the skb has been freed above, but 
since it is just printing the pointer it should be OK, access to any skb 
field will be an issue. You should move this printk to before 
unix_stream_read_generic and print the refcnt on the skb and the length 
of the data and verify what I am saying, that the skb has one refcnt and 
zero length.

This is the kind of interaction I was looking for. If I have missed 
something please be patient and let me know.

Regards,

Shoaib


>   			if (scm.fp)
>   				break;
>   		} else {
> ---8<---
> 
> [...]
>> None of this points to where the skb is "dereferenced" The test case
>> added will never panic the kernel.
>>
>> In the organizations that I have worked with, just because a change
>> stops a panic does not mean the issue is fixed. You have to explicitly
>> show where and how. That is what i am asking, Yes there is a bug, but it
>> will not cause the panic, so if you are just high and might engiineer,
>> show where and how?
>>>
>>> This will be the last mail from me in this thread.  I don't want to
>>> waste time on someone who doesn't read mails.
>> Yes please don't if you do not have anything technical to say, all your
>> comments are "smart comments". This email thread would end if you could
>> just say, here is line XXXX where the skb is de referenced, but you have
>> not because you have no idea.
>>
>> BTTW Your comment about holding the extra refcnt without any reason just
>> shows that you DO NOT understand the code. And the confusion to refcnts
>> has been caused by your changes, I am concerned your changes have broken
>> the code.
>>
>> I am willing to accept that I may be wrong but only if I am shown the
>> location of de-reference. Please do not respond if you can not point to
>> the exact location.
> 
> Please do not respond if you just ask without thinking.

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Tue, 10 Sep 2024 15:30:08 -0700
> My fellow engineer let's first take a breath and calm down. We both are 
> trying to do the right thing. Now read my comments below and if I still 
> don't get it, please be patient, maybe I am not as smart as you are.
> 
> On 9/10/2024 2:53 PM, Kuniyuki Iwashima wrote:
> > From: Shoaib Rao <rao.shoaib@oracle.com>
> > Date: Tue, 10 Sep 2024 13:57:04 -0700
> >> The commit Message:
> >>
> >> syzbot reported use-after-free in unix_stream_recv_urg(). [0]
> >>
> >> The scenario is
> >>
> >>     1. send(MSG_OOB)
> >>     2. recv(MSG_OOB)
> >>        -> The consumed OOB remains in recv queue
> >>     3. send(MSG_OOB)
> >>     4. recv()
> >>        -> manage_oob() returns the next skb of the consumed OOB
> >>        -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared
> >>     5. recv(MSG_OOB)
> >>        -> unix_sk(sk)->oob_skb is used but already freed
> > 
> > How did you miss this ?
> > 
> > Again, please read my patch and mails **carefully**.
> > 
> > unix_sk(sk)->oob_sk wasn't cleared properly and illegal access happens
> > in unix_stream_recv_urg(), where ->oob_skb is dereferenced.
> > 
> > Here's _technical_ thing that you want.
> 
> This is exactly what I am trying to point out to you.
> The skb has proper references and is NOT de-referenced because 
> __skb_datagram_iter() detects that the length is zero and returns EFAULT.

It's dereferenced as UNIXCB(skb).consumed first in
unix_stream_read_actor().

Then, 1 byte of data is copied without -EFAULT because
unix_stream_recv_urg() always passes 1 as chunk (size) to
recv_actor().

That's why I said KASAN should be working on your setup and suggested
running the repro with/without KASAN.  If KASAN is turned off, single
byte garbage is copied from the freed area.

See the last returned values below

Without KASAN:

---8<---
write(1, "executing program\n", 18
executing program
)     = 18
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT
[   15.657345] queued OOB: ff1100000442c700
) = 1
recvmsg(3,
[   15.657793] reading OOB: ff1100000442c700
{msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE
[   15.659830] queued OOB: ff1100000442c300
) = 1
recvfrom(3,
[   15.660272] free skb: ff1100000442c300
"\21", 125, MSG_DONTROUTE|MSG_TRUNC, NULL, NULL) = 1
recvmsg(3,
[   15.661014] reading OOB: ff1100000442c300
{msg_namelen=0, MSG_OOB|MSG_ERRQUEUE) = 1
---8<---


With KASAN:

---8<---
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT
[  134.735962] queued OOB: ff110000099f0b40
) = 1
recvmsg(3,
[  134.736460] reading OOB: ff110000099f0b40
{msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE
[  134.738554] queued OOB: ff110000099f0c80
) = 1
recvfrom(3,
[  134.739086] free skb: ff110000099f0c80
"\21", 125, MSG_DONTROUTE|MSG_TRUNC, NULL, NULL) = 1
recvmsg(3,
[  134.739792] reading OOB: ff110000099f0c80
 {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)
---8<---


> 
> See more below
> > 
> > ---8<---
> > # ./oob
> > executing program
> > [   25.773750] queued OOB: ff1100000947ba40
> > [   25.774110] reading OOB: ff1100000947ba40
> > [   25.774401] queued OOB: ff1100000947bb80
> > [   25.774669] free skb: ff1100000947bb80
> > [   25.774919] reading OOB: ff1100000947bb80
> > [   25.775172] ==================================================================
> > [   25.775654] BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0x86/0xb0
> > ---8<---
> > 
> > ---8<---
> > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> > index a1894019ebd5..ccd9c47160a5 100644
> > --- a/net/unix/af_unix.c
> > +++ b/net/unix/af_unix.c
> > @@ -2230,6 +2230,7 @@ static int queue_oob(struct socket *sock, struct msghdr *msg, struct sock *other
> >   	__skb_queue_tail(&other->sk_receive_queue, skb);
> >   	spin_unlock(&other->sk_receive_queue.lock);
> >   
> > +	printk(KERN_ERR "queued OOB: %px\n", skb);
> >   	sk_send_sigurg(other);
> >   	unix_state_unlock(other);
> >   	other->sk_data_ready(other);
> > @@ -2637,6 +2638,7 @@ static int unix_stream_recv_urg(struct unix_stream_read_state *state)
> >   	spin_unlock(&sk->sk_receive_queue.lock);
> >   	unix_state_unlock(sk);
> >   
> > +	printk(KERN_ERR "reading OOB: %px\n", oob_skb);
> >   	chunk = state->recv_actor(oob_skb, 0, chunk, state);
> >   
> >   	if (!(state->flags & MSG_PEEK))
> > @@ -2915,7 +2917,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
> >   
> >   			skb_unlink(skb, &sk->sk_receive_queue);
> >   			consume_skb(skb);
> > -
> > +			printk(KERN_ERR "free skb: %px\n", skb);
> 
> This printk is wrongly placed

It's not, because this just prints the address of OOB skb just after
it's illegally consumed without MSG_OOB.  The code is only called
for the illegal OOB during the repro.


> because the skb has been freed above, but 
> since it is just printing the pointer it should be OK, access to any skb 
> field will be an issue. You should move this printk to before 
> unix_stream_read_generic and print the refcnt on the skb and the length 
> of the data and verify what I am saying, that the skb has one refcnt and 
> zero length.

Note this is on top of net-next where no additional refcnt is taken
for OOB, so no need to print skb's refcnt.  Also the length is not
related because chunk is always 1.


> This is the kind of interaction I was looking for. If I have missed 
> something please be patient and let me know.
> 
> Regards,
> 
> Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Shoaib Rao]

On 9/10/2024 3:59 PM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@oracle.com>
> Date: Tue, 10 Sep 2024 15:30:08 -0700
>> My fellow engineer let's first take a breath and calm down. We both are
>> trying to do the right thing. Now read my comments below and if I still
>> don't get it, please be patient, maybe I am not as smart as you are.
>>
>> On 9/10/2024 2:53 PM, Kuniyuki Iwashima wrote:
>>> From: Shoaib Rao <rao.shoaib@oracle.com>
>>> Date: Tue, 10 Sep 2024 13:57:04 -0700
>>>> The commit Message:
>>>>
>>>> syzbot reported use-after-free in unix_stream_recv_urg(). [0]
>>>>
>>>> The scenario is
>>>>
>>>>      1. send(MSG_OOB)
>>>>      2. recv(MSG_OOB)
>>>>         -> The consumed OOB remains in recv queue
>>>>      3. send(MSG_OOB)
>>>>      4. recv()
>>>>         -> manage_oob() returns the next skb of the consumed OOB
>>>>         -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared
>>>>      5. recv(MSG_OOB)
>>>>         -> unix_sk(sk)->oob_skb is used but already freed
>>>
>>> How did you miss this ?
>>>
>>> Again, please read my patch and mails **carefully**.
>>>
>>> unix_sk(sk)->oob_sk wasn't cleared properly and illegal access happens
>>> in unix_stream_recv_urg(), where ->oob_skb is dereferenced.
>>>
>>> Here's _technical_ thing that you want.
>>
>> This is exactly what I am trying to point out to you.
>> The skb has proper references and is NOT de-referenced because
>> __skb_datagram_iter() detects that the length is zero and returns EFAULT.
> 
> It's dereferenced as UNIXCB(skb).consumed first in
> unix_stream_read_actor().
> 

That does not matter as the skb still has a refernce. That is why I 
asked you to print the reference count.

> Then, 1 byte of data is copied without -EFAULT because
> unix_stream_recv_urg() always passes 1 as chunk (size) to
> recv_actor().

Can you verify this because IIRC it is not de-refernced. AFAIK, KASAN 
does nothing that would cause returning EFAULT and if KASAN does spot 
this illegal access why is it not pancing the system or producing a report.

This is where we disagree.

Shoaib

> 
> That's why I said KASAN should be working on your setup and suggested
> running the repro with/without KASAN.  If KASAN is turned off, single
> byte garbage is copied from the freed area.
> 
> See the last returned values below
> 
> Without KASAN:
> 
> ---8<---
> write(1, "executing program\n", 18
> executing program
> )     = 18
> socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
> sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT
> [   15.657345] queued OOB: ff1100000442c700
> ) = 1
> recvmsg(3,
> [   15.657793] reading OOB: ff1100000442c700
> {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
> sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE
> [   15.659830] queued OOB: ff1100000442c300
> ) = 1
> recvfrom(3,
> [   15.660272] free skb: ff1100000442c300
> "\21", 125, MSG_DONTROUTE|MSG_TRUNC, NULL, NULL) = 1
> recvmsg(3,
> [   15.661014] reading OOB: ff1100000442c300
> {msg_namelen=0, MSG_OOB|MSG_ERRQUEUE) = 1
> ---8<---
> 
> 
> With KASAN:
> 
> ---8<---
> socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
> sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT
> [  134.735962] queued OOB: ff110000099f0b40
> ) = 1
> recvmsg(3,
> [  134.736460] reading OOB: ff110000099f0b40
> {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
> sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE
> [  134.738554] queued OOB: ff110000099f0c80
> ) = 1
> recvfrom(3,
> [  134.739086] free skb: ff110000099f0c80
> "\21", 125, MSG_DONTROUTE|MSG_TRUNC, NULL, NULL) = 1
> recvmsg(3,
> [  134.739792] reading OOB: ff110000099f0c80
>   {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)
> ---8<---
> 
> 
>>
>> See more below
>>>
>>> ---8<---
>>> # ./oob
>>> executing program
>>> [   25.773750] queued OOB: ff1100000947ba40
>>> [   25.774110] reading OOB: ff1100000947ba40
>>> [   25.774401] queued OOB: ff1100000947bb80
>>> [   25.774669] free skb: ff1100000947bb80
>>> [   25.774919] reading OOB: ff1100000947bb80
>>> [   25.775172] ==================================================================
>>> [   25.775654] BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0x86/0xb0
>>> ---8<---
>>>
>>> ---8<---
>>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>>> index a1894019ebd5..ccd9c47160a5 100644
>>> --- a/net/unix/af_unix.c
>>> +++ b/net/unix/af_unix.c
>>> @@ -2230,6 +2230,7 @@ static int queue_oob(struct socket *sock, struct msghdr *msg, struct sock *other
>>>    	__skb_queue_tail(&other->sk_receive_queue, skb);
>>>    	spin_unlock(&other->sk_receive_queue.lock);
>>>    
>>> +	printk(KERN_ERR "queued OOB: %px\n", skb);
>>>    	sk_send_sigurg(other);
>>>    	unix_state_unlock(other);
>>>    	other->sk_data_ready(other);
>>> @@ -2637,6 +2638,7 @@ static int unix_stream_recv_urg(struct unix_stream_read_state *state)
>>>    	spin_unlock(&sk->sk_receive_queue.lock);
>>>    	unix_state_unlock(sk);
>>>    
>>> +	printk(KERN_ERR "reading OOB: %px\n", oob_skb);
>>>    	chunk = state->recv_actor(oob_skb, 0, chunk, state);
>>>    
>>>    	if (!(state->flags & MSG_PEEK))
>>> @@ -2915,7 +2917,7 @@ static int unix_stream_read_generic(struct unix_stream_read_state *state,
>>>    
>>>    			skb_unlink(skb, &sk->sk_receive_queue);
>>>    			consume_skb(skb);
>>> -
>>> +			printk(KERN_ERR "free skb: %px\n", skb);
>>
>> This printk is wrongly placed
> 
> It's not, because this just prints the address of OOB skb just after
> it's illegally consumed without MSG_OOB.  The code is only called
> for the illegal OOB during the repro.
> 
> 
>> because the skb has been freed above, but
>> since it is just printing the pointer it should be OK, access to any skb
>> field will be an issue. You should move this printk to before
>> unix_stream_read_generic and print the refcnt on the skb and the length
>> of the data and verify what I am saying, that the skb has one refcnt and
>> zero length.
> 
> Note this is on top of net-next where no additional refcnt is taken
> for OOB, so no need to print skb's refcnt.  Also the length is not
> related because chunk is always 1.
> 
> 
>> This is the kind of interaction I was looking for. If I have missed
>> something please be patient and let me know.
>>
>> Regards,
>>
>> Shoaib

Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.shoaib@oracle.com>
Date: Tue, 10 Sep 2024 16:42:33 -0700
> On 9/10/2024 3:59 PM, Kuniyuki Iwashima wrote:
> > From: Shoaib Rao <rao.shoaib@oracle.com>
> > Date: Tue, 10 Sep 2024 15:30:08 -0700
> >> My fellow engineer let's first take a breath and calm down. We both are
> >> trying to do the right thing. Now read my comments below and if I still
> >> don't get it, please be patient, maybe I am not as smart as you are.
> >>
> >> On 9/10/2024 2:53 PM, Kuniyuki Iwashima wrote:
> >>> From: Shoaib Rao <rao.shoaib@oracle.com>
> >>> Date: Tue, 10 Sep 2024 13:57:04 -0700
> >>>> The commit Message:
> >>>>
> >>>> syzbot reported use-after-free in unix_stream_recv_urg(). [0]
> >>>>
> >>>> The scenario is
> >>>>
> >>>>      1. send(MSG_OOB)
> >>>>      2. recv(MSG_OOB)
> >>>>         -> The consumed OOB remains in recv queue
> >>>>      3. send(MSG_OOB)
> >>>>      4. recv()
> >>>>         -> manage_oob() returns the next skb of the consumed OOB
> >>>>         -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared
> >>>>      5. recv(MSG_OOB)
> >>>>         -> unix_sk(sk)->oob_skb is used but already freed
> >>>
> >>> How did you miss this ?
> >>>
> >>> Again, please read my patch and mails **carefully**.
> >>>
> >>> unix_sk(sk)->oob_sk wasn't cleared properly and illegal access happens
> >>> in unix_stream_recv_urg(), where ->oob_skb is dereferenced.
> >>>
> >>> Here's _technical_ thing that you want.
> >>
> >> This is exactly what I am trying to point out to you.
> >> The skb has proper references and is NOT de-referenced because
> >> __skb_datagram_iter() detects that the length is zero and returns EFAULT.
> > 
> > It's dereferenced as UNIXCB(skb).consumed first in
> > unix_stream_read_actor().
> > 
> 
> That does not matter as the skb still has a refernce. That is why I 
> asked you to print the reference count.

It does matter.  Please read carefully again...


> > Then, 1 byte of data is copied without -EFAULT because
> > unix_stream_recv_urg() always passes 1 as chunk (size) to
> > recv_actor().
> 
> Can you verify this because IIRC it is not de-refernced. AFAIK, KASAN 
> does nothing that would cause returning EFAULT and if KASAN does spot 
> this illegal access why is it not pancing the system or producing a report.
> 
> This is where we disagree.

The returned value from recv_actor() was exact 1 when KASAN was off.
It was -EFAULT only when KASAN was on.

Anyway, -EFAULT is not that important and I'm not so interested in how
KASAN triggers that.  What's important is the fact that the first UAF
is UNIXCB() and the bug happens before that.

[...]
> > Note this is on top of net-next where no additional refcnt is taken
> > for OOB

Also in my patch:

  The recent commit 8594d9b85c07 ("af_unix: Don't call skb_get() for OOB
  skb.") uncovered the issue.