netdev - Re: [PATCH] neigh: error out pending skbs if netlink invalidates incomplete neigh

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A30D781.2020403@iki.fi>
Date:	Thu, 11 Jun 2009 13:08:01 +0300
From:	Timo Teräs <timo.teras@....fi>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH] neigh: error out pending skbs if netlink invalidates
 incomplete neigh

David Miller wrote:
> From: Timo Teras <timo.teras@....fi>
> Date: Thu,  4 Jun 2009 11:40:55 +0300
> 
>> The state transition code from incomplete to invalid via neigh_update()
>> is missing the proper clean up of skb queue. Separate the clean up
>> code from neigh_timer_handler() to a new function and make neigh_update()
>> is it also.
>>
>> Signed-off-by: Timo Teras <timo.teras@....fi>
> 
> We don't error out pending SKBs on the state transition alone, we do
> it when we have the state transition _AND_ the number of probes
> exceeds the limit.
> 
> And it seems that behavior is very much intentional.
> 
> I'm not going to apply this.

When the state is changed to FAILED by netlink, the timer is stopped
and further probes are not tried anymore. This results in that the
skb's are not errored. The neigh entry is left stale.

The behaviour is flawed currently. Either we need to prevent state
change from INCOMPLETE -> FAILED via netlink and keep on sending probes,
or flush the queue when userland replies with FAILED. Otherwise the
neigh entry state is left bad.

- Timo

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html