All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+26860029a4d562566231@syzkaller.appspotmail.com>
To: hdanton@sina.com, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [btrfs?] KASAN: slab-use-after-free Read in btrfs_open_devices
Date: Thu, 10 Aug 2023 06:05:33 -0700	[thread overview]
Message-ID: <0000000000005e47e0060291407c@google.com> (raw)
In-Reply-To: <20230810124552.2335-1-hdanton@sina.com>

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: use-after-free Read in btrfs_test_super

==================================================================
BUG: KASAN: use-after-free in btrfs_test_super+0x9b/0xa0 fs/btrfs/super.c:1346
Read of size 8 at addr ffff88802a975110 by task syz-executor.3/5661

CPU: 1 PID: 5661 Comm: syz-executor.3 Not tainted 6.5.0-rc5-next-20230807-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:364 [inline]
 print_report+0xc4/0x620 mm/kasan/report.c:475
 kasan_report+0xda/0x110 mm/kasan/report.c:588
 btrfs_test_super+0x9b/0xa0 fs/btrfs/super.c:1346
 sget+0x3de/0x610 fs/super.c:663
 btrfs_mount_root+0x220/0xd50 fs/btrfs/super.c:1475
 legacy_get_tree+0x109/0x220 fs/fs_context.c:611
 vfs_get_tree+0x88/0x350 fs/super.c:1544
 fc_mount fs/namespace.c:1112 [inline]
 vfs_kern_mount.part.0+0xcb/0x170 fs/namespace.c:1142
 vfs_kern_mount+0x3f/0x60 fs/namespace.c:1129
 btrfs_mount+0x292/0xb10 fs/btrfs/super.c:1578
 legacy_get_tree+0x109/0x220 fs/fs_context.c:611
 vfs_get_tree+0x88/0x350 fs/super.c:1544
 do_new_mount fs/namespace.c:3335 [inline]
 path_mount+0x1492/0x1ed0 fs/namespace.c:3662
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount fs/namespace.c:3861 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f0d83a7e1ea
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 de 09 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f0d847a2ee8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f0d847a2f80 RCX: 00007f0d83a7e1ea
RDX: 00000000200051c0 RSI: 0000000020005200 RDI: 00007f0d847a2f40
RBP: 00000000200051c0 R08: 00007f0d847a2f80 R09: 0000000001000008
R10: 0000000001000008 R11: 0000000000000246 R12: 0000000020005200
R13: 00007f0d847a2f40 R14: 00000000000051ab R15: 0000000020000280
 </TASK>

