From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta1.migadu.com (out-173.mta1.migadu.com [95.215.58.173]) (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 D1B15175A6C for ; Fri, 19 Jun 2026 06:24:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781850261; cv=none; b=bZIkGcYF9NORM4NX1E/l/PB8KvO3MLLPZuEQqDOl/dloAfJkXHqyUZ31K+2AWvZe6mvjK0+8yXYVYuVt/idZ6bwcO8TyqOrpka3QvIcqUIkn0uIVniHyFTyZsuWnQgeWc+rEJW3bbmJJtylE4i7PU//uR/Pk2TEKw1EGPnaz0OI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781850261; c=relaxed/simple; bh=OoZCrcak6gnkvRgb2aPXGG5PzjptNHK/O7HUPMUPIaA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=I2pytHjRqbh+PVDJ2hG3hdaJIwT65T1sFS4YND1Mz4zzr0E1pw2vhjT2YbQ4iQMLbuQQx27Wcku1YK0VByU2ykQiPCHrfODYrg3Jb6FUUv81yTsD6VS2a05WhFf5TDaCZ2Anxdc8WiMxfdLVafeFLFuMvxtILTMOeClAruv+yG8= 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.173 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: linux-kernel@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