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/
next prev parent 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).