linux-kernel - Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Jul 2018 00:26:03 +0900
From:   OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:     Anatoly Trosinenko <anatoly.trosinenko@...il.com>
Cc:     viro@...iv.linux.org.uk, akpm@...ux-foundation.org,
        linux-kernel@...r.kernel.org
Subject: Re: FAT: Operating on broken FAT FS causes the write syscall to return negative number not equal to -1

Anatoly Trosinenko <anatoly.trosinenko@...il.com> writes:

>> This patch returns better error (-EIO) for me.
>
> This works for me likewise.

Thanks for testing.

>> (But note, the corrupted FS image doesn't guarantee POSIX behavior.)
>
> Oops, I was just doing some testing and thought that correct behavior
> for crafted FS is to return arbitrary valid error code (like -EIO) or
> some arbitrary data, say, not larger than FS (not disclosing the
> kernel memory, of course). Please excuse me if I was wrong. If fixing
> this would slow down some hot code path, then I am not insisting on
> returning valid errno. :)
>
> Meanwhile, how should be considered such discrepancies with man pages
> for invalid FS images: should it be considered low priority bug,
> not-a-bug or feature request (diagnostics)?

To handle the corrupted image _perfectly_, finally we will have to have
online fsck or similar.

For example, if the data block was shared between the regular file and
directory, user can mmap the directory data via (corrupted) regular
file.

Then locking of directory handler doesn't work, and handler has to have
directory data as volatile data (and validate data for each memory
load). And to verify this invalid shared data blocks, we will have to
read all inodes (i.e. almost fsck).

So, I may change the code if data verification is easy and lightweight
like in this case. But like said above, it will not be guaranteed.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>