summaryrefslogtreecommitdiff
path: root/mm
diff options
context:
space:
mode:
authorMartin Schwidefsky <schwidefsky@de.ibm.com>2009-04-03 08:35:12 +0400
committerGreg Kroah-Hartman <gregkh@suse.de>2009-05-02 21:23:59 +0400
commite655a1eaa988bc55739f47d62ab0658c1364458a (patch)
tree6b793dbbdaaea766a29aa0d3de283bf661557dde /mm
parent398e94c43b3339ce64f71d1ea827c3c4fed5ef1e (diff)
downloadlinux-e655a1eaa988bc55739f47d62ab0658c1364458a.tar.xz
mm: do_xip_mapping_read: fix length calculation
upstream commit: 58984ce21d315b70df1a43644df7416ea7c9bfd8 The calculation of the value nr in do_xip_mapping_read is incorrect. If the copy required more than one iteration in the do while loop the copies variable will be non-zero. The maximum length that may be passed to the call to copy_to_user(buf+copied, xip_mem+offset, nr) is len-copied but the check only compares against (nr > len). This bug is the cause for the heap corruption Carsten has been chasing for so long:
Diffstat (limited to 'mm')
-rw-r--r--mm/filemap_xip.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/mm/filemap_xip.c b/mm/filemap_xip.c
index b5167dfb2f2d..e8b2b18f02a3 100644
--- a/mm/filemap_xip.c
+++ b/mm/filemap_xip.c
@@ -89,8 +89,8 @@ do_xip_mapping_read(struct address_space *mapping,
}
}
nr = nr - offset;
- if (nr > len)
- nr = len;
+ if (nr > len - copied)
+ nr = len - copied;
error = mapping->a_ops->get_xip_mem(mapping, index, 0,
&xip_mem, &xip_pfn);