Re: [PATCH 5.10.y] f2fs: fix to seek incorrect data offset in inline data file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020/12/22 16:37, Greg KH wrote:
On Tue, Dec 22, 2020 at 09:36:35AM +0100, Greg KH wrote:
On Tue, Dec 22, 2020 at 09:16:34AM +0800, Chao Yu wrote:
As kitestramuort reported:

F2FS-fs (nvme0n1p4): access invalid blkaddr:1598541474
[   25.725898] ------------[ cut here ]------------
[   25.725903] WARNING: CPU: 6 PID: 2018 at f2fs_is_valid_blkaddr+0x23a/0x250
[   25.725923] Call Trace:
[   25.725927]  ? f2fs_llseek+0x204/0x620
[   25.725929]  ? ovl_copy_up_data+0x14f/0x200
[   25.725931]  ? ovl_copy_up_inode+0x174/0x1e0
[   25.725933]  ? ovl_copy_up_one+0xa22/0xdf0
[   25.725936]  ? ovl_copy_up_flags+0xa6/0xf0
[   25.725938]  ? ovl_aio_cleanup_handler+0xd0/0xd0
[   25.725939]  ? ovl_maybe_copy_up+0x86/0xa0
[   25.725941]  ? ovl_open+0x22/0x80
[   25.725943]  ? do_dentry_open+0x136/0x350
[   25.725945]  ? path_openat+0xb7e/0xf40
[   25.725947]  ? __check_sticky+0x40/0x40
[   25.725948]  ? do_filp_open+0x70/0x100
[   25.725950]  ? __check_sticky+0x40/0x40
[   25.725951]  ? __check_sticky+0x40/0x40
[   25.725953]  ? __x64_sys_openat+0x1db/0x2c0
[   25.725955]  ? do_syscall_64+0x2d/0x40
[   25.725957]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9

llseek() reports invalid block address access, the root cause is if
file has inline data, f2fs_seek_block() will access inline data regard
as block address index in inode block, which should be wrong, fix it.

Fixes: 788e96d1d3994 ("f2fs: code cleanup by removing unnecessary check")
Fixes: 267378d4de69 ("f2fs: introduce f2fs_seek_block to support SEEK_{DATA, HOLE} in llseek")
Cc: stable <stable@xxxxxxxxxxxxxxx> # 3.16+
Reported-by: kitestramuort <kitestramuort@xxxxxxxxxxxxx>
Signed-off-by: Chao Yu <yuchao0@xxxxxxxxxx>
Signed-off-by: Jaegeuk Kim <jaegeuk@xxxxxxxxxx>
---

This will cause boot failure in f2fs image, which was reported in gentoo
community, I'd like to fix them in stable kernel 5.10 first as request in
bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=210825

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
     https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

I forgot to add "Cc: stable ..." tag in original patch before this patch been
merged in Linus' tree, so I think "Option 2" should be right way to backport this
patch, however, I forgot to tag commit id of this patch.


</formletter>

Specifically, what is the git commit id of this patch in Linus's tree?

Will add git commit id, and resend the patch.

Thanks,


thanks,

greg k-h
.




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux