This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi! On Fri, 2 Mar 2012 12:00:36 +0000, Pedro Alves <palves@redhat.com> wrote: > On 03/02/2012 11:17 AM, Thomas Schwinge wrote: > > On Thu, 1 Mar 2012 17:18:47 -0700, Kevin Buettner <kevinb@redhat.com> wrote: > >> > On Thu, 01 Mar 2012 10:00:00 +0100 > >> > Thomas Schwinge <thomas@codesourcery.com> wrote: > >> > > >>> > > @@ -594,6 +590,7 @@ sh_analyze_prologue (struct gdbarch *gdb > >>> > > { > >>> > > sav_reg = reg; > >>> > > offset = (inst & 0xff) << 1; > >>> > > + /* TODO: check that this is a valid address. */ > >>> > > sav_offset = > >>> > > read_memory_integer ((pc + 4) + offset, 2, byte_order); > >>> > > } > In this case, what's > necessary to just fix that particular issue? The issue here is that external data (a malicious executable that is being debugged) might possibly cause GDB to do arbitrary things due to corrupting its internal state. (I don't know if GDB development is generally paying attention to such ``detail'', but it certainly is an attack vector if you're debugging a binary that has been provided by a third party.) For inaccessible addresses, target_read_memory returns EIO, which causes read_memory to invoke throw_error: ``Cannot access memory at address 0xfffffffe''; that's fine. For improper but accessible addresses, it is more difficult to predict what might happen in the following. The value will be propagated into a frame cache's sp_offset and saved_sp. From there on, we have to rely on the frame unwinding machinery to reliably detect any failures or inconsistencies. GrÃÃe, Thomas
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |