This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix find_separate_debug_file buffer overrun [Re: gdb crash during read of separate debuginfo]
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Richard Guenther <rguenther at suse dot de>
- Date: Mon, 3 Aug 2009 19:13:10 +0200
- Subject: Re: [patch] Fix find_separate_debug_file buffer overrun [Re: gdb crash during read of separate debuginfo]
- References: <alpine.LNX.2.00.0908021137300.16347@zhemvz.fhfr.qr> <20090802211036.GA28064@host0.dyn.jankratochvil.net> <m3y6q0luad.fsf@fleche.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