do_xip_mapping_read: fix length calculation

PATCH In review Martin Schwidefsky 4 participants 5 messages Mar 31, 2009 – Apr 4, 2009 Memory management

lore

Share & tools

lore

Martin Schwidefsky

author

2009-03-31 13:32 UTC #0 lore raw

PATCH 1/1 do_xip_mapping_read: fix length calculation

From: Martin Schwidefsky <[email protected]>

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:

*** glibc detected *** /bin/bash: free(): invalid next size (normal): 0x00000000800e39f0 *** ======= Backtrace: =========
/lib64/libc.so.6[0x200000b9b44]
/lib64/libc.so.6(cfree+0x8e)[0x200000bdade] /bin/bash(free_buffered_stream+0x32)[0x80050e4e] /bin/bash(close_buffered_stream+0x1c)[0x80050ea4] /bin/bash(unset_bash_input+0x2a)[0x8001c366] /bin/bash(make_child+0x1d4)[0x8004115c]
/bin/bash[0x8002fc3c]
/bin/bash(execute_command_internal+0x656)[0x8003048e] /bin/bash(execute_command+0x5e)[0x80031e1e] /bin/bash(execute_command_internal+0x79a)[0x800305d2] /bin/bash(execute_command+0x5e)[0x80031e1e] /bin/bash(reader_loop+0x270)[0x8001efe0]
/bin/bash(main+0x1328)[0x8001e960] /lib64/libc.so.6(__libc_start_main+0x100)[0x200000592a8] /bin/bash(clearerr+0x5e)[0x8001c092]

With this bug fix the commit 0e4a9b59282914fe057ab17027f55123964bc2e2 "ext2/xip: refuse to change xip flag during remount with busy inodes" can be removed again.

Cc Carsten Otte <[email protected]>

Cc Nick Piggin <[email protected]>

Cc Jared Hulbert <[email protected]>

Cc Andrew Morton <[email protected]>

Signed-off-by Martin Schwidefsky <[email protected]>

---

 mm/filemap_xip.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

mm/filemap_xip.c +2 -2

diff -urpN linux-2.6/mm/filemap_xip.c linux-2.6-patched/mm/filemap_xip.c
@@ -89,8 +89,8 @@ do_xip_mapping_read(struct address_space
 			}
 		}
 		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);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrew Morton

maintainer

2009-04-01 21:21 UTC #1 lore raw

Quoted 20 lines · On Tue, 31 Mar 2009 15:32:23 +0200 Martin Schwidefsky <[email protected]>…

From: Martin Schwidefsky <[email protected]>
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:
*** glibc detected *** /bin/bash: free(): invalid next size (normal): 0x00000000800e39f0 *** ======= Backtrace: =========
/lib64/libc.so.6[0x200000b9b44]
/lib64/libc.so.6(cfree+0x8e)[0x200000bdade] /bin/bash(free_buffered_stream+0x32)[0x80050e4e] /bin/bash(close_buffered_stream+0x1c)[0x80050ea4] /bin/bash(unset_bash_input+0x2a)[0x8001c366] /bin/bash(make_child+0x1d4)[0x8004115c]
/bin/bash[0x8002fc3c]

Quoted 8 lines

/bin/bash(execute_command_internal+0x656)[0x8003048e] /bin/bash(execute_command+0x5e)[0x80031e1e] /bin/bash(execute_command_internal+0x79a)[0x800305d2] /bin/bash(execute_command+0x5e)[0x80031e1e] /bin/bash(reader_loop+0x270)[0x8001efe0] /bin/bash(main+0x1328)[0x8001e960] /lib64/libc.so.6(__libc_start_main+0x100)[0x200000592a8] /bin/bash(clearerr+0x5e)[0x8001c092]

Please get into the habit of adding Cc: <[email protected]> to the changelogs?

I believe I personally am pretty good at picking up stable things, but other patch-mergers are quite unreliable. We all need as much help as we can get on this, because things are falling through cracks.

Quoted 3 lines

With this bug fix the commit 0e4a9b59282914fe057ab17027f55123964bc2e2 "ext2/xip: refuse to change xip flag during remount with busy inodes" can be removed again.

OK, please send a standalone patch to do this at an appropriate time. I guess that this second patch won't be needed in -stable.

Martin Schwidefsky

author

2009-04-02 07:38 UTC #2 lore raw

Quoted 5 lines · On Wed, 1 Apr 2009 14:17:00 -0700 Andrew Morton <[email protected]>…

On Tue, 31 Mar 2009 15:32:23 +0200
Martin Schwidefsky <[email protected]> wrote:
Please get into the habit of adding Cc: <[email protected]> to the changelogs?

Ok, I've made me a sticky note and attached it to my monitor. Perhaps that will help me to remember ..

Quoted 3 lines

I believe I personally am pretty good at picking up stable things, but other patch-mergers are quite unreliable. We all need as much help as we can get on this, because things are falling through cracks.

