Searched hist:"7 c80c352" (Results 1 – 1 of 1) sorted by relevance
/openbmc/linux/fs/jffs2/ |
H A D | readinode.c | 7c80c352 Wed Apr 25 13:45:22 CDT 2012 Xi Wang <xi.wang@gmail.com> 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> 7c80c352 Wed Apr 25 13:45:22 CDT 2012 Xi Wang <xi.wang@gmail.com> 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>
|