lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 8 May 2018 21:48:54 -0500 From: Eric Sandeen <sandeen@...deen.net> To: Dmitry Vyukov <dvyukov@...gle.com> Cc: "Darrick J. Wong" <darrick.wong@...cle.com>, Dave Chinner <david@...morbit.com>, syzbot <syzbot+84a67953651a971809ba@...kaller.appspotmail.com>, LKML <linux-kernel@...r.kernel.org>, linux-xfs@...r.kernel.org, syzkaller-bugs <syzkaller-bugs@...glegroups.com>, Theodore Ts'o <tytso@....edu>, syzkaller <syzkaller@...glegroups.com> Subject: Re: WARNING: bad unlock balance in xfs_iunlock On 5/8/18 2:52 AM, Dmitry Vyukov wrote: >> Or put another way, how did you arrive at the fs image values in the reproducer, >> i.e.: > Currently they are completely random, nobody taught syzkaller about AGFs, etc. So you just combine a few megabytes of purely random bits out of thin air until you get something that approximates an xfs filesystem? Google must have more computing power than I was aware of. -Eric >> oid loop() >> { >> memcpy((void*)0x20000000, "xfs", 4); >> memcpy((void*)0x20000100, "./file0", 8); >> *(uint64_t*)0x20000200 = 0x20010000; >> memcpy((void*)0x20010000, >> "\x58\x46\x53\x42\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00" >> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x9f\x98" >> "\x99\xff\xcb\xa1\x4e\xe6\xad\x52\x08\x20\x67\x09\xed\x75\x00\x00\x00" >> "\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x35\xe0\x00\x00\x00\x00" >> "\x00\x00\x35\xe1\x00\x00\x00\x00\x00\x00\x35\xe2\x00\x00\x00\x01\x00" >> "\x00\x10\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x03\x55\xb4\xa4" >> "\x02\x00\x01\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" >> "\x00\x0c\x09\x08\x04\x0c\x00\x00\x19\x00\x00\x00\x00\x00\x00\x00\x40" >> "\x00\x00\x00\x00\x00\x00\x00\x3d\x00\x00\x00\x00\x00\x00\x0c\xa3\x00" >> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" >> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00" >> "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x02\x02", >> 204); >> >> ... >> >> The in-memory xfs filesystem it constructs is damaged, is that an intentional >> part of the fuzzing during the test? > Yes, invalid inputs is part of testing.
Powered by blists - more mailing lists