Ok, makes sense. Better safe than sorry.

Quoted 6 lines

Quoted 3 lines
With this bug fix the commit 0e4a9b59282914fe057ab17027f55123964bc2e2 "ext2/xip: refuse to change xip flag during remount with busy inodes" can be removed again.
OK, please send a standalone patch to do this at an appropriate time. I guess that this second patch won't be needed in -stable.

The revert should be done either with the bug fix or after the bug fix hit mainline. Guess I just create the patch and send it.

Signature · 10 lines

blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Jared Hulbert

2009-04-03 20:52 UTC #3 lore raw

In reply to Martin Schwidefsky

Quoted 2 lines

This bug is the cause for the heap corruption Carsten has been chasing for so long:

Finally saw this issue on ARM. Some programs in Android on ARM were crashing with AXFS. This fixed it.

Minchan Kim

Reviewed-by Tested-by on v1 1/1

2009-04-04 00:34 UTC #4 lore raw

In reply to Martin Schwidefsky

Nice catch!

I tested this patch on ext2's ramdisk with xip.
It fixed following bug.

*** stack smashing detected ***: <unknown> terminated ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7fe5138] /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7fe50f0] [0x80485f8]
[0x0]
======= Memory map: ========

08048000-08049000 r-xp 00000000 01:00 12         /mnt/xip_test
08049000-0804a000 rw-p 00000000 01:00 12         /mnt/xip_test
0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]
b7ef7000-b7ef8000 rw-p b7ef7000 00:00 0
b7ef8000-b8041000 r-xp 00000000 08:03 4219915    /lib/tls/i686/cmov/libc-2.7.so
b8041000-b8042000 r--p 00149000 08:03 4219915    /lib/tls/i686/cmov/libc-2.7.so
b8042000-b8044000 rw-p 0014a000 08:03 4219915    /lib/tls/i686/cmov/libc-2.7.so

b8044000-b8047000 rw-p b8044000 00:00 0
b8047000-b8051000 r-xp 00000000 08:03 4202508 /lib/libgcc_s.so.1
b8051000-b8052000 rw-p 0000a000 08:03 4202508 /lib/libgcc_s.so.1
b8052000-b8055000 rw-p b8052000 00:00 0

b8055000-b8056000 r-xp b8055000 00:00 0          [vdso]
b8056000-b8070000 r-xp 00000000 08:03 4202565    /lib/ld-2.7.so
b8070000-b8072000 rw-p 00019000 08:03 4202565    /lib/ld-2.7.so
bf95c000-bf971000 rw-p bffeb000 00:00 0          [stack]

Aborted

Reviewed-by Minchan kim <[email protected]>

Tested-by Minchan kim <[email protected]>

Quoted 64 lines · Martin Schwidefsky

From: Martin Schwidefsky <[email protected]>
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:
*** glibc detected *** /bin/bash: free(): invalid next size (normal): 0x00000000800e39f0 *** ======= Backtrace: =========
/lib64/libc.so.6[0x200000b9b44]
/lib64/libc.so.6(cfree+0x8e)[0x200000bdade] /bin/bash(free_buffered_stream+0x32)[0x80050e4e] /bin/bash(close_buffered_stream+0x1c)[0x80050ea4] /bin/bash(unset_bash_input+0x2a)[0x8001c366] /bin/bash(make_child+0x1d4)[0x8004115c]
/bin/bash[0x8002fc3c]
/bin/bash(execute_command_internal+0x656)[0x8003048e] /bin/bash(execute_command+0x5e)[0x80031e1e] /bin/bash(execute_command_internal+0x79a)[0x800305d2] /bin/bash(execute_command+0x5e)[0x80031e1e] /bin/bash(reader_loop+0x270)[0x8001efe0]
/bin/bash(main+0x1328)[0x8001e960] /lib64/libc.so.6(__libc_start_main+0x100)[0x200000592a8] /bin/bash(clearerr+0x5e)[0x8001c092]
With this bug fix the commit 0e4a9b59282914fe057ab17027f55123964bc2e2 "ext2/xip: refuse to change xip flag during remount with busy inodes" can be removed again.
Cc Carsten Otte <[email protected]>
Cc Nick Piggin <[email protected]>
Cc Jared Hulbert <[email protected]>
Cc Andrew Morton <[email protected]>
Signed-off-by Martin Schwidefsky <[email protected]>
---
mm/filemap_xip.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff -urpN linux-2.6/mm/filemap_xip.c linux-2.6-patched/mm/filemap_xip.c
mm/filemap_xip.c 2009-03-31 15:25:53.000000000 +0200 renamed from mm/filemap_xip.c 2009-03-24 00:12:14.000000000 +0100 +2 -3
@@ -89,8 +89,8 @@ do_xip_mapping_read(struct address_space
                        }
                }
                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);
 
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Signature · 8 lines

Kinds regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>