[PATCH] f2fs: fix UAF issue in f2fs_merge_page_bio()

[PATCH] f2fs: fix UAF issue in f2fs_merge_page_bio()

[Jiucheng Xu via B4 Relay]

From: Jiucheng Xu <jiucheng.xu@amlogic.com>

commit edf7e9040fc52c922db947f9c6c36f07377c52ea upstream.

As JY reported in bugzilla [1],

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
pc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98
lr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4
CPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P    B   W  OE      6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5
Tainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Workqueue: writeback wb_workfn (flush-254:49)
Call trace:
 f2fs_is_cp_guaranteed+0x70/0x98
 f2fs_inplace_write_data+0x174/0x2f4
 f2fs_do_write_data_page+0x214/0x81c
 f2fs_write_single_data_page+0x28c/0x764
 f2fs_write_data_pages+0x78c/0xce4
 do_writepages+0xe8/0x2fc
 __writeback_single_inode+0x4c/0x4b4
 writeback_sb_inodes+0x314/0x540
 __writeback_inodes_wb+0xa4/0xf4
 wb_writeback+0x160/0x448
 wb_workfn+0x2f0/0x5dc
 process_scheduled_works+0x1c8/0x458
 worker_thread+0x334/0x3f0
 kthread+0x118/0x1ac
 ret_from_fork+0x10/0x20

[1] https://bugzilla.kernel.org/show_bug.cgi?id=220575

The panic was caused by UAF issue w/ below race condition:

kworker
- writepages
 - f2fs_write_cache_pages
  - f2fs_write_single_data_page
   - f2fs_do_write_data_page
    - f2fs_inplace_write_data
     - f2fs_merge_page_bio
      - add_inu_page
      : cache page #1 into bio & cache bio in
        io->bio_list
  - f2fs_write_single_data_page
   - f2fs_do_write_data_page
    - f2fs_inplace_write_data
     - f2fs_merge_page_bio
      - add_inu_page
      : cache page #2 into bio which is linked
        in io->bio_list
						write
						- f2fs_write_begin
						: write page #1
						 - f2fs_folio_wait_writeback
						  - f2fs_submit_merged_ipu_write
						   - f2fs_submit_write_bio
						   : submit bio which inclues page #1 and #2

						software IRQ
						- f2fs_write_end_io
						 - fscrypt_free_bounce_page
						 : freed bounced page which belongs to page #2
      - inc_page_count( , WB_DATA_TYPE(data_folio), false)
      : data_folio points to fio->encrypted_page
        the bounced page can be freed before
        accessing it in f2fs_is_cp_guarantee()

It can reproduce w/ below testcase:
Run below script in shell #1:
for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \
-c "pwrite 0 32k" -c "fdatasync"

Run below script in shell #2:
for ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \
-c "pwrite 0 32k" -c "fdatasync"

So, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after
commit page into internal ipu cache.

Fixes: 0b20fcec8651 ("f2fs: cache global IPU bio")
Reported-by: JY <JY.Ho@mediatek.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
[Mark: backport to v5.15.y]
Signed-off-by: Jiucheng Xu <jiucheng.xu@amlogic.com>
---
 fs/f2fs/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 9d1d0c9d924c0cf3831b383f272309c093bcd354..b35886e9b9948ca9889798fac1388e2abdeb003d 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -897,7 +897,7 @@ int f2fs_merge_page_bio(struct f2fs_io_info *fio)
 	if (fio->io_wbc)
 		wbc_account_cgroup_owner(fio->io_wbc, fio->page, PAGE_SIZE);
 
-	inc_page_count(fio->sbi, WB_DATA_TYPE(page));
+	inc_page_count(fio->sbi, WB_DATA_TYPE(fio->page));
 
 	*fio->last_block = fio->new_blkaddr;
 	*fio->bio = bio;

---
base-commit: c86c4726e7f044ab73b493c6f00527aafef640cd
change-id: 20260709-origin-5-15-y-ee6a6262b19e

Best regards,
-- 
Jiucheng Xu <jiucheng.xu@amlogic.com>

Re: [PATCH] f2fs: fix UAF issue in f2fs_merge_page_bio()

[Greg KH]

On Thu, Jul 09, 2026 at 05:35:40PM +0800, Jiucheng Xu via B4 Relay wrote:
> From: Jiucheng Xu <jiucheng.xu@amlogic.com>
> 
> commit edf7e9040fc52c922db947f9c6c36f07377c52ea upstream.
> 
> As JY reported in bugzilla [1],

What kernel(s) is this for?

thanks,

greg k-h

Re: [PATCH] f2fs: fix UAF issue in f2fs_merge_page_bio()

[Jiucheng Xu]

On 7/9/2026 7:04 PM, Greg KH wrote:
> [ EXTERNAL EMAIL ]
> 
> On Thu, Jul 09, 2026 at 05:35:40PM +0800, Jiucheng Xu via B4 Relay wrote:
>> From: Jiucheng Xu <jiucheng.xu@amlogic.com>
>>
>> commit edf7e9040fc52c922db947f9c6c36f07377c52ea upstream.
>>
>> As JY reported in bugzilla [1],
> 
> What kernel(s) is this for?

I'm really sorry, Greg.

This is my first time submitting code to the stable git tree, and I'm 
not quite familiar with the process and rules yet. Please forgive me.

