From: Sami Liedes <sami.liedes@iki.fi>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Intentionally corrupted vfat fs causing BUG
Date: Sun, 12 Oct 2014 23:40:45 +0300 [thread overview]
Message-ID: <20141012204045.GA12577@sli.dy.fi> (raw)
In-Reply-To: <CAFLxGvxiP8mUK4Kjm1p9m5J=d5qNpcpXuJddkRVFkc++BFFnFg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]
On Sun, Oct 12, 2014 at 09:04:19PM +0200, Richard Weinberger wrote:
> You misunderstood Sami's issue. He corrupted the vfat fs intentionally
> to find issues
> in the vfat driver.
> And as he reports he found an nasty issue.
> Any user can trigger a BUG_ON() using a crafted vfat image.
> Please note, if you mount exactly the same image using msdos fs the issue
> does not occur.
Yeah, you can think of it as either a security issue if you wish, or
just as a plain old robustness issue in the age of unreliable USB
sticks etc. in that it just would be more ideal to fail gracefully
instead of crashing.
Anyway, I'm not advocating for any measure of severity (I leave that
to others); I just find and report these in the hope that someone
finds the reports useful. I personally view these more as robustness
than security bugs at the moment, but certainly they can be seen as
either.
And if some of these get fixed, I will rerun the tests, so I might
produce a daunting stream of reports. I know it would be nicer to
report everything at once, but usually the issues found first are
prevalent enough to mask other issues.
By the way, I find it interesting that once I implemented a tool to
minimize the differences between a bad fs and a good fs, every bug I
have found in any filesystem implementation has minimized to a single
bit flip. That suggests to me that fuzz testing is probably not very
effective in finding bugs that require more than that.
Sami
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-10-12 20:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-10 20:57 Intentionally corrupted vfat fs causing BUG Sami Liedes
2014-10-11 10:20 ` Richard Weinberger
2014-10-12 12:08 ` OGAWA Hirofumi
2014-10-12 19:04 ` Richard Weinberger
2014-10-12 20:40 ` Sami Liedes [this message]
2014-10-13 7:57 ` OGAWA Hirofumi
2014-10-13 8:22 ` Richard Weinberger
2014-10-13 8:35 ` OGAWA Hirofumi
2014-10-13 8:39 ` Richard Weinberger
2014-10-13 8:59 ` OGAWA Hirofumi
2014-10-13 14:36 ` Richard Weinberger
2014-10-19 16:36 ` Richard Weinberger
2014-10-23 15:28 ` OGAWA Hirofumi
2014-10-23 16:01 ` Al Viro
2014-10-23 16:16 ` Al Viro
2014-10-23 16:45 ` OGAWA Hirofumi
2014-10-23 16:50 ` OGAWA Hirofumi
2014-10-23 16:55 ` Richard Weinberger
2014-10-23 16:55 ` Al Viro
2014-10-23 17:21 ` Al Viro
2014-10-23 17:58 ` OGAWA Hirofumi
2014-10-23 20:46 ` Sami Liedes
2014-10-23 17:35 ` OGAWA Hirofumi
2014-10-23 17:54 ` J. Bruce Fields
2014-10-23 18:05 ` Al Viro
2014-10-23 18:16 ` J. Bruce Fields
2014-10-23 16:56 ` Al Viro
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=20141012204045.GA12577@sli.dy.fi \
--to=sami.liedes@iki.fi \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=richard.weinberger@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).