linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@canonical.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: dragonylffly <dragonylffly@163.com>,
	john.johansen@canonical.com, dustin.kirkland@gazzang.com,
	ecryptfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] eCryptfs: infinite loop bug
Date: Wed, 18 Jan 2012 15:04:01 -0600	[thread overview]
Message-ID: <20120118210400.GB20576@boyd> (raw)
In-Reply-To: <CA+55aFx7CV8wpDLfCr-pVVRxRyYgd2QdRXJSmp+UgrjSHyB1eA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]

On 2012-01-18 12:49:17, Linus Torvalds wrote:
> Hmm.
> 
> 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().

ecryptfs_read() is ifdef'ed out, and has been for years, so I'll just go
ahead and kill that function for good.

> 
> 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?

I think you're right. I'll start off with making it killable and then
see if there is anything else we can do.

Tyler

> 
> Tyler, Dustin, others - comments? This looks nasty.
> 
>                      Linus.
> 
> 2012/1/17 dragonylffly <dragonylffly@163.com>:
> > Hi,
> >   There is an infinite loop bug in eCryptfs, to make it present,
> > just truncate to generate a huge file (>= 4G) on a 32-bit machine under
> > the plain text foleder mounted with eCryptfs, a simple command
> > 'truncate -s 4G dummy' is enough. Note: 4GB is smaller than 4G,
> > therefore the following command 'truncate -s 4GB dummy' will not
> > trigger this bug. The bug comes from a data overflow, the patch below fixes
> > it.
> >
> > Cheers,
> > Li Wang
> >
> > ---
> >
> > signed-off-by: Li Wang <liwang@nudt.edu.cn>
> >                Yunchuan Wen (wenyunchuan@kylinos.com.cn)
> >
> > --- read_write.c.orig 2012-01-18 10:39:26.000000000 +0800
> > +++ read_write.c 2012-01-18 19:48:41.484196221 +0800
> > @@ -130,7 +130,7 @@
> >    pgoff_t ecryptfs_page_idx = (pos >> PAGE_CACHE_SHIFT);
> >    size_t start_offset_in_page = (pos & ~PAGE_CACHE_MASK);
> >    size_t num_bytes = (PAGE_CACHE_SIZE - start_offset_in_page);
> > -  size_t total_remaining_bytes = ((offset + size) - pos);
> > +  loff_t total_remaining_bytes = ((offset + size) - pos);
> >
> >    if (num_bytes > total_remaining_bytes)
> >     num_bytes = total_remaining_bytes;
> >
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-01-18 21:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7f1e961d.f528.134efaf8348.Coremail.dragonylffly@163.com>
2012-01-18 20:49 ` [PATCH] eCryptfs: infinite loop bug Linus Torvalds
2012-01-18 21:04   ` Tyler Hicks [this message]
2012-01-19 16:17   ` Dustin Kirkland
2012-01-18  7:30 Li Wang
2012-01-18 15:26 ` Cong Wang
2012-01-18 21:40   ` Tyler Hicks
2012-01-19  3:43     ` Linus Torvalds
     [not found]   ` <526922120.05125@eyou.net>
2012-01-19  1:44     ` Li Wang
2012-01-19  8:48       ` Tyler Hicks
2012-01-19 14:03         ` Dustin Kirkland
2012-01-19 15:08           ` Tyler Hicks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120118210400.GB20576@boyd \
    --to=tyhicks@canonical.com \
    --cc=dragonylffly@163.com \
    --cc=dustin.kirkland@gazzang.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=john.johansen@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).