summaryrefslogtreecommitdiffstats
path: root/fs/romfs
diff options
context:
space:
mode:
authorGreg Ungerer <gerg@uclinux.org>2013-04-02 06:25:33 +0200
committerGreg Ungerer <gerg@uclinux.org>2013-04-29 01:17:57 +0200
commite4ba4fc2b98f659f525d02721643a01015a8e3ed (patch)
treefdc9b5c1c1e09ee83aae0f968702e27f21585208 /fs/romfs
parentm68k: clean up unused "config ROMVECSIZE" (diff)
downloadlinux-e4ba4fc2b98f659f525d02721643a01015a8e3ed.tar.xz
linux-e4ba4fc2b98f659f525d02721643a01015a8e3ed.zip
romfs: fix nommu map length to keep inside filesystem
Checks introduced in commit 4991e7251 ("romfs: do not use mtd->get_unmapped_area directly") re-introduce problems fixed in the earlier commit 2b4b2482e ("romfs: fix romfs_get_unmapped_area() argument check"). If a flat binary app is located at the end of a romfs, its page aligned length may be outside of the romfs filesystem. The flat binary loader, via nommu do_mmap_pgoff(), page aligns the length it is mmaping. So simple offset+size checks will fail - returning EINVAL. We can truncate the length to keep it inside the romfs filesystem, and that also keeps the call to mtd_get_unmapped_area() happy. Are there any side effects to truncating the size here though? Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Diffstat (limited to 'fs/romfs')
-rw-r--r--fs/romfs/mmap-nommu.c5
1 files changed, 4 insertions, 1 deletions
diff --git a/fs/romfs/mmap-nommu.c b/fs/romfs/mmap-nommu.c
index e1a7779dd3cb..f373bde8f545 100644
--- a/fs/romfs/mmap-nommu.c
+++ b/fs/romfs/mmap-nommu.c
@@ -49,8 +49,11 @@ static unsigned long romfs_get_unmapped_area(struct file *file,
return (unsigned long) -EINVAL;
offset += ROMFS_I(inode)->i_dataoffset;
- if (offset > mtd->size - len)
+ if (offset >= mtd->size)
return (unsigned long) -EINVAL;
+ /* the mapping mustn't extend beyond the EOF */
+ if ((offset + len) > mtd->size)
+ len = mtd->size - offset;
ret = mtd_get_unmapped_area(mtd, len, offset, flags);
if (ret == -EOPNOTSUPP)