summaryrefslogtreecommitdiff
path: root/fs/jffs2
diff options
context:
space:
mode:
authorXi Wang <xi.wang@gmail.com>2012-04-25 22:45:22 +0400
committerDavid Woodhouse <David.Woodhouse@intel.com>2012-05-14 08:05:15 +0400
commit7c80c352331a27cf0584f1701ed3a003984985f0 (patch)
tree3c90b8d5a23cf563fb40a9866bc8dcf11af4b2fc /fs/jffs2
parent8abc0d4a1181b44e0a42cadab4a15f8c6aa42451 (diff)
downloadlinux-7c80c352331a27cf0584f1701ed3a003984985f0.tar.xz
jffs2: validate symlink size in jffs2_do_read_inode_internal()
`csize' is read from disk and thus needs validation. Otherwise a bogus value 0xffffffff would turn the subsequent kmalloc(csize + 1, ...) into kmalloc(0, ...), leading to out-of-bounds write. This patch limits `csize' to JFFS2_MAX_NAME_LEN, which is also used in jffs2_symlink(). Artem: we actually validate csize by checking CRC, so this 0xFFs cannot come from empty flash region. But I guess an attacker could feed JFFS2 an image with random csize value, including 0xFFs. Signed-off-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Diffstat (limited to 'fs/jffs2')
-rw-r--r--fs/jffs2/readinode.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/fs/jffs2/readinode.c b/fs/jffs2/readinode.c
index dc0437e84763..9897f38af707 100644
--- a/fs/jffs2/readinode.c
+++ b/fs/jffs2/readinode.c
@@ -1266,6 +1266,12 @@ static int jffs2_do_read_inode_internal(struct jffs2_sb_info *c,
/* Symlink's inode data is the target path. Read it and
* keep in RAM to facilitate quick follow symlink
* operation. */
+ uint32_t csize = je32_to_cpu(latest_node->csize);
+ if (csize > JFFS2_MAX_NAME_LEN) {
+ mutex_unlock(&f->sem);
+ jffs2_do_clear_inode(c, f);
+ return -ENAMETOOLONG;
+ }
f->target = kmalloc(je32_to_cpu(latest_node->csize) + 1, GFP_KERNEL);
if (!f->target) {
JFFS2_ERROR("can't allocate %d bytes of memory for the symlink target path cache\n", je32_to_cpu(latest_node->csize));