From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCC1E2EA151 for ; Fri, 19 Jun 2026 06:24:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781850270; cv=none; b=sqFkTtKWcMeX0Irn+N5/t5L8vuVv+6vq/3dT7Z/BK5T7bMl1fc/ZaJuJuYzZJEcwPFJ2AQ3ydfDe8qQfTb9i4dN0wzLHfLIBc3DMxRkPXKoLlqSwXJiAXFxzwKEI+QmWHVRcc5aUEX2evA2Gl+jSzYOrIYkQ7v+noy6JlSZXUoA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781850270; c=relaxed/simple; bh=OoZCrcak6gnkvRgb2aPXGG5PzjptNHK/O7HUPMUPIaA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dqlI0MVFNaUBih1INKDA9L4ITOF0NGzSpUVebJhWrOvcrJgOOOoDl6RVzw/1Oos1t+vpyz1F2mVrH4c4AHQ6qw+sbx6kQl4UxBMJDvDEEfHXi/0ReEco4gzmj1wf5jXkApXEL77uEoItLiHKNMQEmtsIIIAKPb/aitDqey4mUw8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=baDOwNaZ; arc=none smtp.client-ip=95.215.58.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="baDOwNaZ" Message-ID: <3d21c10c-3ac5-48eb-9954-ac35c83e1495@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781850256; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p0WB5NKj40pwLNTx/NSVulZ0Mdm91bCb7Hsm/xNTiXc=; b=baDOwNaZ7C3G1K4mUAvB1/Fa9saA67VcATCbJ+L60a/ZmDEq73bTvi6MJkFmYwhTlq2r8v NehRtn+QmxZfgfxLY3ScIpX3S29v4pMJ+K8DI8pMFdtlxxkIcW6nrPArRd9JhTxGSjofw8 I9/a7W8kLGfrVP4+uO7FEU6tnWqIwk0= Date: Fri, 19 Jun 2026 14:24:05 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH net] ipv6: ndisc: fix NULL deref in accept_untracked_na() To: Weiming Shi , "David S . Miller" , David Ahern , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Xiang Mei References: <20260617065512.2529757-2-bestswngs@gmail.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Jiayuan Chen In-Reply-To: <20260617065512.2529757-2-bestswngs@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 6/17/26 2:55 PM, Weiming Shi wrote: > accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev) > and dereferences idev->cnf.accept_untracked_na without a NULL check, > even though its only caller ndisc_recv_na() already fetched and > NULL-checked idev for the same device. > > Both reads of dev->ip6_ptr run in the same RCU read-side critical > section, but a concurrent addrconf_ifdown() can clear dev->ip6_ptr > between them: lowering the MTU below IPV6_MIN_MTU calls addrconf_ifdown() > without the synchronize_net() that orders the unregister path, so the > re-fetch returns NULL and oopses: > > BUG: KASAN: null-ptr-deref in ndisc_recv_na (net/ipv6/ndisc.c:974) > Read of size 4 at addr 0000000000000364 > Call Trace: > > ndisc_recv_na (net/ipv6/ndisc.c:974) > icmpv6_rcv (net/ipv6/icmp.c:1193) > ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479) > ip6_input_finish (net/ipv6/ip6_input.c:534) > ip6_input (net/ipv6/ip6_input.c:545) > ip6_mc_input (net/ipv6/ip6_input.c:635) > ipv6_rcv (net/ipv6/ip6_input.c:351) > > > It is reachable by an unprivileged user via a network namespace. > > Pass the caller's already validated idev instead of re-fetching it; the > idev stays alive for the whole RCU critical section, so it is safe even > after dev->ip6_ptr has been cleared. > > Fixes: aaa5f515b16b ("net: ipv6: new accept_untracked_na option to accept na only if in-network") > Assisted-by: Claude:claude-opus-4-8 > Reported-by: Xiang Mei > Signed-off-by: Weiming Shi Reviewed-by: Jiayuan Chen