Re: Possible ext2/3/4 filesysystem iov_length integer overflow andstrange behavior on large writes

[Ted Ts'o]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/