Re: dn_neigh_table vs pneigh_lookup/pneigh_delete

2007-12-20 Thread Steven Whitehouse
Hi,

On Wed, Dec 19, 2007 at 05:11:34PM +0300, Pavel Emelyanov wrote:
 Hi
 
 The pneigh_lookup/delete silently concerns, that the 
 key_len of the table is more that 4 bytes. Look:
 
  u32 hash_val = *(u32 *)(pkey + key_len - 4);
 
 The hash_val for the proxy neighbor entry is four last bytes
 from the pkey.
 
 But the dn_neigh_tables' key_len is sizeof(__le16), that is 2,
 so setting (via netlink) the proxy neighbor entry for decnet 
 will cause this entry to reside in arbitrary hash chain.
 
 Is this too bad for decnet?
 
 Thanks,
 Pavel
The pneigh code is never used in DECnet, we only use the normal
part of the neigh code where the hash function was changed so that
it can be defined for each protocol (and thus doesn't suffer from
this problem)

Steve.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


dn_neigh_table vs pneigh_lookup/pneigh_delete

2007-12-19 Thread Pavel Emelyanov
Hi

The pneigh_lookup/delete silently concerns, that the 
key_len of the table is more that 4 bytes. Look:

 u32 hash_val = *(u32 *)(pkey + key_len - 4);

The hash_val for the proxy neighbor entry is four last bytes
from the pkey.

But the dn_neigh_tables' key_len is sizeof(__le16), that is 2,
so setting (via netlink) the proxy neighbor entry for decnet 
will cause this entry to reside in arbitrary hash chain.

Is this too bad for decnet?

Thanks,
Pavel
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html