[Bug 891349] New: Address zero referenced in libc.so.6, routine free, for arguments that have bits 26-63 unset
https://bugzilla.novell.com/show_bug.cgi?id=891349 https://bugzilla.novell.com/show_bug.cgi?id=891349#c0 Summary: Address zero referenced in libc.so.6, routine free, for arguments that have bits 26-63 unset Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: shamsundar@uh.edu QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36 Problem: If argument to free() has bits 30-63 equal to zero, at offset 7ea24 (see disassembly below) contents of address 0 are referenced,and then a crash is likely. $ /lib64/libc.so.6 GNU C Library (GNU libc) stable release version 2.17 (git c758a6861537), by Roland McGrath et al. Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Configured for x86_64-suse-linux. Compiled by GNU CC version 4.7.2 20130108 [gcc-4_7-branch revision 195012]. Compiled on a Linux 3.7.1 system. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNC $ nm /lib64/libc.so.6 | grep -C4 -i ' free$' 00000000000fd590 T __fread_chk 0000000000074f90 T __freading 0000000000075ad0 T fread_unlocked 00000000000fd760 T __fread_unlocked_chk 000000000007e9f0 T free <======= 000000000007e9f0 t __free 00000000000d62a0 T freeaddrinfo 000000000007dd40 t free_atfork 00000000000c2ec0 t free_charset $ objdump -d /lib64/libc.so.6 --start-address=0x7e9f0 --stop-address=0x7eb00 000000000007e9f0 <__libc_free>: 7e9f0: 48 8b 05 c1 94 32 00 mov 0x3294c1(%rip),%rax # 3a7eb8 <_DYNAMIC+0x378> 7e9f7: 48 8b 00 mov (%rax),%rax 7e9fa: 48 85 c0 test %rax,%rax 7e9fd: 75 73 jne 7ea72 <__libc_free+0x82> 7e9ff: 48 85 ff test %rdi,%rdi 7ea02: 74 6c je 7ea70 <__libc_free+0x80> 7ea04: 48 8b 47 f8 mov -0x8(%rdi),%rax 7ea08: 48 8d 77 f0 lea -0x10(%rdi),%rsi 7ea0c: a8 02 test $0x2,%al 7ea0e: 75 20 jne 7ea30 <__libc_free+0x40> 7ea10: a8 04 test $0x4,%al 7ea12: 48 8d 3d 27 9c 32 00 lea 0x329c27(%rip),%rdi # 3a8640 <main_arena> 7ea19: 74 0c je 7ea27 <__libc_free+0x37> 7ea1b: 48 89 f0 mov %rsi,%rax 7ea1e: 48 25 00 00 00 fc and $0xfffffffffc000000,%rax 7ea24: 48 8b 38 mov (%rax),%rdi <======= 7ea27: 31 d2 xor %edx,%edx 7ea29: e9 22 cc ff ff jmpq 7b650 <_int_free> Reproducible: Always Steps to Reproduce: 1.The problem was discovered in a complex Fortran program, in a DEALLOCATE statement, which sent the argument to free() as 0x00000000020E5C20. I do not know how to construct a reproducer that generates a valid address with at least one of bits 26 - 63 set. I hope that inspecting the disassembly (see above) will suffice. 2. 3. Actual Results: 1. Inspect disassembly of free() in libc.so.6. 2. Observe instructions that AND the argument to free() to zero out bits 0-25, and then reference the resulting address (at offsets 7EA1E and 7EA24 in the listing above). Expected Results: Code should not try to reference address zero. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=891349 https://bugzilla.novell.com/show_bug.cgi?id=891349#c1 --- Comment #1 from Dr. Shamsundar <shamsundar@uh.edu> 2014-08-11 18:12:52 UTC --- Postscript: Here is a short Fortran program that exposes this bug. program test_free_bug implicit none real, dimension (:), allocatable :: w integer :: dim, err, locw, mskadr dim = 100 print *, "Linear dimension of the matrix", dim allocate(w(dim), stat=err) if (err /= 0) print *, "w: allocation request denied" locw = LOC(w) write(*,'(A,Z16.16)')'Address of w after allocation = 0X',locw mskadr=IAND(locw,Z'FC000000') if(mskadr.eq.0)stop 'masked adrs =zero, will crash free() on Linux libc.so.6' if (allocated(w)) deallocate(w, stat=err) if (err /= 0) print *, "w: deallocation request denied" end program test_free_bug -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=891349 https://bugzilla.novell.com/show_bug.cgi?id=891349#c2 Marcus Meissner <meissner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@suse.com --- Comment #2 from Marcus Meissner <meissner@suse.com> 2014-08-12 05:57:08 UTC --- this seems as if the upper 32bit are truncated. are you storing a pointer in a 32bit entiuty on 64bit? not familar with fortran, but it seems "locw" should not be an integer (32bit?) but more a long (in C speak) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=891349 https://bugzilla.novell.com/show_bug.cgi?id=891349#c3 --- Comment #3 from Dr. Shamsundar <shamsundar@uh.edu> 2014-08-12 13:53:26 UTC --- Strictly speaking, yes, "locw" should be declared INTEGER*8 for 64 bit pointers. However, in this reproducer the variable "locw" is used only to report what is happening, and the complaint concerns only those cases where the *upper 32 bits of the pointer are zero*. Therefore, even a 32-bit "locw" suffices to highlight the bug. I downloaded the source code for GLIBC (2.17) and looked at the code for free(). There is no place in that scope where the pointer is AND-ed with FFFFFFFFFC000000, so I wonder, is this a Suse modification? Thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=891349 https://bugzilla.novell.com/show_bug.cgi?id=891349#c Marcus Meissner <meissner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |rguenther@suse.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=891349 https://bugzilla.novell.com/show_bug.cgi?id=891349#c Richard Biener <rguenther@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|rguenther@suse.com |schwab@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=891349 https://bugzilla.novell.com/show_bug.cgi?id=891349#c4 Andreas Schwab <schwab@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #4 from Andreas Schwab <schwab@suse.com> 2014-08-14 11:26:22 CEST --- You can only pass valid heap pointers to free. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
You can only pass valid heap pointers to free. Of course, and you can see from the Fortran source that I do not manipulate any
https://bugzilla.novell.com/show_bug.cgi?id=891349 https://bugzilla.novell.com/show_bug.cgi?id=891349#c5 --- Comment #5 from Dr. Shamsundar <shamsundar@uh.edu> 2014-08-14 12:13:33 UTC --- pointers. A valid pointer is generated (to use C terminology) by the ALLOCATE statement, and that same pointer is used with a subsequent DEALLOCATE statement. The GFortran compiler converts these statements into calls to malloc() and free(). For details, please read the initial post. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com