Forwarded: [PATCH] mm/workingset: add debug for corrupted shadow entry investigation

[syzbot <syzbot+e008db2ac01e282550ee@syzkaller.appspotmail.com>]

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] mm/workingset: add debug for corrupted shadow entry investigation
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


When pgdat is NULL in lru_gen_test_recent(), it indicates a corrupted
shadow entry. Currently returning false allows execution to continue,
which leads to a subsequent crash in filemap_read_folio() with a NULL
function pointer dereference.

Add debug output and stack dump to understand:
1. When pgdat is NULL (corrupted shadow entries)
2. The full call path leading to this situation
3. Why continuing execution after return false causes crashes

This will help determine the proper place to handle corrupted shadow
entries - either stop earlier in the call chain or handle the corruption
differently in lru_gen_test_recent().

Related-to: syzbot+e008db2ac01e282550ee@syzkaller.appspot.com
Link: https://syzkaller.appspot.com/bug?extid=e008db2ac01e282550ee
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 mm/workingset.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/mm/workingset.c b/mm/workingset.c
index e9f05634747a..a848572f8c8a 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -270,7 +270,13 @@ static bool lru_gen_test_recent(void *shadow, struct lruvec **lruvec,
 	struct pglist_data *pgdat;
 
 	unpack_shadow(shadow, &memcg_id, &pgdat, token, workingset);
-
+	if (unlikely(!pgdat)) {
+		pr_warn("FATAL: Corrupted shadow entry - pgdat is NULL! shadow=%p\n", shadow);
+		pr_warn("This indicates page cache corruption - cannot proceed\n");
+		dump_stack();
+		*lruvec = NULL;
+		return false;
+	}
 	memcg = mem_cgroup_from_id(memcg_id);
 	*lruvec = mem_cgroup_lruvec(memcg, pgdat);
 
-- 
2.43.0