Stack corruption in 21.5b26

Fabrice Popineau Fabrice.Popineau at supelec.fr
Tue May 16 02:38:51 EDT 2006


* Aidan Kehoe <kehoea at parhasard.net> writes:

    >  Ar an triú lá déag de mí Bealtaine, scríobh Fabrice Popineau:
    >> I managed to compile the latest CVS natively under Win32 (and
    >> using my own setup ;-) but while trying the debug version, I got
    >> a stack corruption. The following patch cures it.

    > Cool, thank you for tracking it down. But are you sure the
    > corruption appears after Stephen~s patch of
    > http://mid.gmane.org/87slnt7nrq.fsf_-_@tleepslib.sk.tsukuba.ac.jp
    > was committed?  Because the first part of it looks like it would
    > have roughly the same effect on the stack as Stephen~s fix, and
    > the second part is an change to old code that~s been around for
    > ten years without provoking a bug.


Not at all. Stephen's patch was abour enlarging the buffer. But that
doesn't cure the fact that :

  Ibyte buf[DOC_MAX_FILENAME_LENGTH+1];
  Ibyte *buffer = buf;
  int buffer_size = sizeof (buf), space_left;
                    ^^^^^^^^^^^^
whatever the size of the buf[] array, buffer_size is set to this size.

  REGISTER Ibyte *p = buffer;

p and buffer point to the same location

  space_left = buffer_size - (p - buffer);

space_left is buffer_size

  while (space_left > 0)
    {
      int nread;

      nread = Lstream_read (XLSTREAM (instream), p, space_left);

You read buffer_size characters into buf[0 .. buffer_size - 1] that is the buf[] array is full

      p[nread] = 0;
^^^^^^^^^^^^^^^^^^^

and then you are accessing p[buffer_size] which is prohibited whatever
the real size of the buffer is, because your buf index goes from 0 to
buffer_size - 1.

I fixed it in both places but I can acknowledge only for the first one
causing a crash.

Fabrice




More information about the XEmacs-Beta mailing list