tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: rtsock.c:rt_msg2() appears to be overwriting buffers it does not own



On Fri, Oct 24, 2008 at 02:43:12PM +0000, Christos Zoulas wrote:
> >
> >I think that this does pretty firmly point the finger at a routing
> >table update that is exceeding its allocated memory and stomping the
> >memory after it.  If this is really the case, I am not sure how to fix
> >it - the whole routing update thing looks like a bit of a MP disaster
> >as there appears to be no locking about any of the updates.  Ideas?
> 
> Are you sure it is the routing code? It could be the sysctl_iflist() one too.
> Can you put some more debugging code to verify? I am saying that because
> the sysctl_rtable() is protected with splsoftnet(), but the sysctl_iflist()
> is not, and perhaps it should.
> 

Reasonably certain.  There is only one place in rtsock.c that
rt_msg2() is called with cpv non-NULL and that is in route_output().
If cpv is NULL then the bottom end of rt_msg2() allocates memory and
then flow loops back to the top with second_time set true - the
message I output changes depending on the state of second_time.  The
message we are seeing indicates that a) cp is non-NULL and b)
second_time is not set.

As a kludge we hard coded the required len to 1024 bytes to provide a
buffer far larger than the debug messages said was needed and tried
running with that.  The debug messages no longer fired and the
freelist corruptions were no longer reported when the ppp connection
went down.

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."




Home | Main Index | Thread Index | Old Index