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

Message-ID: <20110716211618.GA2717@thunk.org>
Date:	Sat, 16 Jul 2011 17:16:18 -0400
From:	Ted Ts'o <tytso@....edu>
To:	halfdog <me@...fdog.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Possible ext2/3/4 filesysystem iov_length integer overflow and
 strange behavior on large writes

On Fri, Jun 17, 2011 at 04:17:32PM +0000, halfdog wrote:
> 
> If I understand it correctly, there might be multiple iov_length
> interger overflows on 32bit arch in ext2, ext3, ext4, e.g.

> Can someone confirm or refute that? I wrote a small test program, but
> failed to inflict damage on the kernel or filesystem, so I might have
> missed something. From source grep, also other filesystems might have
> the same problem.

The iovec is checked in the VFS layer.  See the function
rw_copy_check_uvector() in fs/read_write.c.

> Apart from that, large iov writes seem to be uninteruptible. Sending a
> kill signal to the process in writev terminates it after finishing the
> syscall.

That's partially historical.  There are a programs out there which
assume that reads and writes to files on disk can't get interrupted in
media res.  (Worse yet are the progams which make this assumption on
network connections, but that's another story.)  Programs should check
the return value, on a partial read or write, retry the read/write.
Many don't.  Writes are fast enough most of the time that it's not
worth it to make them be interruptible.

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.  I'm currently not in a place where I can do experiments about
this, but I did want to acknowledge your concern.  It may be that the
right thing to do is to allow a SIGKILL to interrupt a disk write.

Apologies for not responding earlier; this managed to slip through my
inbox and I only saw it now.

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