[patch] Fix find_separate_debug_file buffer overrun [Re: gdb crash during read of separate debuginfo]
Jan Kratochvil
jan.kratochvil@redhat.com
Mon Aug 3 17:13:00 GMT 2009
On Mon, 03 Aug 2009 18:46:34 +0200, Tom Tromey wrote:
> Jan> 2009-08-02 Richard Guenther <rguenther@suse.de>
> Jan> Jan Kratochvil <jan.kratochvil@redhat.com>
> Jan> Fix memory corruption on reread of file through a symbolic link.
> Jan> * symfile.c (find_separate_debug_file): Initialize CANON_NAME earlier.
> Jan> Allocate DEBUGFILE with length based on CANON_NAME. Free CANON_NAME on
> Jan> all the return paths.
>
> This looks good to me.
> Ok.
Checked-in:
http://sourceware.org/ml/gdb-cvs/2009-08/msg00009.html
> Jan> I do not push much to get the testcase accepted.
>
> Is there something in particular you think is wrong with it? It looks
> ok to me, but your comment makes me wonder what subtlety I missed.
Function under the test is: find_separate_debug_file
Calling paths to find_separate_debug_file are only:
reread_symbols -> reread_separate_symbols -> find_separate_debug_file
- It should get sooner or later dropped by
Re: [patch] Replace reread_symbols by load+free calls
http://sourceware.org/ml/gdb-patches/2009-06/msg00696.html
or some similiar patch which is IMO inevitable.
- This path is currently exploited by the testcase.
symbol_file_add -> symbol_file_add_from_bfd
- Not exploitable as:
symbol_file_add -> symfile_bfd_open -> openp -> xfullpath
so that objfile->name has already expanded any symbolic links.
symbol_file_add_from_bfd -> symbol_file_add_with_addrs_or_offsets -> find_separate_debug_file
- Exploitable caller may be symbol_add_stub through solib_add, I will
check it later more.
The testcase was written before I found out it is not easily exploitable.
Only now found the last option. Therefore not checking it now in.
Thanks,
Jan
More information about the Gdb-patches
mailing list