linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

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