linux-kernel - [PATCH] jfs: Initialize synclist in metapage allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20251107200645.149093-1-ssranevjti@gmail.com>
Date: Sat,  8 Nov 2025 01:36:45 +0530
From: ssrane_b23@...vjti.ac.in
To: shaggy@...nel.org
Cc: jfs-discussion@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org,
	dsterba@...e.com,
	david@...hat.com,
	shivankg@....com,
	skhan@...uxfoundation.org,
	linux-kernel-mentees@...ts.linux.dev,
	david.hunter.linux@...il.com,
	khalid@...nel.org,
	Shaurya Rane <ssrane_b23@...vjti.ac.in>,
	syzbot+cfc7cab3bb6eaa7c4de2@...kaller.appspotmail.com
Subject: [PATCH] jfs: Initialize synclist in metapage allocation

From: Shaurya Rane <ssrane_b23@...vjti.ac.in>

The synclist field in struct metapage was not being initialized during
allocation in alloc_metapage(), leading to list corruption when the
metapage is later added to a transaction's sync list.

When diUpdatePMap() calls list_add(&mp->synclist, &tblk->synclist), if
the synclist field contains stale data from a previous allocation (such
as LIST_POISON values from a freed list node), the list debugging code
detects the corruption and triggers a stack segment fault.

This issue is intermittent because it only manifests when recycled
memory happens to contain poison values in the synclist field. The bug
was discovered by syzbot, which creates specific filesystem patterns
that reliably trigger this uninitialized memory usage.

Initialize the synclist field with INIT_LIST_HEAD() in alloc_metapage()
to ensure it's in a valid state before being used in list operations.
This is consistent with how the wait queue is initialized in the same
function.

Reported-by: syzbot+cfc7cab3bb6eaa7c4de2@...kaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=cfc7cab3bb6eaa7c4de2
Signed-off-by: Shaurya Rane <ssrane_b23@...vjti.ac.in>

---
Tested:
 - Tested locally with syzbot reproducer, no errors observed

 fs/jfs/jfs_metapage.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/jfs/jfs_metapage.c b/fs/jfs/jfs_metapage.c
index 871cf4fb3636..77c512a0a42b 100644
--- a/fs/jfs/jfs_metapage.c
+++ b/fs/jfs/jfs_metapage.c
@@ -269,6 +269,7 @@ static inline struct metapage *alloc_metapage(gfp_t gfp_mask)
 		mp->data = NULL;
 		mp->clsn = 0;
 		mp->log = NULL;
+		INIT_LIST_HEAD(&mp->synclist);
 		init_waitqueue_head(&mp->wait);
 	}
 	return mp;
-- 
2.34.1