I hope this patch can be applied to the v5.15.y branch. I referred to 
other patches and added a "[Mark: backport to v5.15.y]" in the commit 
message. I'm not sure if this is correct.

Thanks,
Jiucheng

Re: [PATCH] f2fs: fix UAF issue in f2fs_merge_page_bio()

[Greg KH]

On Fri, Jul 10, 2026 at 11:17:19AM +0800, Jiucheng Xu wrote:
> 
> On 7/9/2026 7:04 PM, Greg KH wrote:
> > [ EXTERNAL EMAIL ]
> > 
> > On Thu, Jul 09, 2026 at 05:35:40PM +0800, Jiucheng Xu via B4 Relay wrote:
> > > From: Jiucheng Xu <jiucheng.xu@amlogic.com>
> > > 
> > > commit edf7e9040fc52c922db947f9c6c36f07377c52ea upstream.
> > > 
> > > As JY reported in bugzilla [1],
> > 
> > What kernel(s) is this for?
> 
> I'm really sorry, Greg.
> 
> This is my first time submitting code to the stable git tree, and I'm not
> quite familiar with the process and rules yet. Please forgive me.
> 
> I hope this patch can be applied to the v5.15.y branch. I referred to other
> patches and added a "[Mark: backport to v5.15.y]" in the commit message. I'm
> not sure if this is correct.

It needs to go to the newer kernels first, so that you do not have a
regression when moving to a newer release.  So can you submit backports
for all of the relevant stable kernel trees, including 5.15.y, and we
will be glad to queue them all up then.

thanks,

greg k-h

Re: [PATCH] f2fs: fix UAF issue in f2fs_merge_page_bio()

[Jiucheng Xu]

On 7/21/2026 9:04 PM, Greg KH wrote:
> [ EXTERNAL EMAIL ]
> 
> On Fri, Jul 10, 2026 at 11:17:19AM +0800, Jiucheng Xu wrote:
>>
>> On 7/9/2026 7:04 PM, Greg KH wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On Thu, Jul 09, 2026 at 05:35:40PM +0800, Jiucheng Xu via B4 Relay wrote:
>>>> From: Jiucheng Xu <jiucheng.xu@amlogic.com>
>>>>
>>>> commit edf7e9040fc52c922db947f9c6c36f07377c52ea upstream.
>>>>
>>>> As JY reported in bugzilla [1],
>>>
>>> What kernel(s) is this for?
>>
>> I'm really sorry, Greg.
>>
>> This is my first time submitting code to the stable git tree, and I'm not
>> quite familiar with the process and rules yet. Please forgive me.
>>
>> I hope this patch can be applied to the v5.15.y branch. I referred to other
>> patches and added a "[Mark: backport to v5.15.y]" in the commit message. I'm
>> not sure if this is correct.
> 
> It needs to go to the newer kernels first, so that you do not have a
> regression when moving to a newer release.  So can you submit backports
> for all of the relevant stable kernel trees, including 5.15.y, and we
> will be glad to queue them all up then.
> Hi Greg,

Could I ask for your advice? When submitting patches to different 
branches, how do I mark each commit to specify the target branch it 
applies to?

Thanks,
Jiucheng

Re: [PATCH] f2fs: fix UAF issue in f2fs_merge_page_bio()

[Greg KH]

On Fri, Jul 24, 2026 at 09:46:39AM +0800, Jiucheng Xu wrote:
> 
> 
> On 7/21/2026 9:04 PM, Greg KH wrote:
> > [ EXTERNAL EMAIL ]
> > 
> > On Fri, Jul 10, 2026 at 11:17:19AM +0800, Jiucheng Xu wrote:
> > > 
> > > On 7/9/2026 7:04 PM, Greg KH wrote:
> > > > [ EXTERNAL EMAIL ]
> > > > 
> > > > On Thu, Jul 09, 2026 at 05:35:40PM +0800, Jiucheng Xu via B4 Relay wrote:
> > > > > From: Jiucheng Xu <jiucheng.xu@amlogic.com>
> > > > > 
> > > > > commit edf7e9040fc52c922db947f9c6c36f07377c52ea upstream.
> > > > > 
> > > > > As JY reported in bugzilla [1],
> > > > 
> > > > What kernel(s) is this for?
> > > 
> > > I'm really sorry, Greg.
> > > 
> > > This is my first time submitting code to the stable git tree, and I'm not
> > > quite familiar with the process and rules yet. Please forgive me.
> > > 
> > > I hope this patch can be applied to the v5.15.y branch. I referred to other
> > > patches and added a "[Mark: backport to v5.15.y]" in the commit message. I'm
> > > not sure if this is correct.
> > 
> > It needs to go to the newer kernels first, so that you do not have a
> > regression when moving to a newer release.  So can you submit backports
> > for all of the relevant stable kernel trees, including 5.15.y, and we
> > will be glad to queue them all up then.
> > Hi Greg,
> 
> Could I ask for your advice? When submitting patches to different branches,
> how do I mark each commit to specify the target branch it applies to?

The simplest way, and what I would strongly recommend, is to put the
version in the subject line, like this series did:
	https://lore.kernel.org/r/20260724012519.3833356-1-sashal@kernel.org

Look in the email archives for this list for thousands of other examples
of this happening :)

Also, please read the stable-kernel-rules document which explains that
you do have to list the kernel version a patch is to be applied to.  If
you haven't read that already, there's probably other things you missed
as part of this process also.

thanks,

greg k-h