aarp_alloc() allocates struct aarp_entry without zeroing it, but only
initializes refcnt and packet_queue.  When an unresolved AARP entry is
created, hwaddr[ETH_ALEN] is left uninitialized.

aarp_seq_show() later prints this field with %pM when users read
/proc/net/atalk/arp.  This can expose 6 bytes of stale heap data for
each unresolved entry.

Fix this by zero-initializing struct aarp_entry at allocation time.

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>
---
diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
index e7315c0..9490395 100644
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -393,7 +393,7 @@ static void aarp_purge(void)
  */
 static struct aarp_entry *aarp_alloc(void)
 {
-	struct aarp_entry *a = kmalloc_obj(*a, GFP_ATOMIC);
+	struct aarp_entry *a = kzalloc_obj(*a, GFP_ATOMIC);
 	if (!a)
 		return NULL;
 

--
2.43.0

On Fri, May 29, 2026 at 06:50:16PM +0800, Yizhou Zhao wrote:
> aarp_alloc() allocates struct aarp_entry without zeroing it, but only
> initializes refcnt and packet_queue.  When an unresolved AARP entry is
> created, hwaddr[ETH_ALEN] is left uninitialized.
> 
> aarp_seq_show() later prints this field with %pM when users read
> /proc/net/atalk/arp.  This can expose 6 bytes of stale heap data for
> each unresolved entry.
> 
> Fix this by zero-initializing struct aarp_entry at allocation time.
> 
> 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>

Reviewed-by: Simon Horman <horms@kernel.org>

FTR, there is an AI generated review of this patch available on sashiko.dev.
However, the issues flagged there appear to be pre-existing and I do not
believe they should block progress of this patch.