diff options
| author | Greg Ungerer <gerg@uclinux.org> | 2013-04-02 14:25:33 +1000 |
|---|---|---|
| committer | Greg Ungerer <gerg@uclinux.org> | 2013-04-29 09:17:57 +1000 |
| commit | e4ba4fc2b98f659f525d02721643a01015a8e3ed (patch) | |
| tree | fdc9b5c1c1e09ee83aae0f968702e27f21585208 /fs/romfs | |
| parent | 5143661ff82792673787cd03b2b1bf9d63f60093 (diff) | |
| download | linux-stable-e4ba4fc2b98f659f525d02721643a01015a8e3ed.tar.gz linux-stable-e4ba4fc2b98f659f525d02721643a01015a8e3ed.tar.bz2 linux-stable-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.c | 5 |
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) |