Re: writing to freed memory--issues

Kasper Dupont wrote:
bill pursell wrote:

I was playing around with a toy program, which led to some confusion.
I had expected that doing the following would lead to an immediate
segfault:
free(a);
*a=0;
However, it did not.

The result is undefined, which means it could do anything that
process is allowed to do. If you want to catch such a bug look
on some of the debugging tools that were written for the purpose:

Sure, the result is undefined, but the behavior is very
consistent. I'm not concerned about catching the
bug, just trying to understand the behavior.


I concluded that when I had allocated
enough space that the process required an extra page, the page was
given, and then taken back on the free, so that writes to the freed
page caused the error.

Then I'd say you jump to conclusions. There are other possible
explanations for what you are seeing.

Maybe "concluded" is the wrong word. "hypothesized" would
be more accurate.

<snip>

1) what is special about 33790? Why does the segfault keep occurring
at that point?

Does there have to be anything special about it?

No, but there seems to be. I'm hoping that understanding
what's happening here will give me some insight into memory
management. Trying to understand the OS, I figure understanding
the extreme cases will help. I'll peek around in
/proc/self/maps and see if I can correlate anything to the point
at which the error occurs. It may be completely pointless, but
it's guaranteed to be at least a little bit fun. (Which is to say
that I'll probably stop as soon as I get bored!)

.

Relevant Pages

  • [patch 2.6.28-rc6] when to BUG(), and when to not BUG()
    ... This matches my understanding of the standard policy ... ... seems not to be written down so far, outside of LKML messages ... * If you're tempted to BUG(), think again: ...
    (Linux-Kernel)
  • Re: Newbie
    ... I might very well use a debugger for that. ... it was about understanding a program. ... conditional breakpoint set to trigger if the point in the code is ... by a bug fix as soon as possible. ...
    (comp.programming)
  • Re: record count -1
    ... and a general lack of understanding of the different cursors types. ... was even a reported 'bug' in some ODBC driver that it returned an erronous ...
    (microsoft.public.vb.database.ado)
  • Re: large varchar columns in SQL server
    ... My understanding of the bug is that it could cause a simple script like ... This seems like basic functionality that should ... This email account is my spam trap so I ...
    (microsoft.public.inetserver.asp.db)
  • Re: memcpy with negative length and destination on heap - exploitable?
    ... 3> exploit this kind of bug: ... 3> dst = malloc; ... 3> it possible to avoid it if destination buffer is on heap? ... segfault and issues either a mallocor a freeon the corrupted ...
    (Vuln-Dev)