fs/jfs/jfs_metapage.c | 1 + 1 file changed, 1 insertion(+)
From: Shaurya Rane <ssrane_b23@ee.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+e87be72c9a6fe69996f5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e87be72c9a6fe69996f5
Signed-off-by: Shaurya Rane <ssrane_b23@ee.vjti.ac.in>
---
Tested:
- Tested locally with syzbot reproducer, no errors observed
Changelog:
- Correct bug link
- Corrected patch format
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
From: Shaurya Rane <ssrane_b23@ee.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+e87be72c9a6fe69996f5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e87be72c9a6fe69996f5
Signed-off-by: Shaurya Rane <ssrane_b23@ee.vjti.ac.in>
---
Tested:
- Tested locally with syzbot reproducer, no errors observed
Changelog:
- Correct bug link
- Corrected patch format
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
Pinging if missed On Sat, Nov 8, 2025 at 7:48 PM <ssrane_b23@ee.vjti.ac.in> wrote: > > From: Shaurya Rane <ssrane_b23@ee.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+e87be72c9a6fe69996f5@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=e87be72c9a6fe69996f5 > Signed-off-by: Shaurya Rane <ssrane_b23@ee.vjti.ac.in> > > --- > Tested: > - Tested locally with syzbot reproducer, no errors observed > Changelog: > - Correct bug link > - Corrected patch format > > 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 >
On 11/22/25 8:42PM, SHAURYA RANE wrote: > Pinging if missed Sorry, I've been flooded with some other work and was also out on vacation a bit during the past month. I'm trying to catch up on a bunch of submitted patches now. Please be patient. Thanks, Shaggy > > On Sat, Nov 8, 2025 at 7:48 PM <ssrane_b23@ee.vjti.ac.in> wrote: >> >> From: Shaurya Rane <ssrane_b23@ee.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+e87be72c9a6fe69996f5@syzkaller.appspotmail.com >> Closes: https://syzkaller.appspot.com/bug?extid=e87be72c9a6fe69996f5 >> Signed-off-by: Shaurya Rane <ssrane_b23@ee.vjti.ac.in> >> >> --- >> Tested: >> - Tested locally with syzbot reproducer, no errors observed >> Changelog: >> - Correct bug link >> - Corrected patch format >> >> 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 >>
© 2016 - 2025 Red Hat, Inc.