[Xorp-hackers] Potential null pointer dereference.

[Pavlin Radoslavov]

Bruce M Simpson <bms at incunabulum.net> wrote:

> Pavlin Radoslavov wrote:
> > The reason those XLOG statements are FATAL is to capture bugs that
> > might be hiding somewhere else.
> > If you were able to trigger those statements, could you provide
> > instructions how to reproduce the problem so we can investigate it.
> >   
> 
> +1.
> 
> Whilst Ben's patches are well intentioned, they do not fully address the
> issues, and you correctly point out they most likely mask the underlying
> issue.
> 
> There is definitely a corner case in the first situation, where vifp may
> be NULL and yet be dereferenced when is_deleted is true. This applies to
> all netlink socket processing.

Yes, the NULL pointer dereferencing was a bug which is now fixed.

> In the second situation, it looks like the case where the FEA is told of
> a new interface event by Linux, for an interface which it doesn't know
> about, this is treated as a fatal error by the FEA.

The interface event is addition of a new address to an interface.
Obviously, the kernel must first tell the FEA that an interface is
added/exists and only then the "new address" event should be send.
Hence, it is a mystery for me when/why the XLOG_FATAL() there is
triggered.

> It looks like this issue is also present in the PF_ROUTE support code.
> 
> Now this reminds me of a situation I saw when testing out the
> forthcoming OLSR code, under both FreeBSD and Linux. I haven't recorded
> the details as it hasn't been an immediate priority, however it IS a
> looming issue.
> 
> Hot swapping an interface seems to have problems -- that is, if I fire
> up a full XORP router with an OLSR process, remove its configuration for
> an interface, add a new interface to the underlying system, and then
> attempt to bring up OLSR on the new interface, the FEA does not
> recognise the new interface.
> 
> Looking at the code it appears this is the case. There's a clear need to
> be able to add interfaces at runtime to support hot swapping of network
> interfaces for both ad-hoc and classic routing protocols.
> 
> Could we be looking at the same underlying issue?
> 
> I was under the impression the FEA could deal with learning about new
> interfaces at runtime, this evidence seems to suggest it doesn't and
> needs fixing.

Yes, the most recent code in CVS is suppose to work with hot-swapped
interfaces.
If you are hitting some errors/crashes this is probably because of
some remaining bugs.
Obviously, those bugs will remain in the code if they are not
reported.

Thanks,
Pavlin