diff options
| author | Martin Schwidefsky <schwidefsky@de.ibm.com> | 2009-04-03 04:35:12 +0000 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@suse.de> | 2009-05-02 10:23:59 -0700 |
| commit | e655a1eaa988bc55739f47d62ab0658c1364458a (patch) | |
| tree | 6b793dbbdaaea766a29aa0d3de283bf661557dde | |
| parent | 398e94c43b3339ce64f71d1ea827c3c4fed5ef1e (diff) | |
| download | lwn-e655a1eaa988bc55739f47d62ab0658c1364458a.tar.gz lwn-e655a1eaa988bc55739f47d62ab0658c1364458a.zip | |
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:
| -rw-r--r-- | mm/filemap_xip.c | 4 |
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); |