KASAN: use-after-free Read in ext4_xattr_set_entry

28 views
Skip to first unread message

syzbot

unread,
Jun 25, 2019, 11:30:05 PM6/25/19
Hello,

syzbot found the following crash on:

HEAD commit: aec3002d Linux 4.19.56
git tree: linux-4.19.y
console output: https://syzkaller.appspot.com/x/log.txt?x=17ba8ceea00000
kernel config: https://syzkaller.appspot.com/x/.config?x=48b721ea0070d1cd
dashboard link: https://syzkaller.appspot.com/bug?extid=1634adac0cb6d2d930ef
compiler: gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: [email protected]

EXT4-fs error (device sda1): ext4_xattr_set_entry:1607: inode #16813: comm
syz-fuzzer: corrupted xattr entries
EXT4-fs error (device sda1): ext4_xattr_set_entry:1607: inode #16813: comm
syz-fuzzer: corrupted xattr entries
EXT4-fs error (device sda1): ext4_xattr_set_entry:1607: inode #16813: comm
syz-fuzzer: corrupted xattr entries
==================================================================
BUG: KASAN: use-after-free in memmove include/linux/string.h:363 [inline]
BUG: KASAN: use-after-free in ext4_xattr_set_entry+0xbf7/0x3770
fs/ext4/xattr.c:1738
Read of size 4 at addr ffff8880884d9ffe by task syz-fuzzer/8041

CPU: 0 PID: 8041 Comm: syz-fuzzer Not tainted 4.19.56 #28
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report mm/kasan/report.c:412 [inline]
kasan_report.cold+0x8c/0x2ba mm/kasan/report.c:396
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x123/0x190 mm/kasan/kasan.c:267
memmove+0x24/0x50 mm/kasan/kasan.c:293
memmove include/linux/string.h:363 [inline]
ext4_xattr_set_entry+0xbf7/0x3770 fs/ext4/xattr.c:1738
ext4_xattr_ibody_set+0x89/0x2c0 fs/ext4/xattr.c:2240
ext4_xattr_set_handle+0x5d2/0x1010 fs/ext4/xattr.c:2396
ext4_initxattrs+0xc0/0x130 fs/ext4/xattr_security.c:43
security_inode_init_security security/security.c:502 [inline]
security_inode_init_security+0x2c8/0x3b0 security/security.c:475
ext4_init_security+0x34/0x40 fs/ext4/xattr_security.c:57
__ext4_new_inode+0x3b2a/0x52c0 fs/ext4/ialloc.c:1160
ext4_mkdir+0x3d5/0xdf0 fs/ext4/namei.c:2629
vfs_mkdir+0x42e/0x690 fs/namei.c:3816
do_mkdirat+0x234/0x2a0 fs/namei.c:3839
__do_sys_mkdirat fs/namei.c:3850 [inline]
__se_sys_mkdirat fs/namei.c:3848 [inline]
__x64_sys_mkdirat+0x76/0xb0 fs/namei.c:3848
do_syscall_64+0xfd/0x620 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x47c4a0
Code: 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 49 c7 c2 00 00 00 00 49 c7
c0 00 00 00 00 49 c7 c1 00 00 00 00 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff
ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30
RSP: 002b:000000c4214f35c0 EFLAGS: 00000206 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000047c4a0
RDX: 00000000000001c0 RSI: 000000c4211522c0 RDI: ffffffffffffff9c
RBP: 000000c4214f3620 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000206 R12: ffffffffffffffff
R13: 0000000000000017 R14: 0000000000000016 R15: 0000000000000100

The buggy address belongs to the page:
page:ffffea0002213640 count:2 mapcount:0 mapping:ffff8880a6d53418
index:0x43c
flags: 0x1fffc0000001074(referenced|dirty|lru|active|private)
raw: 01fffc0000001074 ffffea0002423fc8 ffffea0001ea0f08 ffff8880a6d53418
raw: 000000000000043c ffff888052c98e70 00000002ffffffff ffff88806000c900
page dumped because: kasan: bad access detected
page->mem_cgroup:ffff88806000c900

Memory state around the buggy address:
ffff8880884d9f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880884d9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8880884da000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff8880884da080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff8880884da100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================


---
This bug 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 [email protected].

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

syzbot

unread,
Dec 13, 2019, 3:49:09 PM12/13/19
syzbot has found a reproducer for the following crash on:

HEAD commit: 312017a4 Linux 4.19.89
git tree: linux-4.19.y
console output: https://syzkaller.appspot.com/x/log.txt?x=16e05cfae00000
kernel config: https://syzkaller.appspot.com/x/.config?x=67c148d572dbab48
dashboard link: https://syzkaller.appspot.com/bug?extid=1634adac0cb6d2d930ef
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=115aa1a6e00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: [email protected]

IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready
IPv6: ADDRCONF(NETDEV_UP): veth1_to_team: link is not ready
IPv6: ADDRCONF(NETDEV_UP): vxcan0: link is not ready
IPv6: ADDRCONF(NETDEV_UP): veth1_to_hsr: link is not ready
==================================================================
BUG: KASAN: use-after-free in ext4_xattr_set_entry+0x35e0/0x3770
fs/ext4/xattr.c:1604
Read of size 4 at addr ffff88807a263083 by task syz-executor.2/7742

