From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94B3D383C92 for ; Tue, 4 Aug 2026 11:47:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785844024; cv=none; b=pe6iS/S0EqUcSr2WrbLFktb9BIB7INIWYOX4eedkp3wSTbcoM1q5Fm8dIDLaGi9R5VpgkGx7I5Y0Ox2FgpEg5882bd2lcszrVUkswcq+ewIhwDP0O8ktV9rFOeYYgyGrTVnpRO+Ge6tLYckf8BWFohVyIb8l7/RunvUPXdKGEU8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785844024; c=relaxed/simple; bh=XxqNS50tBpxlE2P29zTDYXh7Xwj62CrJ08IlelI2hk8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=dtmANtS3I3e7623DY6tsxh9yZrAl2UVEv00yYI4jWdVD1Gb2wAOz2H9Uuj15dqg4U4FHS/3ygwtM4OQvNwJHwcCbo/xqdGIwp1Mmwk+VvO0HcQyQ11atfcVjtnejNuSSZByEU4/YjirqhL7EMc/skqS21wJ7KV4ZIc+6F0hMAYY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=cT62ObCd; arc=none smtp.client-ip=209.85.214.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cT62ObCd" Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2ce98cb8165so10868055ad.1 for ; Tue, 04 Aug 2026 04:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785844022; x=1786448822; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=9tB62FksLX7ZQ0iAAw6nUq5NKmSatJoxx9sauneOGhA=; b=cT62ObCdeBUSqpxcFXDeB0uwsMFF4OSp9kkrSRWv8gPn3509GZuP2Qc32X1n8mvKtG 8Q7rMinJdZ5mEzCFoB+4gWbvE28UAXZWhLi4J9TpWTm5pPxuBv7MnScHzpSfHJ/d/Z6f KRQNRLWiippd9tu7Q5dUCFZKU1WTgrcbquO9buKbFZQar7Ar9KSBLz7aTZrNehFGh79O FeAbBXXQK7caryojF6gakiGQ4vro5582wU2rvGkh0q6OAz+CgnlN4z5WRTzNf0PiQQ9I m63mRcqmCKECcoA09Waxw7b8Ifyx7/wKkm6/dzYDTpenHoSVuls4Ie/Ee00KFbW21J1T MQyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785844022; x=1786448822; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=9tB62FksLX7ZQ0iAAw6nUq5NKmSatJoxx9sauneOGhA=; b=fxyfeqfZqr7p8drqtpXMD42rr3XiA7i2jNgcK/RsJxdI98CDVCV5trZ7ORCjvwF4Mq eQ1C2erMkSrxWBgsw9e43ckuSx4CgfQ8MxaNxxP8fXTKUfH5r1U+qQy2kPwTO5dDdc46 ix1TUOCG5pAgpEvx4KDrccY2uH34HDvB+mUVrkh+iLNAGcUiyFk07SvnVDHYnzEALKE3 zwoQhsBDdY/1A3VpNMvpPJoqMCZvICR/lOcMlqNe+MD4yJ6D2yM/0y2jK9aNI5uiURhh RRlieO10nOmRjbEJwM2KqZf4q2epjgR1fYtgVbnGsp7COJhbIYnm6Z2WVV9Ce4Od7/pc 3iOA== X-Forwarded-Encrypted: i=1; AHgh+RpNRbMwu+8Ko76lnOvzP8QEVMv/90aRPuFMMZkHOmo/UA3jsTthLUZ5bY8ftZ6x7HnF7ENVUIDZ6WqpQvg=@vger.kernel.org X-Gm-Message-State: AOJu0YzFsIkis2sLU3kI9LXZIQBsMn8KKP5Qar3nWc9KACnCuIabfHj1 /XoUSNnywUDseBN20tbwkrwHZ22TBmd27Pka/kBqE6QMrVHevXBscW6Y X-Gm-Gg: AR+sD13KIL+dzmwyC4urLVytCUnnKTESzvc1uBBmAilzDGJf8OIuHZmXBrojWxlDvAH p9A++418FUF2JmVuZn7CJUK8PN/WT6TudSwMX+x9WGe0jbJjaxu7qpurRcHTfIp7k82p5vvBRQb HDMhfn5cmUC82nnbVJIibDrUMI9M6LmIe1kCM+QnMJDmlYHJrzaLV8+ELvVrf31ewaAI1dfPAAa 9Rz9LNfhVWqhq1HsOTY/h6nSdR9Z1VijpV57CvudHmyPxj/iCTIa2Od6odvKJONht+aAdH2DM2F ayDXeGsuEdrmM5U+5ED7/4P7Hw2waxfiG6mQWpaYdy+j+JfADrfwk7lc3eK4eaN9YEHITwR8k// ialc9YLAzyvNmplpTSna813H/BbtsL8RZR3de3HGwux+hB+lw8D3LaYZvilcSLcvLGIsKiXGsOQ 9xifYi4a9U0Ntd26Mf99kqA086/ewWOofDk0ALNebKIGbClAbuwd8O8C/Cu8Tiw3ljNHbKNTtZl E8= X-Received: by 2002:a17:903:98f:b0:2cf:461a:3863 with SMTP id d9443c01a7336-2d08ab8bec3mr32019075ad.22.1785844021710; Tue, 04 Aug 2026 04:47:01 -0700 (PDT) Received: from online.mioffice.cn ([43.224.245.228]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d0aa013dafsm5778535ad.35.2026.08.04.04.46.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 04:47:01 -0700 (PDT) From: Pengfei Zhang To: stable@vger.kernel.org Cc: gregkh@linuxfoundation.org, sashal@kernel.org, davem@davemloft.net, dsahern@kernel.org, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, idosch@nvidia.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, zhangpengfei16@xiaomi.com, Pengfei Zhang Subject: [PATCH 5.10.y 6.1.y 6.6.y] ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump Date: Tue, 4 Aug 2026 19:46:54 +0800 Message-ID: <20260804114655.179105-1-zhangfeionline@gmail.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit commit 9facb861dc6b9b9ea9793ef5032a9a826f7a4229 upstream. inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:fib6_walk_continue+0x6e/0x170 Call Trace: fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 Fix by storing tb->tb6_id in cb->args[1] instead of a positional index. On resume, skip entries until the id matches; a concurrent head-insert can never match the saved id, so the walker always resumes on the correct table. Fixes: 1b43af5480c3 ("[IPV6]: Increase number of possible routing tables to 2^32") Signed-off-by: Pengfei Zhang Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20260625070517.965597-1-zhangfeionline@gmail.com Signed-off-by: Jakub Kicinski [Adapted to 5.10/6.1/6.6: inet6_dump_fib() there predates 22e36ea9f5d7 and 5fc68320c1fb, so the return variable is "res" not "err" and the RCU-protected hash walk exits via "out_unlock" instead of "unlock". Context-only change; the fix itself is identical.] Signed-off-by: Pengfei Zhang --- Notes for maintainers, not for the changelog: This fix was picked up for 5.15.y, 6.12.y, 6.18.y and 7.1.y, but silently dropped for 5.10.y, 6.1.y and 6.6.y, where it does not apply. Those three are the only maintained trees still missing it. The two mainline commits that reshaped inet6_dump_fib() are 22e36ea9f5d7 ("inet: allow ip_valid_fib_dump_req() to be called with RTNL or RCU") -- v6.9 5fc68320c1fb ("ipv6: remove RTNL protection from inet6_dump_fib()") -- v6.10 6.12.y and later already contain both, since they branched off after v6.10. 5.15.y had both backported as prerequisites together with the fix, which is why the unmodified patch applied there. 5.10.y, 6.1.y and 6.6.y never received them, so the upstream patch no longer applies. I did not backport those two commits on purpose: they are RTNL scalability work rather than fixes, and 22e36ea9f5d7 touches six files including common inet code. Re-contextualising the fix is the smaller and safer change for these trees. The race is unaffected by the locking difference -- it happens between netlink dump batches, when no lock is held at all -- so the older RTNL-held shape is equally exposed. inet6_dump_fib() is byte-for-byte identical in 5.10.262, 6.1.180 and 6.6.148, so this single patch covers all three. Build- and boot-tested on each of them. net/ipv6/ip6_fib.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -625,11 +625,11 @@ const struct nlmsghdr *nlh = cb->nlh; struct net *net = sock_net(skb->sk); unsigned int h, s_h; - unsigned int e = 0, s_e; struct fib6_walker *w; struct fib6_table *tb; struct hlist_head *head; int res = 0; + u32 s_id; if (cb->strict_check) { int err; @@ -687,25 +687,24 @@ } s_h = cb->args[0]; - s_e = cb->args[1]; + s_id = cb->args[1]; rcu_read_lock(); - for (h = s_h; h < FIB6_TABLE_HASHSZ; h++, s_e = 0) { - e = 0; + for (h = s_h; h < FIB6_TABLE_HASHSZ; h++, s_id = 0) { head = &net->ipv6.fib_table_hash[h]; hlist_for_each_entry_rcu(tb, head, tb6_hlist) { - if (e < s_e) - goto next; + if (s_id && tb->tb6_id != s_id) + continue; + + s_id = 0; + cb->args[1] = tb->tb6_id; res = fib6_dump_table(tb, skb, cb); if (res != 0) goto out_unlock; -next: - e++; } } out_unlock: rcu_read_unlock(); - cb->args[1] = e; cb->args[0] = h; out: res = res < 0 ? res : skb->len; -- 2.54.0