linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anton Altaparmakov <aia21@cam.ac.uk>
To: akpm@osdl.org
Cc: blaisorblade@yahoo.it, dhowells@redhat.com, dwmw2@infradead.org,
	green@linuxhacker.ru, hch@lst.de, jdike@addtoit.com,
	linux-fsdevel@vger.kernel.org, miklos@szeredi.hu,
	neilb@cse.unsw.edu.au, reiserfs-dev@namesys.com,
	rmk@arm.linux.org.uk, trond.myklebust@fys.uio.no,
	zippel@linux-m68k.org, mm-commits@vger.kernel.org
Subject: ntfs - was: Re: + fix-possible-page_cache_shift-overflows.patch added to -mm tree
Date: Wed, 23 Nov 2005 22:01:56 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0511232141500.3573@hermes-1.csi.cam.ac.uk> (raw)
In-Reply-To: <200511232121.jANLLo7J024428@shell0.pdx.osdl.net>

On Wed, 23 Nov 2005, akpm@osdl.org wrote:
> 
> The patch titled
> 
>      fix possible PAGE_CACHE_SHIFT overflows
> 
> has been added to the -mm tree.  Its filename is
> 
>      fix-possible-page_cache_shift-overflows.patch
> 
> 
> From: Andrew Morton <akpm@osdl.org>
> 
> We've had two instances recently of overflows when doing
> 
> 	64_bit_value = (32_bit_value << PAGE_CACHE_SHIFT)
> 
> I did a tree-wide grep of `<<.*PAGE_CACHE_SHIFT' and this is the result.
[snip]
> - ntfs_read_compressed_block is doing fishy things with cur_page and
>   cb_max_page.

Those are both fine.  They deal with relative offsets rather than absolute 
page->index and the number of pages is very low (on a 4k PAGE_SIZE 
architecture the maximum number of pages is 16, thus cannot overflow when 
you shiftleft by PAGE_CACHE_SHIFT (16 * 4096 = 65536) and the offsets 
added are also relative to the page and the compression block thus a very 
maximum value of 65536 + 4095 (PAGE_SIZE - 1) + 65536 (maximum compression 
block size) = 135167 which is well within a signed 32-bit variable...

> - load_and_init_attrdef()'s handling of `index' needs to be checked.  Ditto

Towards the top of the function you see:

        i_size = i_size_read(ino);      
        if (i_size <= 0 || i_size > 0x7fffffff)
                goto iput_failed;

Thus the file size is limited to 31-bits thus index << PAGE_CACHE_SHIFT 
can never overflow 32-bits.

>   load_and_init_upcase().  Ditto

As above file size is limited towards top of the function:

        i_size = i_size_read(ino);
        if (!i_size || i_size & (sizeof(ntfschar) - 1) ||
                        i_size > 64ULL * 1024 * sizeof(ntfschar))
                goto iput_upcase_failed;

Since sizeof(ntfschar) is always 2 bytes, the file size is limited to 
128kiB thus index << PAGE_CACHE_SHIFT can never overflow.

>   ntfs_attr_extend_initialized():initialized_size

Yep, I can see a bug there!  I missed one (s64) cast when I had it in the 
four other places doing a << PAGE_CACHE_SHIFT around the same place.  )-:

-		ni->initialized_size = (index + 1) << PAGE_CACHE_SHIFT;
+		ni->initialized_size = (s64)(index + 1) << PAGE_CACHE_SHIFT;

Well caught!  Thanks!  Normally I am quite careful about this as I already 
have been hit in ntfs by such overflows (a long time ago when the new 
ntfs driver was in early stages of development)...

I will fix it tomorrow and push to my ntfs-2.6-devel.git tree so you 
will hopefully pick it up for your next -mm...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

  reply	other threads:[~2005-11-23 22:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-23 21:22 + fix-possible-page_cache_shift-overflows.patch added to -mm tree akpm
2005-11-23 22:01 ` Anton Altaparmakov [this message]
2005-11-24  1:00 ` Blaisorblade
2005-11-24  1:09   ` Andrew Morton
2005-11-24  1:37     ` Blaisorblade
2005-11-24 10:02     ` Christoph Hellwig
2005-11-24  7:05 ` Miklos Szeredi
2005-11-24  7:46 ` David Woodhouse
2005-11-24 11:24 ` Oleg Drokin
2005-11-26  0:54   ` Hans Reiser
2005-11-24 21:08 ` Roman Zippel

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=Pine.LNX.4.64.0511232141500.3573@hermes-1.csi.cam.ac.uk \
    --to=aia21@cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=blaisorblade@yahoo.it \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=green@linuxhacker.ru \
    --cc=hch@lst.de \
    --cc=jdike@addtoit.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mm-commits@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    --cc=reiserfs-dev@namesys.com \
    --cc=rmk@arm.linux.org.uk \
    --cc=trond.myklebust@fys.uio.no \
    --cc=zippel@linux-m68k.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).