CPU: 1 PID: 7742 Comm: syz-executor.2 Not tainted 4.19.89-syzkaller #0
IPv6: ADDRCONF(NETDEV_UP): veth0_to_hsr: link is not ready
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
IPv6: ADDRCONF(NETDEV_UP): veth1_to_hsr: link is not ready
Call Trace:
hsr0: Slave A (hsr_slave_0) is not up; please bring it up to get a fully
working HSR network
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x197/0x210 lib/dump_stack.c:118
hsr0: Slave B (hsr_slave_1) is not up; please bring it up to get a fully
working HSR network
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:256
IPv6: ADDRCONF(NETDEV_UP): hsr0: link is not ready
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report mm/kasan/report.c:412 [inline]
kasan_report.cold+0x8c/0x2ba mm/kasan/report.c:396
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
ext4_xattr_set_entry+0x35e0/0x3770 fs/ext4/xattr.c:1604
IPv6: ADDRCONF(NETDEV_UP): vxcan0: link is not ready
IPv6: ADDRCONF(NETDEV_UP): vxcan1: link is not ready
8021q: adding VLAN 0 to HW filter on device batadv0
ext4_xattr_ibody_set+0x89/0x2c0 fs/ext4/xattr.c:2240
ext4_xattr_set_handle+0x5d2/0x1010 fs/ext4/xattr.c:2396
ext4_initxattrs+0xc0/0x130 fs/ext4/xattr_security.c:43
security_inode_init_security security/security.c:502 [inline]
security_inode_init_security+0x2c8/0x3b0 security/security.c:475
ext4_init_security+0x34/0x40 fs/ext4/xattr_security.c:57
__ext4_new_inode+0x3b2f/0x52d0 fs/ext4/ialloc.c:1160
EXT4-fs error (device sda1): ext4_xattr_ibody_get:591: inode #16514: comm
syz-executor.0: corrupted in-inode xattr
IPv6: ADDRCONF(NETDEV_UP): vxcan1: link is not ready
ext4_symlink+0x3f8/0xbe0 fs/ext4/namei.c:3125
vfs_symlink fs/namei.c:4126 [inline]
vfs_symlink+0x373/0x5c0 fs/namei.c:4112
do_symlinkat+0x22b/0x290 fs/namei.c:4153
8021q: adding VLAN 0 to HW filter on device batadv0
__do_sys_symlink fs/namei.c:4172 [inline]
__se_sys_symlink fs/namei.c:4170 [inline]
__x64_sys_symlink+0x59/0x80 fs/namei.c:4170
do_syscall_64+0xfd/0x620 arch/x86/entry/common.c:293
EXT4-fs error (device sda1): ext4_xattr_set_entry:1607: inode #16520: comm
syz-executor.3: corrupted xattr entries
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45a637
Code: 0f 1f 00 b8 5c 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 6d b9 fb ff c3
66 2e 0f 1f 84 00 00 00 00 00 66 90 b8 58 00 00 00 0f 05 <48> 3d 01 f0 ff
ff 0f 83 4d b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffc19bc9ba8 EFLAGS: 00000202 ORIG_RAX: 0000000000000058
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000045a637
RDX: 00007ffc19bc9c47 RSI: 00000000004c0369 RDI: 00007ffc19bc9c30
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000017
R10: 0000000000000075 R11: 0000000000000202 R12: 0000000000000001
R13: 00007ffc19bc9be0 R14: 0000000000000000 R15: 00007ffc19bc9bf0

The buggy address belongs to the page:
page:ffffea0001e898c0 count:0 mapcount:0 mapping:0000000000000000 index:0x1
flags: 0xfffe0000000000()
raw: 00fffe0000000000 ffffea0001e89c48 ffffea0001e80848 0000000000000000
raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff88807a262f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88807a263000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff88807a263080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff88807a263100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff88807a263180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_team: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): team_slave_1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_hsr: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0_to_hsr: link becomes ready
EXT4-fs error (device sda1): ext4_xattr_ibody_get:591: inode #16514: comm
syz-executor.0: corrupted in-inode xattr
IPv6: ADDRCONF(NETDEV_CHANGE): hsr_slave_0: link becomes ready
EXT4-fs error (device sda1): ext4_xattr_ibody_get:591: inode #16512: comm
syz-executor.1: corrupted in-inode xattr
IPv6: ADDRCONF(NETDEV_CHANGE): veth1_to_hsr: link becomes ready

syzbot

unread,
Mar 30, 2020, 6:23:03 AM3/30/20
syzbot suspects this bug was fixed by commit:

commit cb1702c403ad392a9ae6e090702a17cca98a38ca
Author: Theodore Ts'o <[email protected]>
Date: Sun Dec 15 06:09:03 2019 +0000

ext4: validate the debug_want_extra_isize mount option at parse time

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=146fd5a3e00000
start commit: 312017a4 Linux 4.19.89
git tree: linux-4.19.y
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=115aa1a6e00000

If the result looks correct, please mark the bug fixed by replying with:

#syz fix: ext4: validate the debug_want_extra_isize mount option at parse time

For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Reply all
Reply to author
Forward
0 new messages