The buggy address belongs to the physical page:
page:ffffea0000aa5d40 refcount:0 mapcount:0 mapping:0000000000000000 index:0x4 pfn:0x2a975
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000000 0000000000000000 ffffffff00000201 0000000000000000
raw: 0000000000000004 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 2, migratetype Unmovable, gfp_mask 0x152dc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5641, tgid 5640 (syz-executor.0), ts 80709504641, free_ts 80731761534
 set_page_owner include/linux/page_owner.h:31 [inline]
 post_alloc_hook+0x2d2/0x350 mm/page_alloc.c:1567
 prep_new_page mm/page_alloc.c:1574 [inline]
 get_page_from_freelist+0x10d7/0x31b0 mm/page_alloc.c:3253
 __alloc_pages+0x1d0/0x4a0 mm/page_alloc.c:4509
 __alloc_pages_node include/linux/gfp.h:237 [inline]
 alloc_pages_node include/linux/gfp.h:260 [inline]
 __kmalloc_large_node+0x87/0x1c0 mm/slab_common.c:1164
 __do_kmalloc_node mm/slab_common.c:1011 [inline]
 __kmalloc_node.cold+0x5/0xdd mm/slab_common.c:1030
 kmalloc_node include/linux/slab.h:619 [inline]
 kvmalloc_node+0x6f/0x1a0 mm/util.c:604
 kvmalloc include/linux/slab.h:737 [inline]
 kvzalloc include/linux/slab.h:745 [inline]
 btrfs_mount_root+0xe8/0xd50 fs/btrfs/super.c:1461
 legacy_get_tree+0x109/0x220 fs/fs_context.c:611
 vfs_get_tree+0x88/0x350 fs/super.c:1544
 fc_mount fs/namespace.c:1112 [inline]
 vfs_kern_mount.part.0+0xcb/0x170 fs/namespace.c:1142
 vfs_kern_mount+0x3f/0x60 fs/namespace.c:1129
 btrfs_mount+0x292/0xb10 fs/btrfs/super.c:1578
 legacy_get_tree+0x109/0x220 fs/fs_context.c:611
 vfs_get_tree+0x88/0x350 fs/super.c:1544
 do_new_mount fs/namespace.c:3335 [inline]
 path_mount+0x1492/0x1ed0 fs/namespace.c:3662
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount fs/namespace.c:3861 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
page last free stack trace:
 reset_page_owner include/linux/page_owner.h:24 [inline]
 free_pages_prepare mm/page_alloc.c:1158 [inline]
 free_unref_page_prepare+0x508/0xb90 mm/page_alloc.c:2380
 free_unref_page+0x33/0x3b0 mm/page_alloc.c:2475
 kvfree+0x47/0x50 mm/util.c:650
 btrfs_mount_root+0x591/0xd50 fs/btrfs/super.c:1535
 legacy_get_tree+0x109/0x220 fs/fs_context.c:611
 vfs_get_tree+0x88/0x350 fs/super.c:1544
 fc_mount fs/namespace.c:1112 [inline]
 vfs_kern_mount.part.0+0xcb/0x170 fs/namespace.c:1142
 vfs_kern_mount+0x3f/0x60 fs/namespace.c:1129
 btrfs_mount+0x292/0xb10 fs/btrfs/super.c:1578
 legacy_get_tree+0x109/0x220 fs/fs_context.c:611
 vfs_get_tree+0x88/0x350 fs/super.c:1544
 do_new_mount fs/namespace.c:3335 [inline]
 path_mount+0x1492/0x1ed0 fs/namespace.c:3662
 do_mount fs/namespace.c:3675 [inline]
 __do_sys_mount fs/namespace.c:3884 [inline]
 __se_sys_mount fs/namespace.c:3861 [inline]
 __x64_sys_mount+0x293/0x310 fs/namespace.c:3861
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Memory state around the buggy address:
 ffff88802a975000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88802a975080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff88802a975100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                         ^
 ffff88802a975180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88802a975200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


Tested on:

commit:         f7dc24b3 Add linux-next specific files for 20230807
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
console output: https://syzkaller.appspot.com/x/log.txt?x=14a2c5aba80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=d7847c9dca13d6c5
dashboard link: https://syzkaller.appspot.com/bug?extid=26860029a4d562566231
compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=128199aba80000


       reply	other threads:[~2023-08-10 13:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230810124552.2335-1-hdanton@sina.com>
2023-08-10 13:05 ` syzbot [this message]
     [not found] <20230810141207.2398-1-hdanton@sina.com>
2023-08-10 15:03 ` [syzbot] [btrfs?] KASAN: slab-use-after-free Read in btrfs_open_devices syzbot
     [not found] <20230810104550.2217-1-hdanton@sina.com>
2023-08-10 11:05 ` syzbot
     [not found] <20230809110318.2110-1-hdanton@sina.com>
2023-08-09 14:22 ` syzbot
     [not found] <20230808232313.2035-1-hdanton@sina.com>
2023-08-08 23:38 ` syzbot
     [not found] <20230808140807.1967-1-hdanton@sina.com>
2023-08-08 14:30 ` syzbot
2023-08-07 20:51 syzbot
2023-08-08  3:24 ` syzbot
2023-08-08 15:50   ` Christian Brauner
2023-08-08 16:01     ` Christoph Hellwig
2023-08-08 16:35       ` Christian Brauner
2023-08-08 17:22         ` Christoph Hellwig
2023-08-08 17:38       ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0000000000005e47e0060291407c@google.com \
    --to=syzbot+26860029a4d562566231@syzkaller.appspotmail.com \
    --cc=hdanton@sina.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.