All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: potential memory corruption in check_leaf()
Date: Thu, 6 Nov 2014 13:09:01 +0300	[thread overview]
Message-ID: <20141106100901.GA19282@mwanda> (raw)

Hello Artem Bityutskiy,

The patch 1e51764a3c2a: "UBIFS: add new flash file system" from Jul
14, 2008, leads to the following static checker warning:

	fs/ubifs/debug.c:2039 check_leaf()
	warn: is 'node' large enough for 'struct ubifs_data_node'?

fs/ubifs/debug.c
  1978  static int check_leaf(struct ubifs_info *c, struct ubifs_zbranch *zbr,
  1979                        void *priv)
  1980  {
  1981          ino_t inum;
  1982          void *node;
  1983          struct ubifs_ch *ch;
  1984          int err, type = key_type(c, &zbr->key);
  1985          struct fsck_inode *fscki;
  1986  
  1987          if (zbr->len < UBIFS_CH_SZ) {
                    ^^^^^^^^^^^^^^^^^^^^^^^
We check that ->len is at least 24 bytes.

  1988                  ubifs_err("bad leaf length %d (LEB %d:%d)",
  1989                            zbr->len, zbr->lnum, zbr->offs);
  1990                  return -EINVAL;
  1991          }
  1992  
  1993          node = kmalloc(zbr->len, GFP_NOFS);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Allocate node.

  1994          if (!node)
  1995                  return -ENOMEM;
  1996  
  1997          err = ubifs_tnc_read_node(c, zbr, node);
  1998          if (err) {
  1999                  ubifs_err("cannot read leaf node at LEB %d:%d, error %d",
  2000                            zbr->lnum, zbr->offs, err);
  2001                  goto out_free;
  2002          }
  2003  
  2004          /* If this is an inode node, add it to RB-tree of inodes */
  2005          if (type == UBIFS_INO_KEY) {
  2006                  fscki = add_inode(c, priv, node);
  2007                  if (IS_ERR(fscki)) {
  2008                          err = PTR_ERR(fscki);
  2009                          ubifs_err("error %d while adding inode node", err);
  2010                          goto out_dump;
  2011                  }
  2012                  goto out;
  2013          }
  2014  
  2015          if (type != UBIFS_DENT_KEY && type != UBIFS_XENT_KEY &&
  2016              type != UBIFS_DATA_KEY) {
  2017                  ubifs_err("unexpected node type %d at LEB %d:%d",
  2018                            type, zbr->lnum, zbr->offs);
  2019                  err = -EINVAL;
  2020                  goto out_free;
  2021          }
  2022  
  2023          ch = node;
                ^^^^^^^^^^
24 bytes is large enough for "ch".

  2024          if (le64_to_cpu(ch->sqnum) > c->max_sqnum) {
  2025                  ubifs_err("too high sequence number, max. is %llu",
  2026                            c->max_sqnum);
  2027                  err = -EINVAL;
  2028                  goto out_dump;
  2029          }
  2030  
  2031          if (type == UBIFS_DATA_KEY) {
  2032                  long long blk_offs;
  2033                  struct ubifs_data_node *dn = node;
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
But it's not large enough for "dn".

  2034  
  2035                  /*
  2036                   * Search the inode node this data node belongs to and insert
  2037                   * it to the RB-tree of inodes.
  2038                   */
  2039                  inum = key_inum_flash(c, &dn->key);
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The check waits until we use "dn" before complaining, in case there is
another size check after the assignment.

Also on the other side of the if statement:
fs/ubifs/debug.c:2071 check_leaf() warn: is 'node' large enough for 'struct ubifs_dent_node'?

regards,
dan carpenter

             reply	other threads:[~2014-11-06 10:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 10:09 Dan Carpenter [this message]
2014-11-25 15:00 ` potential memory corruption in check_leaf() Artem Bityutskiy

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=20141106100901.GA19282@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.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 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.