public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: static check complains about potential oops in adfs_read_map()
Date: Fri, 6 Jan 2012 14:45:04 +0300	[thread overview]
Message-ID: <20120106114503.GA1540@elgon.mountain> (raw)

My static checker is complaining about potential oops in adfs.  I don't
know the code well enough to say if it's a real bug or what the correct
fix is.

fs/adfs/super.c
   299          nzones    = asb->s_map_size;
                            ^^^^^^^^^^^^^^^
This could be zero.  We read it from the disk.  I don't see any place
where it's checked.

   300          zone_size = (8 << dr->log2secsize) - le16_to_cpu(dr->zone_spare);
   301          map_addr  = (nzones >> 1) * zone_size -
   302                       ((nzones > 1) ? ADFS_DR_SIZE_BITS : 0);
   303          map_addr  = signed_asl(map_addr, asb->s_map2blk);
   304  
   305          asb->s_ids_per_zone = zone_size / (asb->s_idlen + 1);
   306  
   307          dm = kmalloc(nzones * sizeof(*dm), GFP_KERNEL);
   308          if (dm == NULL) {
   309                  adfs_error(sb, "not enough memory");
   310                  return NULL;
   311          }
   312  
   313          for (zone = 0; zone < nzones; zone++, map_addr++) {
   314                  dm[zone].dm_startbit = 0;
   315                  dm[zone].dm_endbit   = zone_size;
   316                  dm[zone].dm_startblk = zone * zone_size - ADFS_DR_SIZE_BITS;
   317                  dm[zone].dm_bh       = sb_bread(sb, map_addr);
   318  
   319                  if (!dm[zone].dm_bh) {
   320                          adfs_error(sb, "unable to read map");
   321                          goto error_free;
   322                  }
   323          }
   324  
   325          /* adjust the limits for the first and last map zones */
   326          i = zone - 1;
   327          dm[0].dm_startblk = 0;
                ^^^^^
dm is the ZERO_SIZE_PTR so this would oops.

   328          dm[0].dm_startbit = ADFS_DR_SIZE_BITS;
   329          dm[i].dm_endbit   = (le32_to_cpu(dr->disc_size_high) << (32 - dr->log2bpmb)) +
   330                              (le32_to_cpu(dr->disc_size) >> dr->log2bpmb) +
   331                              (ADFS_DR_SIZE_BITS - i * zone_size);

regards,
dan carpenter

                 reply	other threads:[~2012-01-06 11:45 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20120106114503.GA1540@elgon.mountain \
    --to=dan.carpenter@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk@arm.linux.org.uk \
    /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