From: Simon Horman <horms@kernel.org>
To: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
"Kito Xu (veritas501)" <hxzene@gmail.com>,
Kees Cook <kees@kernel.org>,
linux-kernel@vger.kernel.org,
Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>,
Ao Wang <wangao@seu.edu.cn>, Xuewei Feng <fengxw06@126.com>,
Qi Li <qli01@tsinghua.edu.cn>, Ke Xu <xuke@tsinghua.edu.cn>,
stable@vger.kernel.org
Subject: Re: [PATCH net] appletalk: aarp: fix proxy probe conflict lookup
Date: Mon, 15 Jun 2026 13:20:01 +0100 [thread overview]
Message-ID: <20260615122001.GH712698@horms.kernel.org> (raw)
In-Reply-To: <20260613150104.1985-1-zhaoyz24@mails.tsinghua.edu.cn>
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;
prev parent reply other threads:[~2026-06-15 12:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-13 15:00 [PATCH net] appletalk: aarp: fix proxy probe conflict lookup Yizhou Zhao
2026-06-15 12:20 ` Simon Horman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260615122001.GH712698@horms.kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fengxw06@126.com \
--cc=hxzene@gmail.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=qli01@tsinghua.edu.cn \
--cc=stable@vger.kernel.org \
--cc=wangao@seu.edu.cn \
--cc=xuke@tsinghua.edu.cn \
--cc=yangyx22@mails.tsinghua.edu.cn \
--cc=zhaoyz24@mails.tsinghua.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.