[PATCH net] appletalk: aarp: fix proxy probe conflict lookup

[PATCH net] appletalk: aarp: fix proxy probe conflict lookup

[Yizhou Zhao]

aarp_rcv() computes hash from the packet source node and later uses it
for the normal AARP reply lookup against the unresolved table. The same
hash is also reused earlier for the proxy probe conflict check, but that
check builds its lookup key from the packet destination address.

Proxy AARP entries are inserted into the proxy table using the proxied
address node as the hash key. AARP packets are not required to have the
same source and destination node numbers, so the proxy probe conflict
check can search the wrong bucket and miss an entry that is still in
ATIF_PROBE state.

If that happens, SIOCSARP can accept a proxy address even though a
conflicting AARP packet was observed on the wire. This can create
duplicate AppleTalk address ownership. Depending on the network setup,
traffic for that address may then be misdirected, or the address may
become intermittently unreachable.

Look up the proxy probe entry using a hash derived from da.s_node, which
matches how proxy entries are inserted and removed. Leave the source-node
hash unchanged for the later unresolved-entry reply handling.

In a veth/SNAP/AARP reproducer on a KASAN-enabled kernel, a conflicting
AARP packet with different source and destination nodes allowed SIOCSARP
to succeed before this change. With this change, the same conflict
returns EADDRINUSE, while a no-conflict proxy add still succeeds.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: GLM:GLM-5.1
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
---
 net/appletalk/aarp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
index 078fb7a6efa5..1352ede79668 100644
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -755,7 +755,8 @@ static int aarp_rcv(struct sk_buff *skb, struct net_device *dev,
 	da.s_net  = ea->pa_dst_net;
 
 	write_lock_bh(&aarp_lock);
-	a = __aarp_find_entry(proxies[hash], dev, &da);
+	a = __aarp_find_entry(proxies[da.s_node % (AARP_HASH_SIZE - 1)],
+			      dev, &da);
 
 	if (a && a->status & ATIF_PROBE) {
 		a->status |= ATIF_PROBE_FAIL;
-- 
2.43.0

Re: [PATCH net] appletalk: aarp: fix proxy probe conflict lookup

[Simon Horman]

On Sat, Jun 13, 2026 at 11:00:59PM +0800, Yizhou Zhao wrote:
> aarp_rcv() computes hash from the packet source node and later uses it
> for the normal AARP reply lookup against the unresolved table. The same
> hash is also reused earlier for the proxy probe conflict check, but that
> check builds its lookup key from the packet destination address.
> 
> Proxy AARP entries are inserted into the proxy table using the proxied
> address node as the hash key. AARP packets are not required to have the
> same source and destination node numbers, so the proxy probe conflict
> check can search the wrong bucket and miss an entry that is still in
> ATIF_PROBE state.
> 
> If that happens, SIOCSARP can accept a proxy address even though a
> conflicting AARP packet was observed on the wire. This can create
> duplicate AppleTalk address ownership. Depending on the network setup,
> traffic for that address may then be misdirected, or the address may
> become intermittently unreachable.
> 
> Look up the proxy probe entry using a hash derived from da.s_node, which
> matches how proxy entries are inserted and removed. Leave the source-node
> hash unchanged for the later unresolved-entry reply handling.
> 
> In a veth/SNAP/AARP reproducer on a KASAN-enabled kernel, a conflicting
> AARP packet with different source and destination nodes allowed SIOCSARP
> to succeed before this change. With this change, the same conflict
> returns EADDRINUSE, while a no-conflict proxy add still succeeds.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
> Reported-by: Ao Wang <wangao@seu.edu.cn>
> Reported-by: Xuewei Feng <fengxw06@126.com>
> Reported-by: Qi Li <qli01@tsinghua.edu.cn>
> Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
> Assisted-by: GLM:GLM-5.1
> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
> ---
>  net/appletalk/aarp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
> index 078fb7a6efa5..1352ede79668 100644
> --- a/net/appletalk/aarp.c
> +++ b/net/appletalk/aarp.c
> @@ -755,7 +755,8 @@ static int aarp_rcv(struct sk_buff *skb, struct net_device *dev,
>  	da.s_net  = ea->pa_dst_net;
>  
>  	write_lock_bh(&aarp_lock);
> -	a = __aarp_find_entry(proxies[hash], dev, &da);
> +	a = __aarp_find_entry(proxies[da.s_node % (AARP_HASH_SIZE - 1)],
> +			      dev, &da);

Hi Yinzhou,

I wonder if __aarp_proxy_find() can be used here.

>  
>  	if (a && a->status & ATIF_PROBE) {
>  		a->status |= ATIF_PROBE_FAIL;