From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 258932E7F0A for ; Mon, 8 Dec 2025 11:24:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765193092; cv=none; b=p/Y1EDBl8dNpJ+S7ErMXYZwVT6vOHAq+oMJokG43dGzi2ekepELeTvy0R5btXTnYkpZBRSyCyXY4I+gWAAXoAOKVC7elxMuffqACuKoTK6j8r9zrdg7HW4S06M78P5Mt4WvXDN3Mf+Yv3wEWRWZAn7Qe7ZL7iFsEto5IIof86nc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765193092; c=relaxed/simple; bh=fC/24Oc3hf4PxmCbW821UhQo/NgsLPZaEn7uaZClSa8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kSyOEZmtq8DeS9PUi+sstNPzLCQhhYgqPdd1hCr1JLZAZo5vBWcptly9s2k+lFfhcxCI58WNytYNkOM1eOD/rgNjcEs8RJNA6MlH544Yn5UptRxphhcT3qC96orATrkdBHIGnVQCVOwCelG41xm5GxT33EnKQU87ndI1sSMZXyc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Zk0C0EKY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Zk0C0EKY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2753BC4CEF1; Mon, 8 Dec 2025 11:24:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765193091; bh=fC/24Oc3hf4PxmCbW821UhQo/NgsLPZaEn7uaZClSa8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Zk0C0EKYfYOApC+Dr//4eGf69mnRDReQefVGpqs8iACGOs2ex0hcMYsQ0iIM+RQLo 087o3F+wVYAZkzbhlnTb3Rvs05O2Vn430vXpJjfLeyLwbpvD8n1wWXyuhJOr8OvK6R 2ARaOW6Qi4mCxXTciDGPgtg8n1AG0Moh3vqNEOJFOhTD+47L3oPH4ys1ahbLIXaWpg m0+1j6QhN+uMiVL7hNGcGEfBYMBdeDIqZQiTjHSbey3C+dqrwl4d8Bv7y8QjB8Ta7W jaHPPSh6B++lk1nDEsYPQgYDRio6E6MkZoaE+hXh1yyvLR4msAY+EmqkVS8ZKemsMO k75/bKb2p3azQ== Message-ID: Date: Mon, 8 Dec 2025 12:24:45 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/workingset: fix crash from corrupted shadow entries in lru_gen To: Deepanshu Kartikey , akpm@linux-foundation.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, hannes@cmpxchg.org, mhocko@kernel.org, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, lorenzo.stoakes@oracle.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot+e008db2ac01e282550ee@syzkaller.appspot.com, Yu Zhao References: <20251208060046.2933866-1-kartikey406@gmail.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251208060046.2933866-1-kartikey406@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/8/25 07:00, Deepanshu Kartikey wrote: > Syzbot reported crashes in lru_gen_test_recent() and subsequent NULL > pointer dereferences in the page cache code: > > Oops: general protection fault in lru_gen_test_recent+0xfc/0x370 > KASAN: probably user-memory-access in range [0x0000000000004e00-0x0000000000004e07] > > And later: > > BUG: kernel NULL pointer dereference, address: 0000000000000000 > #PF: supervisor instruction fetch in kernel mode > RIP: 0010:0x0 > Call Trace: > filemap_read_folio+0xc8/0x2a0 > > Investigation revealed that unpack_shadow() can extract an invalid node ID > from shadow entries, causing NODE_DATA(nid) to return NULL for pgdat. In > the reported case, the shadow value was 0x0000000000000041, which is > suspiciously small and indicates corruption. > > When this NULL pgdat is passed to mem_cgroup_lruvec(), it leads to crashes > when dereferencing memcg->nodeinfo. The corrupted state also propagates > through the call chain causing subsequent crashes in page cache code. > > The root cause of shadow entry corruption is unclear and may indicate a > deeper issue in xarray management, page cache eviction/refault race > conditions, or memory corruption. However, regardless of the source, the > code should handle corrupted entries defensively. We should identify+fix the root cause. [...] > - > + /* > + * If pgdat is NULL, the shadow entry contains an invalid node ID. > + * Set lruvec to NULL so caller can detect and skip processing. > + */ > + if (unlikely(!pgdat)) { > + *lruvec = NULL; > + return false; > + } That's just hacking around the root cause, no? Because IIUC, that's not something we would ever expect to happen unless BUG. Unless I am missing something this patch is trying to cure the symptoms, but not the root cause. Now, if it would be valid (and we would not have a corruption), then handling it like you propose would be the right thing. -- Cheers David