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:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-18 7:30 [PATCH] eCryptfs: infinite loop bug 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 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 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 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).