[PATCH v3] jfs: Initialize synclist in metapage allocation

[PATCH v3] jfs: Initialize synclist in metapage allocation

[ssrane_b23]

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

[PATCH v3] jfs: Initialize synclist in metapage allocation

[ssrane_b23]

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

Re: [PATCH v3] jfs: Initialize synclist in metapage allocation

[SHAURYA RANE]

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
>

Re: [PATCH v3] jfs: Initialize synclist in metapage allocation

[Dave Kleikamp]

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
>>