Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
family == AF_INET. For most purposes this is fine, since the two modules
each hold a pointer to their table and pass it into the neigh_* functions.
A problem arises in neigh_add, which is called by the rtnetlink code and
which iterates through all the neighbour tables looking for the first
one with the correct family. Since there are two different tables with
family == AF_INET, sometimes it picks the wrong one.
This leads to the situation where sending a RTM_NEWNEIGH message via
netlink can generate an ignored and useless entry in the clip table,
whilst the not affecting another entry in the ARP table, both entries
for the same IP.
Viz:
sid:~# ip neigh
192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE
192.168.3.40 dev eth0 FAILED
It's not immediately obvious how to fix this in a conceptually clean
manner: neighbour tables are not associated with single netdevices, and
they don't carry an address-type field. Given a {IP,lladdr,device}
triple, its easy to determine if the device is ether-like or CLIP, but
then the update call would have to go via the ARP and CLIP modules,
instead of direct to the neighbour module in an address independent way.
New address types would need further additions to the netlink/neighbour
code.
OTOH there are several obvious hacks that will fix the immediate
problem. I'm happy to provide a patch implementing one if that's desired.
Looking again, I think this is also a security hole, since the CLIP code
keeps a whole struct including pointers in the neighbour table entry
where ARP has the MAC address. So this might provide a way to poke
arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though.
Cheers,
Simon.
On Wed, 03 May 2006 22:32:39 +0100
Simon Kelley <[email protected]> wrote:
> Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
> family == AF_INET. For most purposes this is fine, since the two modules
> each hold a pointer to their table and pass it into the neigh_* functions.
>
> A problem arises in neigh_add, which is called by the rtnetlink code and
> which iterates through all the neighbour tables looking for the first
> one with the correct family. Since there are two different tables with
> family == AF_INET, sometimes it picks the wrong one.
>
> This leads to the situation where sending a RTM_NEWNEIGH message via
> netlink can generate an ignored and useless entry in the clip table,
> whilst the not affecting another entry in the ARP table, both entries
> for the same IP.
>
> Viz:
> sid:~# ip neigh
> 192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE
> 192.168.3.40 dev eth0 FAILED
>
>
> It's not immediately obvious how to fix this in a conceptually clean
> manner: neighbour tables are not associated with single netdevices, and
> they don't carry an address-type field. Given a {IP,lladdr,device}
> triple, its easy to determine if the device is ether-like or CLIP, but
> then the update call would have to go via the ARP and CLIP modules,
> instead of direct to the neighbour module in an address independent way.
> New address types would need further additions to the netlink/neighbour
> code.
>
> OTOH there are several obvious hacks that will fix the immediate
> problem. I'm happy to provide a patch implementing one if that's desired.
>
> Looking again, I think this is also a security hole, since the CLIP code
> keeps a whole struct including pointers in the neighbour table entry
> where ARP has the MAC address. So this might provide a way to poke
> arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though.
>
This was fixed in 2.6.16.6 and current 2.6.17