Re: [patch] Fix find_separate_debug_file buffer overrun [Re: gdb crash during read of separate debuginfo]

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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