[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+881138...@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 syzk...@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

[Eric Dumazet]

Another af_unix OOB issue.

Rao can you take a look ?

Thanks.

[Shoaib Rao]

On 9/4/2024 8:32 AM, Eric Dumazet wrote:
> On Wed, Sep 4, 2024 at 5:13 PM syzbot
> <syzbot+881138...@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$

>> 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 syzk...@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

[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);

[syzbot]

Hello,

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

Reported-by: syzbot+881138...@syzkaller.appspotmail.com
Tested-by: syzbot+881138...@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.

[Kuniyuki Iwashima]

From: Lizhi Xu <lizh...@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

[Shoaib Rao]

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

[syzbot]

Hello,

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

Reported-by: syzbot+881138...@syzkaller.appspotmail.com
Tested-by: syzbot+881138...@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

[Eric Dumazet]

On Thu, Sep 5, 2024 at 9:35 AM Shoaib Rao <rao.s...@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

[Shoaib Rao]

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

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.s...@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...@amazon.com/

[Shoaib Rao]

> https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240...@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

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.s...@oracle.com>
Date: Thu, 5 Sep 2024 13:15:18 -0700

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.

[Shoaib Rao]

Can you provide the full test case that you used to reproduce the issue.

Thanks,

Shoaib

[Shoaib Rao]

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

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.s...@oracle.com>
Date: Thu, 5 Sep 2024 13:37:06 -0700

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

[Shoaib Rao]

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

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.s...@oracle.com>
Date: Thu, 5 Sep 2024 13:48:16 -0700

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/00000000000064...@google.com/

[Hillf Danton]

On Wed, 04 Sep 2024 08:13:24 -0700

> syzbot found the following issue on:
>
> HEAD commit: fbdaffe41adc Merge branch 'am-qt2025-phy-rust'
> git tree: net-next

> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16d3fc53980000

#syz test

--- x/net/unix/af_unix.c
+++ y/net/unix/af_unix.c
@@ -2634,6 +2634,7 @@ static int unix_stream_recv_urg(struct u
if (!(state->flags & MSG_PEEK))
WRITE_ONCE(u->oob_skb, NULL);

+ __skb_unlink(oob_skb, &sk->sk_receive_queue);
spin_unlock(&sk->sk_receive_queue.lock);
unix_state_unlock(sk);

--

[syzbot]

Hello,

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

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

Tested on:

commit: 22d6adac Merge branch 'add-driver-for-motorcomm-yt8821..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1133d5b7980000
kernel config: https://syzkaller.appspot.com/x/.config?x=b4222042d2d7e932

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=11f6b163980000

[Eric Dumazet]

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).

[Shoaib Rao]

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

[Shoaib Rao]

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

[Kuniyuki Iwashima]

From: Shoaib Rao <rao.s...@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);
> +}

[...]