[Patches] [ python-Patches-645404 ] fix buffer overrun in pmerge

noreply@sourceforge.net noreply@sourceforge.net
Fri, 29 Nov 2002 02:06:28 -0800


Patches item #645404, was opened at 2002-11-28 20:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645404&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix buffer overrun in pmerge

Initial Comment:
It sometimes overruns the PyList "j_lst".  I don't
understand the algorithm here, so my fix is just based
on the fact that when it *does* overrun, the data it
reads probably doesn't == candidate, so I changed it to
behave in the '!= candidate' way when it reaches the
end of j_lst.

Someone who actually knows what this function actually
does should probably have a look at this patch.

Python passes its unit tests both before and after this
patch.  Presumably there is a very small chance (< 1 in
4 billion) that it will behave incorrectly when it
reads data that does happen to == candidate.  Also I
think there is a very small chance that it could get a
memory protection violation.

This bug was found with valgrind.  It's not your
father's memory debugger!  Valgrind has an extremely
low occurrence of false alarms, since it keeps track of
validity status for *every* *bit* of data, while
running your program in valgrind's internal x86
interpreter.  It does *not* complain unless you do
something that is extremely likely to be fatally wrong,
such as branching on uninitialized data or writing to
unallocated memory.

This is the only bug revealed by running valgrind
unstable snapshot on Python CVS HEAD's self-test.

Here is a "suppression" file to ignore one particularly
amazing stunt that Python pulls.  This suppression file
is for valgrind v1:
# add the cmdline arg `--suppressions=thisfile' when
invoking valgrind

    {
    PyObject_Free_Cond_inblock_Cond_okay
    Cond
    fun:PyObject_Free
    }

  {
    PyObject_Free_Cond_inblock_Value4_okay
    Value4
    fun:PyObject_Free
  }

  {
    PyObject_Free_Cond_inblock_Addr4_okay
    Addr4
    fun:PyObject_Free
  }

  {
    PyObject_Realloc_Cond_inblock_Cond_okay
    Cond
    fun:PyObject_Realloc
  }

  {
    PyObject_Realloc_Cond_inblock_Value4_okay
    Value4
    fun:PyObject_Realloc
  }

  {
    PyObject_Realloc_Cond_inblock_Addr4_okay
    Addr4
    fun:PyObject_Realloc
  }


Here are the same suppression rules for the unstable
snapshot of valgrind 2:

# add the cmdline arg `--suppressions=thisfile' when
invoking valgrind

    {
    PyObject_Free_Cond_inblock_Cond_okay
    Memcheck:Cond
    fun:PyObject_Free
    }

  {
    PyObject_Free_Cond_inblock_Value4_okay
    Memcheck:Value4
    fun:PyObject_Free
  }

  {
    PyObject_Free_Cond_inblock_Addr4_okay
    Memcheck:Addr4
    fun:PyObject_Free
  }

  {
    PyObject_Realloc_Cond_inblock_Cond_okay
    Memcheck:Cond
    fun:PyObject_Realloc
  }

  {
    PyObject_Realloc_Cond_inblock_Value4_okay
    Memcheck:Value4
    fun:PyObject_Realloc
  }

  {
    PyObject_Realloc_Cond_inblock_Addr4_okay
    Memcheck:Addr4
    fun:PyObject_Realloc
  }



----------------------------------------------------------------------

>Comment By: Martin v. L÷wis (loewis)
Date: 2002-11-29 11:06

Message:
Logged In: YES 
user_id=21627

Can you provide a source code example that triggers the 
problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645404&group_id=5470