From: Tyler Hicks <tyhicks@canonical.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Li Wang <liwang@nudt.edu.cn>,
ecryptfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
Dustin Kirkland <kirkland@canonical.com>
Subject: Re: [PATCH] eCryptfs: infinite loop bug
Date: Wed, 18 Jan 2012 15:40:51 -0600 [thread overview]
Message-ID: <20120118214051.GC20576@boyd> (raw)
In-Reply-To: <4F16E4BC.5080100@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3421 bytes --]
On 2012-01-18 23:26:52, Cong Wang wrote:
> On 01/18/2012 03:30 PM, Li Wang wrote:
> >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.
> >
> >
>
> Hi,
>
> Your patch is not correctly generated, you need to make the diff on
> top of the source tree.
>
> Also, after reviewing the code, I think there are more places need
> to fix. Can you try my patch below?
Thanks for the review and additional fixes. See my comments below.
>
> Thanks.
>
> ---->
>
> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
>
>
> diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
> index a9f29b1..9ca9c17 100644
> --- a/fs/ecryptfs/ecryptfs_kernel.h
> +++ b/fs/ecryptfs/ecryptfs_kernel.h
> @@ -653,7 +653,7 @@ int ecryptfs_write_lower(struct inode *ecryptfs_inode, char *data,
> loff_t offset, size_t size);
> int ecryptfs_write_lower_page_segment(struct inode *ecryptfs_inode,
> struct page *page_for_lower,
> - size_t offset_in_page, size_t size);
> + loff_t offset_in_page, size_t size);
> int ecryptfs_write(struct inode *inode, char *data, loff_t offset, size_t size);
> int ecryptfs_read_lower(char *data, loff_t offset, size_t size,
> struct inode *ecryptfs_inode);
> diff --git a/fs/ecryptfs/read_write.c b/fs/ecryptfs/read_write.c
> index 3745f7c..93d80c4 100644
> --- a/fs/ecryptfs/read_write.c
> +++ b/fs/ecryptfs/read_write.c
> @@ -72,7 +72,7 @@ int ecryptfs_write_lower(struct inode *ecryptfs_inode, char *data,
> */
> int ecryptfs_write_lower_page_segment(struct inode *ecryptfs_inode,
> struct page *page_for_lower,
> - size_t offset_in_page, size_t size)
> + loff_t offset_in_page, size_t size)
mm/filemap.c uses unsigned long for variables used to identify an offset
into a single page. That's what I'm tempted to use for offset_in_page,
rather than loff_t.
> {
> char *virt;
> loff_t offset;
> @@ -128,15 +128,15 @@ int ecryptfs_write(struct inode *ecryptfs_inode, char *data, loff_t offset,
> pos = offset;
> while (pos < (offset + size)) {
> 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 start_offset_in_page = (pos & ~PAGE_CACHE_MASK);
> + loff_t num_bytes = (PAGE_CACHE_SIZE - start_offset_in_page);
unsigned long should work for start_offset_in_page and num_bytes, too.
Tyler
> + loff_t total_remaining_bytes = ((offset + size) - pos);
>
> if (num_bytes > total_remaining_bytes)
> num_bytes = total_remaining_bytes;
> if (pos < offset) {
> /* remaining zeros to write, up to destination offset */
> - size_t total_remaining_zeros = (offset - pos);
> + loff_t total_remaining_zeros = (offset - pos);
>
> if (num_bytes > total_remaining_zeros)
> num_bytes = total_remaining_zeros;
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-01-18 21:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-18 7:30 [PATCH] eCryptfs: infinite loop bug Li Wang
2012-01-18 7:30 ` Li Wang
2012-01-18 15:26 ` Cong Wang
2012-01-18 21:40 ` Tyler Hicks [this message]
2012-01-19 3:43 ` Linus Torvalds
[not found] ` <526922120.05125@eyou.net>
2012-01-19 1:44 ` Li Wang
2012-01-19 1:44 ` Li Wang
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
2012-01-19 9:13 ` [PATCH] eCryptfs: infinite loop due to overflow in ecryptfs_write() Tyler Hicks
2012-01-19 15:09 ` Cong Wang
[not found] <7f1e961d.f528.134efaf8348.Coremail.dragonylffly@163.com>
2012-01-18 20:49 ` [PATCH] eCryptfs: infinite loop bug Linus Torvalds
2012-01-18 20:49 ` Linus Torvalds
2012-01-18 21:04 ` Tyler Hicks
2012-01-19 16:17 ` Dustin Kirkland
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=20120118214051.GC20576@boyd \
--to=tyhicks@canonical.com \
--cc=ecryptfs@vger.kernel.org \
--cc=kirkland@canonical.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liwang@nudt.edu.cn \
--cc=xiyou.wangcong@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.