From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934318AbeEIInd (ORCPT ); Wed, 9 May 2018 04:43:33 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:42928 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934326AbeEIIn0 (ORCPT ); Wed, 9 May 2018 04:43:26 -0400 X-Google-Smtp-Source: AB8JxZoY3VJ2j8Wi/ZxSAPMye1LbdiYflmN2s5mKs2SyCL8+OQJHX+TB841gmobphnKdc8LBU1MmtzBMXFg2zmU6eWs= MIME-Version: 1.0 In-Reply-To: <9adacfed-0de6-cb94-bf14-3e639678a02a@sandeen.net> References: <20180403043854.GL1150@dastard> <20180405213844.GE23861@dastard> <20180406161053.GF7500@magnolia> <95c1400b-94f2-1af4-2d5d-c61c274c28ff@sandeen.net> <9f8d657c-7f42-7bd9-4477-6c3addf16dee@sandeen.net> <9adacfed-0de6-cb94-bf14-3e639678a02a@sandeen.net> From: Dmitry Vyukov Date: Wed, 9 May 2018 10:43:05 +0200 Message-ID: Subject: Re: WARNING: bad unlock balance in xfs_iunlock To: Eric Sandeen Cc: "Darrick J. Wong" , Dave Chinner , syzbot , LKML , linux-xfs@vger.kernel.org, syzkaller-bugs , "Theodore Ts'o" , syzkaller Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 9, 2018 at 4:48 AM, Eric Sandeen wrote: > > > 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. syzbot uses very few cores for fuzzing of all of the hundreds of kernel subsystems. But syzkaller (the underlying fuzzer) uses coverage-guidance and this makes fuzzing exponentially more efficient than blind techniques. Coverage-guidance is also combined with grammar-based generation techniques, which gives additional synergy (though there are no grammar descriptions for filesystem formats at the moment). Does "xfstests fuzzing infrastructure" use coverage-guidance? If not, it would be useful to add. Among some solutions there are LibFuzzer (https://llvm.org/docs/LibFuzzer.html), AFL (http://lcamtuf.coredump.cx/afl/), kernel-fuzzing (https://github.com/oracle/kernel-fuzzing). I don't know how xfstests fuzzing works, so I can't say what would be more suitable there. >>> 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. >