commit 1dd73601a1cba37a0ed5f89a8662c90191df5873 upstream.
As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly.
Let's fall back to the generic path to deal with such unusual i_size.
[1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com
Reported-by: syzbot+f966c13b1b4fc0403b19@syzkaller.appspotmail.com Fixes: 431339ba9042 ("staging: erofs: add inode operations") Reviewed-by: Yue Hu huyue2@coolpad.com Link: https://lore.kernel.org/r/20220909023948.28925-1-hsiangkao@linux.alibaba.com Signed-off-by: Gao Xiang hsiangkao@linux.alibaba.com --- fs/erofs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/erofs/inode.c b/fs/erofs/inode.c index 0a94a52a119f..93a4ed665d93 100644 --- a/fs/erofs/inode.c +++ b/fs/erofs/inode.c @@ -202,7 +202,7 @@ static int erofs_fill_symlink(struct inode *inode, void *data,
/* if it cannot be handled with fast symlink scheme */ if (vi->datalayout != EROFS_INODE_FLAT_INLINE || - inode->i_size >= PAGE_SIZE) { + inode->i_size >= PAGE_SIZE || inode->i_size < 0) { inode->i_op = &erofs_symlink_iops; return 0; }
commit 9ed50b8231e37b1ae863f5dec8153b98d9f389b4 upstream.
Fast symlink can be used if the on-disk symlink data is stored in the same block as the on-disk inode, so we don’t need to trigger another I/O for symlink data. However, currently fs correction could be reported _incorrectly_ if inode xattrs are too large.
In fact, these should be valid images although they cannot be handled as fast symlinks.
Many thanks to Colin for reporting this!
Reported-by: Colin Walters walters@verbum.org Reported-by: https://honggfuzz.dev/ Link: https://lore.kernel.org/r/bb2dd430-7de0-47da-ae5b-82ab2dd4d945@app.fastmail.... Fixes: 431339ba9042 ("staging: erofs: add inode operations") [ Note that it's a runtime misbehavior instead of a security issue. ] Link: https://lore.kernel.org/r/20240909031911.1174718-1-hsiangkao@linux.alibaba.c... [ Gao Xiang: fix 5.10.y build warning due to `check_add_overflow`. ] Signed-off-by: Gao Xiang hsiangkao@linux.alibaba.com --- fs/erofs/inode.c | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/fs/erofs/inode.c b/fs/erofs/inode.c index 93a4ed665d93..60b4c4326dae 100644 --- a/fs/erofs/inode.c +++ b/fs/erofs/inode.c @@ -198,11 +198,14 @@ static int erofs_fill_symlink(struct inode *inode, void *data, unsigned int m_pofs) { struct erofs_inode *vi = EROFS_I(inode); + loff_t off; char *lnk;
- /* if it cannot be handled with fast symlink scheme */ - if (vi->datalayout != EROFS_INODE_FLAT_INLINE || - inode->i_size >= PAGE_SIZE || inode->i_size < 0) { + m_pofs += vi->xattr_isize; + /* check if it cannot be handled with fast symlink scheme */ + if (vi->datalayout != EROFS_INODE_FLAT_INLINE || inode->i_size < 0 || + check_add_overflow((loff_t)m_pofs, inode->i_size, &off) || + off > i_blocksize(inode)) { inode->i_op = &erofs_symlink_iops; return 0; } @@ -211,17 +214,6 @@ static int erofs_fill_symlink(struct inode *inode, void *data, if (!lnk) return -ENOMEM;
- m_pofs += vi->xattr_isize; - /* inline symlink data shouldn't cross page boundary as well */ - if (m_pofs + inode->i_size > PAGE_SIZE) { - kfree(lnk); - erofs_err(inode->i_sb, - "inline data cross block boundary @ nid %llu", - vi->nid); - DBG_BUGON(1); - return -EFSCORRUPTED; - } - memcpy(lnk, data + m_pofs, inode->i_size); lnk[inode->i_size] = '\0';
[ Sasha's backport helper bot ]
Hi,
The upstream commit SHA1 provided is correct: 9ed50b8231e37b1ae863f5dec8153b98d9f389b4
Status in newer kernel trees: 6.12.y | Present (exact SHA1) 6.6.y | Present (different SHA1: 0c9b52bfee0e) 6.1.y | Present (different SHA1: ec134c1855c8) 5.15.y | Not found 5.10.y | Not found
Note: The patch differs from the upstream commit: --- Failed to apply patch cleanly, falling back to interdiff...
interdiff error output: /home/sasha/stable/mailbot.sh: line 525: interdiff: command not found interdiff failed, falling back to standard diff... ---
Results of testing on various branches:
| Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | stable/linux-5.10.y | Success | Success |
[ Sasha's backport helper bot ]
Hi,
The upstream commit SHA1 provided is correct: 1dd73601a1cba37a0ed5f89a8662c90191df5873
Status in newer kernel trees: 6.12.y | Present (exact SHA1) 6.6.y | Present (exact SHA1) 6.1.y | Present (exact SHA1) 5.15.y | Present (different SHA1: acc2f40b980c) 5.10.y | Not found
Note: The patch differs from the upstream commit: --- 1: 1dd73601a1cb < -: ------------ erofs: fix order >= MAX_ORDER warning due to crafted negative i_size -: ------------ > 1: 025315542f31 erofs: fix order >= MAX_ORDER warning due to crafted negative i_size ---
Results of testing on various branches:
| Branch | Patch Apply | Build Test | |---------------------------|-------------|------------| | stable/linux-5.10.y | Success | Success |
linux-stable-mirror@lists.linaro.org
-
Gao Xiang -
Sasha Levin