linux-kernel - Re: [PATCH] eCryptfs: infinite loop bug

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

Message-ID: <CA+55aFx7CV8wpDLfCr-pVVRxRyYgd2QdRXJSmp+UgrjSHyB1eA@mail.gmail.com>
Date:	Wed, 18 Jan 2012 12:49:17 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	dragonylffly <dragonylffly@....com>
Cc:	tyhicks@...onical.com, john.johansen@...onical.com,
	dustin.kirkland@...zang.com, ecryptfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] eCryptfs: infinite loop bug

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().

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.

                     Linus.

2012/1/17 dragonylffly <dragonylffly@....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@...t.edu.cn>
>                Yunchuan Wen (wenyunchuan@...inos.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 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/