[Xorp-hackers] Potential null pointer dereference.

[Ben Greear]

Bruce M. Simpson 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.

While doing my testing on virtual interfaces that come and go, I have 
hit these corner cases.  That is why I
added these fixes in the first place.  As previously mentioned, an 
interface can disappear at *any* time, so
you can *never* be absolutely certain that a system call to ask about a 
particular interface will work.
It's not easy to hit these races, so I can't give you a straight-forward 
way to reproduce it, but since it
obviously can happen, I think you should figure out how to not crash 
when it does.  For what it's worth,
my method seemed to work fine.

Either way, as Bruce admits, we can deref NULL in this case.  If you 
want to leave it a fatal assert,
that is your prerogative, but at least make it an assert and not just a 
SEGV.

Thanks,
Ben


>
> 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.
>
> 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.
>
> cheers
> BMS


-- 
Ben Greear <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com