[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANT6BaO418KViOgCj11qCKi8keZ+tqbEAkCvBFvwNF4EtUziEA@mail.gmail.com>
Date: Thu, 19 Jan 2012 10:17:55 -0600
From: Dustin Kirkland <dustin.kirkland@...zang.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: dragonylffly <dragonylffly@....com>, tyhicks@...onical.com,
john.johansen@...onical.com, ecryptfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] eCryptfs: infinite loop bug
On Wed, Jan 18, 2012 at 2:49 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> There are *two* cases where we do that "total_remaining_bytes"
> calculation. The same bug seems to exist both in ecryptfs_read() and
> ecryptfs_write().
>
> Possibly only the ecryptfs_write() one leads to an endless loop, but
> the read one looks suspicious too.
>
> Also, what protects things against this just being one nasty DoS
> attack - even if the code is fixed to not be an endless loop, it looks
> like a trivial "truncate()" can be used to generate a *practically*
> infinite write stream. At the very least, this should be KILLABLE. Or
> did I mis-read the code?
>
> Tyler, Dustin, others - comments? This looks nasty.
Definitely nasty, Linus. This is almost certainly the source of a
long-standing bug [1] we've had with tor-downloads into eCryptfs
mounts hanging the OS. Tor clients truncate a file at the start of
the download large enough to handle the eventual result.
Glad to see this finally triaged and a fix in the works, Li Wang and
Yunchuan Wen. Thanks for that.
[1] https://bugs.launchpad.net/ecryptfs/+bug/431975
--
:-Dustin
Dustin Kirkland
Chief Architect
Gazzang, Inc.
www.gazzang.com
--
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