linux-kernel - Re: Possible ext2/3/4 filesysystem iov_length integer overflow and strange behavior on large writes

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] [day] [month] [year] [list]

Message-ID: <CA+55aFyDwAQE5ig6+yqzcVphGcrarVG2eP_aMyPxpzGo25s+VA@mail.gmail.com>
Date:	Sat, 16 Jul 2011 21:39:28 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Ted Ts'o" <tytso@....edu>, halfdog <me@...fdog.net>,
	linux-kernel@...r.kernel.org
Subject: Re: Possible ext2/3/4 filesysystem iov_length integer overflow and
 strange behavior on large writes

On Sat, Jul 16, 2011 at 2:16 PM, Ted Ts'o <tytso@....edu> wrote:
>
> Your questions about what happens if someone is trying to perform a
> Denial of Service attack and send a writev of 1 TB is a interesting
> one.

We *should* be pretty good about this at the VFS layer at least, since
we tend to use things like "lock_page_killable()" and friends. IOW,
the thing may not be "interruptible" in the sense that we don't allow
signals (for all the historical reasons: user programs *should* be
able to handle interrupted file accesses since they do happen with NFS
if you mount things with "-o intr" etc, but nobody has really dared
say that it can happen in general). But we generally allow a signal
that kills a process to interrupt a read or write.

There may be cases where we don't do the "_killable()" version,
though. And filesystems that do their own routines (eg writes on
filesystems with logs etc) rather than use the VFS helper ones would
be more likely to have that issue.

Of course, we already say "screw posix" if somebody tries to write
really big chunks, and the VFS layer will say "I will truncate writes
bigger than 2GB, and better handle partial writes if you do big
chunks". That's partly due to security issues with drivers/filesystems
with overflow issues, and partly just because anything else would be
crazy. We could easily also say that "big writes are always
interruptible", for some random definition of "big" (ie
multi-megabyte). Exactly because of the DoS issues.

                         Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/