All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Elder <alex.elder@linaro.org>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: elder@inktank.com, ceph-devel@vger.kernel.org
Subject: Re: rbd: refactor rbd_header_from_disk()
Date: Thu, 20 Jun 2013 16:23:13 -0500	[thread overview]
Message-ID: <51C372C1.7010607@linaro.org> (raw)
In-Reply-To: <20130620211158.GA31274@elgon.mountain>

On 06/20/2013 04:11 PM, Dan Carpenter wrote:
> Hello Alex Elder,
> 
> The patch bb23e37acb2a: "rbd: refactor rbd_header_from_disk()" from 
> May 6, 2013, has some integer overflow bugs:
> 
> drivers/block/rbd.c
>    793          snap_count = le32_to_cpu(ondisk->snap_count);
>    794          snapc = ceph_create_snap_context(snap_count, GFP_KERNEL);
> 
> snap_count comes from the disk.  On 32 bit systems there is an integer
> overflow problem inside ceph_create_snap_context() so snapc could be
> smaller than intended.

Is it true that fixing ceph_create_snap_context() would resolve
the issues you describe here?

I believe inserting this at the top of that function would
resolve the potential overflow:

        if (snap_count > SNAP_COUNT_MAX)
                return NULL;

Where SNAP_COUNT_MAX would be defined as:

#define SNAP_COUNT_MAX \
        ((SIZE_MAX - sizeof (struct ceph_snap_context)) / sizeof (u64))

Do you agree, or is there something else you would recommend?
Thanks.

					-Alex
> 
>    795          if (!snapc)
>    796                  goto out_err;
>    797          snapc->seq = le64_to_cpu(ondisk->snap_seq);
>    798          if (snap_count) {
>    799                  struct rbd_image_snap_ondisk *snaps;
>    800                  u64 snap_names_len = le64_to_cpu(ondisk->snap_names_len);
>    801  
>    802                  /* We'll keep a copy of the snapshot names... */
>    803  
>    804                  if (snap_names_len > (u64)SIZE_MAX)
>    805                          goto out_2big;
>    806                  snap_names = kmalloc(snap_names_len, GFP_KERNEL);
>    807                  if (!snap_names)
>    808                          goto out_err;
>    809  
>    810                  /* ...as well as the array of their sizes. */
>    811  
>    812                  size = snap_count * sizeof (*header->snap_sizes);
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> There is a second integer overflow bug here.
> 
>    813                  snap_sizes = kmalloc(size, GFP_KERNEL);
>    814                  if (!snap_sizes)
>    815                          goto out_err;
> 
> regards,
> dan carpenter
> 


      reply	other threads:[~2013-06-20 21:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-20 21:11 rbd: refactor rbd_header_from_disk() Dan Carpenter
2013-06-20 21:23 ` Alex Elder [this message]

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=51C372C1.7010607@linaro.org \
    --to=alex.elder@linaro.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dan.carpenter@oracle.com \
    --cc=elder@inktank.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.