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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