* [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
@ 2024-01-16 0:27 Sasha Levin
2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 02/12] UBSAN: array-index-out-of-bounds in dtSplitRoot Sasha Levin
` (10 more replies)
0 siblings, 11 replies; 17+ messages in thread
From: Sasha Levin @ 2024-01-16 0:27 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Osama Muhammad, syzbot+39ba34a099ac2e9bd3cb, Dave Kleikamp,
Sasha Levin, shaggy, ghandatmanas, juntong.deng, code,
yogi.kernel, jfs-discussion
From: Osama Muhammad <osmtendev@gmail.com>
[ Upstream commit 9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68 ]
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
</TASK>
================================================================================
Kernel panic - not syncing: UBSAN: panic_on_warn set ...
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
panic+0x30f/0x770 kernel/panic.c:340
check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
ubsan_epilogue lib/ubsan.c:223 [inline]
__ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
txUpdateMap+0x342/0x9e0
txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
kthread+0x2d3/0x370 kernel/kthread.c:388
ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
</TASK>
Kernel Offset: disabled
Rebooting in 86400 seconds..
The issue is caused when the value of lp becomes greater than
CTLTREESIZE which is the max size of stree. Adding a simple check
solves this issue.
Dave:
As the function returns a void, good error handling
would require a more intrusive code reorganization, so I modified
Osama's patch at use WARN_ON_ONCE for lack of a cleaner option.
The patch is tested via syzbot.
Reported-by: syzbot+39ba34a099ac2e9bd3cb@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=39ba34a099ac2e9bd3cb
Signed-off-by: Osama Muhammad <osmtendev@gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/jfs/jfs_dmap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index 2f452b5ee731..b7fc47907d96 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -2948,6 +2948,9 @@ static void dbAdjTree(dmtree_t * tp, int leafno, int newval)
/* is the current value the same as the old value ? if so,
* there is nothing to do.
*/
+ if (WARN_ON_ONCE(lp >= CTLTREESIZE))
+ return;
+
if (tp->dmt_stree[lp] == newval)
return;
--
2.43.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH AUTOSEL 4.19 02/12] UBSAN: array-index-out-of-bounds in dtSplitRoot 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin @ 2024-01-16 0:27 ` Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 03/12] jfs: fix slab-out-of-bounds Read in dtSearch Sasha Levin ` (9 subsequent siblings) 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:27 UTC (permalink / raw) To: linux-kernel, stable Cc: Osama Muhammad, syzbot+d4b1df2e9d4ded6488ec, Dave Kleikamp, Sasha Levin, shaggy, ghandatmanas, jfs-discussion From: Osama Muhammad <osmtendev@gmail.com> [ Upstream commit 27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16 ] Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013 do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was able to produce value less than -1 which cause the error. This patch simply add the change for the values less than 0. The patch is tested via syzbot. Reported-and-tested-by: syzbot+d4b1df2e9d4ded6488ec@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=d4b1df2e9d4ded6488ec Signed-off-by: Osama Muhammad <osmtendev@gmail.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/jfs/jfs_dtree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c index 52bae3f5c914..320c9f42b65b 100644 --- a/fs/jfs/jfs_dtree.c +++ b/fs/jfs/jfs_dtree.c @@ -1983,7 +1983,7 @@ static int dtSplitRoot(tid_t tid, do { f = &rp->slot[fsi]; fsi = f->next; - } while (fsi != -1); + } while (fsi >= 0); f->next = n; } -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 03/12] jfs: fix slab-out-of-bounds Read in dtSearch 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 02/12] UBSAN: array-index-out-of-bounds in dtSplitRoot Sasha Levin @ 2024-01-16 0:27 ` Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 04/12] jfs: fix array-index-out-of-bounds in dbAdjTree Sasha Levin ` (8 subsequent siblings) 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:27 UTC (permalink / raw) To: linux-kernel, stable Cc: Manas Ghandat, kernel test robot, Dan Carpenter, Dave Kleikamp, Sasha Levin, shaggy, osmtendev, jfs-discussion From: Manas Ghandat <ghandatmanas@gmail.com> [ Upstream commit fa5492ee89463a7590a1449358002ff7ef63529f ] Currently while searching for current page in the sorted entry table of the page there is a out of bound access. Added a bound check to fix the error. Dave: Set return code to -EIO Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202310241724.Ed02yUz9-lkp@intel.com/ Signed-off-by: Manas Ghandat <ghandatmanas@gmail.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/jfs/jfs_dtree.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c index 320c9f42b65b..ea2c8f0fe832 100644 --- a/fs/jfs/jfs_dtree.c +++ b/fs/jfs/jfs_dtree.c @@ -646,6 +646,11 @@ int dtSearch(struct inode *ip, struct component_name * key, ino_t * data, for (base = 0, lim = p->header.nextindex; lim; lim >>= 1) { index = base + (lim >> 1); + if (stbl[index] < 0) { + rc = -EIO; + goto out; + } + if (p->header.flag & BT_LEAF) { /* uppercase leaf name to compare */ cmp = -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 04/12] jfs: fix array-index-out-of-bounds in dbAdjTree 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 02/12] UBSAN: array-index-out-of-bounds in dtSplitRoot Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 03/12] jfs: fix slab-out-of-bounds Read in dtSearch Sasha Levin @ 2024-01-16 0:27 ` Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 05/12] jfs: fix uaf in jfs_evict_inode Sasha Levin ` (7 subsequent siblings) 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:27 UTC (permalink / raw) To: linux-kernel, stable Cc: Manas Ghandat, syzbot+39ba34a099ac2e9bd3cb, Dave Kleikamp, Sasha Levin, shaggy, juntong.deng, wonguk.lee1023, yogi.kernel, andrew.kanner, code, osmtendev, jfs-discussion From: Manas Ghandat <ghandatmanas@gmail.com> [ Upstream commit 74ecdda68242b174920fe7c6133a856fb7d8559b ] Currently there is a bound check missing in the dbAdjTree while accessing the dmt_stree. To add the required check added the bool is_ctl which is required to determine the size as suggest in the following commit. https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/ Reported-by: syzbot+39ba34a099ac2e9bd3cb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=39ba34a099ac2e9bd3cb Signed-off-by: Manas Ghandat <ghandatmanas@gmail.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/jfs/jfs_dmap.c | 60 ++++++++++++++++++++++++----------------------- 1 file changed, 31 insertions(+), 29 deletions(-) diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c index b7fc47907d96..893bc59658da 100644 --- a/fs/jfs/jfs_dmap.c +++ b/fs/jfs/jfs_dmap.c @@ -76,10 +76,10 @@ */ static void dbAllocBits(struct bmap * bmp, struct dmap * dp, s64 blkno, int nblocks); -static void dbSplit(dmtree_t * tp, int leafno, int splitsz, int newval); -static int dbBackSplit(dmtree_t * tp, int leafno); -static int dbJoin(dmtree_t * tp, int leafno, int newval); -static void dbAdjTree(dmtree_t * tp, int leafno, int newval); +static void dbSplit(dmtree_t *tp, int leafno, int splitsz, int newval, bool is_ctl); +static int dbBackSplit(dmtree_t *tp, int leafno, bool is_ctl); +static int dbJoin(dmtree_t *tp, int leafno, int newval, bool is_ctl); +static void dbAdjTree(dmtree_t *tp, int leafno, int newval, bool is_ctl); static int dbAdjCtl(struct bmap * bmp, s64 blkno, int newval, int alloc, int level); static int dbAllocAny(struct bmap * bmp, s64 nblocks, int l2nb, s64 * results); @@ -2184,7 +2184,7 @@ static int dbFreeDmap(struct bmap * bmp, struct dmap * dp, s64 blkno, * system. */ if (dp->tree.stree[word] == NOFREE) - dbBackSplit((dmtree_t *) & dp->tree, word); + dbBackSplit((dmtree_t *)&dp->tree, word, false); dbAllocBits(bmp, dp, blkno, nblocks); } @@ -2270,7 +2270,7 @@ static void dbAllocBits(struct bmap * bmp, struct dmap * dp, s64 blkno, * the binary system of the leaves if need be. */ dbSplit(tp, word, BUDMIN, - dbMaxBud((u8 *) & dp->wmap[word])); + dbMaxBud((u8 *)&dp->wmap[word]), false); word += 1; } else { @@ -2310,7 +2310,7 @@ static void dbAllocBits(struct bmap * bmp, struct dmap * dp, s64 blkno, * system of the leaves to reflect the current * allocation (size). */ - dbSplit(tp, word, size, NOFREE); + dbSplit(tp, word, size, NOFREE, false); /* get the number of dmap words handled */ nw = BUDSIZE(size, BUDMIN); @@ -2417,7 +2417,7 @@ static int dbFreeBits(struct bmap * bmp, struct dmap * dp, s64 blkno, /* update the leaf for this dmap word. */ rc = dbJoin(tp, word, - dbMaxBud((u8 *) & dp->wmap[word])); + dbMaxBud((u8 *)&dp->wmap[word]), false); if (rc) return rc; @@ -2450,7 +2450,7 @@ static int dbFreeBits(struct bmap * bmp, struct dmap * dp, s64 blkno, /* update the leaf. */ - rc = dbJoin(tp, word, size); + rc = dbJoin(tp, word, size, false); if (rc) return rc; @@ -2602,14 +2602,14 @@ dbAdjCtl(struct bmap * bmp, s64 blkno, int newval, int alloc, int level) * that it is at the front of a binary buddy system. */ if (oldval == NOFREE) { - rc = dbBackSplit((dmtree_t *) dcp, leafno); + rc = dbBackSplit((dmtree_t *)dcp, leafno, true); if (rc) return rc; oldval = dcp->stree[ti]; } - dbSplit((dmtree_t *) dcp, leafno, dcp->budmin, newval); + dbSplit((dmtree_t *) dcp, leafno, dcp->budmin, newval, true); } else { - rc = dbJoin((dmtree_t *) dcp, leafno, newval); + rc = dbJoin((dmtree_t *) dcp, leafno, newval, true); if (rc) return rc; } @@ -2638,7 +2638,7 @@ dbAdjCtl(struct bmap * bmp, s64 blkno, int newval, int alloc, int level) */ if (alloc) { dbJoin((dmtree_t *) dcp, leafno, - oldval); + oldval, true); } else { /* the dbJoin() above might have * caused a larger binary buddy system @@ -2648,9 +2648,9 @@ dbAdjCtl(struct bmap * bmp, s64 blkno, int newval, int alloc, int level) */ if (dcp->stree[ti] == NOFREE) dbBackSplit((dmtree_t *) - dcp, leafno); + dcp, leafno, true); dbSplit((dmtree_t *) dcp, leafno, - dcp->budmin, oldval); + dcp->budmin, oldval, true); } /* release the buffer and return the error. @@ -2698,7 +2698,7 @@ dbAdjCtl(struct bmap * bmp, s64 blkno, int newval, int alloc, int level) * * serialization: IREAD_LOCK(ipbmap) or IWRITE_LOCK(ipbmap) held on entry/exit; */ -static void dbSplit(dmtree_t * tp, int leafno, int splitsz, int newval) +static void dbSplit(dmtree_t *tp, int leafno, int splitsz, int newval, bool is_ctl) { int budsz; int cursz; @@ -2720,7 +2720,7 @@ static void dbSplit(dmtree_t * tp, int leafno, int splitsz, int newval) while (cursz >= splitsz) { /* update the buddy's leaf with its new value. */ - dbAdjTree(tp, leafno ^ budsz, cursz); + dbAdjTree(tp, leafno ^ budsz, cursz, is_ctl); /* on to the next size and buddy. */ @@ -2732,7 +2732,7 @@ static void dbSplit(dmtree_t * tp, int leafno, int splitsz, int newval) /* adjust the dmap tree to reflect the specified leaf's new * value. */ - dbAdjTree(tp, leafno, newval); + dbAdjTree(tp, leafno, newval, is_ctl); } @@ -2763,7 +2763,7 @@ static void dbSplit(dmtree_t * tp, int leafno, int splitsz, int newval) * * serialization: IREAD_LOCK(ipbmap) or IWRITE_LOCK(ipbmap) held on entry/exit; */ -static int dbBackSplit(dmtree_t * tp, int leafno) +static int dbBackSplit(dmtree_t *tp, int leafno, bool is_ctl) { int budsz, bud, w, bsz, size; int cursz; @@ -2814,7 +2814,7 @@ static int dbBackSplit(dmtree_t * tp, int leafno) * system in two. */ cursz = leaf[bud] - 1; - dbSplit(tp, bud, cursz, cursz); + dbSplit(tp, bud, cursz, cursz, is_ctl); break; } } @@ -2842,7 +2842,7 @@ static int dbBackSplit(dmtree_t * tp, int leafno) * * RETURN VALUES: none */ -static int dbJoin(dmtree_t * tp, int leafno, int newval) +static int dbJoin(dmtree_t *tp, int leafno, int newval, bool is_ctl) { int budsz, buddy; s8 *leaf; @@ -2897,12 +2897,12 @@ static int dbJoin(dmtree_t * tp, int leafno, int newval) if (leafno < buddy) { /* leafno is the left buddy. */ - dbAdjTree(tp, buddy, NOFREE); + dbAdjTree(tp, buddy, NOFREE, is_ctl); } else { /* buddy is the left buddy and becomes * leafno. */ - dbAdjTree(tp, leafno, NOFREE); + dbAdjTree(tp, leafno, NOFREE, is_ctl); leafno = buddy; } @@ -2915,7 +2915,7 @@ static int dbJoin(dmtree_t * tp, int leafno, int newval) /* update the leaf value. */ - dbAdjTree(tp, leafno, newval); + dbAdjTree(tp, leafno, newval, is_ctl); return 0; } @@ -2936,21 +2936,23 @@ static int dbJoin(dmtree_t * tp, int leafno, int newval) * * RETURN VALUES: none */ -static void dbAdjTree(dmtree_t * tp, int leafno, int newval) +static void dbAdjTree(dmtree_t *tp, int leafno, int newval, bool is_ctl) { int lp, pp, k; - int max; + int max, size; + + size = is_ctl ? CTLTREESIZE : TREESIZE; /* pick up the index of the leaf for this leafno. */ lp = leafno + le32_to_cpu(tp->dmt_leafidx); + if (WARN_ON_ONCE(lp >= size || lp < 0)) + return; + /* is the current value the same as the old value ? if so, * there is nothing to do. */ - if (WARN_ON_ONCE(lp >= CTLTREESIZE)) - return; - if (tp->dmt_stree[lp] == newval) return; -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 05/12] jfs: fix uaf in jfs_evict_inode 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin ` (2 preceding siblings ...) 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 04/12] jfs: fix array-index-out-of-bounds in dbAdjTree Sasha Levin @ 2024-01-16 0:27 ` Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 06/12] jfs: fix shift-out-of-bounds in dbJoin Sasha Levin ` (6 subsequent siblings) 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:27 UTC (permalink / raw) To: linux-kernel, stable Cc: Edward Adam Davis, syzbot+01cf2dbcbe2022454388, Dave Kleikamp, Sasha Levin, shaggy, brauner, jack, jfs-discussion From: Edward Adam Davis <eadavis@qq.com> [ Upstream commit e0e1958f4c365e380b17ccb35617345b31ef7bf3 ] When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. Reported-and-tested-by: syzbot+01cf2dbcbe2022454388@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/jfs/jfs_mount.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/jfs/jfs_mount.c b/fs/jfs/jfs_mount.c index f1a705d15904..97d91c1686b8 100644 --- a/fs/jfs/jfs_mount.c +++ b/fs/jfs/jfs_mount.c @@ -184,15 +184,15 @@ int jfs_mount(struct super_block *sb) } jfs_info("jfs_mount: ipimap:0x%p", ipimap); - /* map further access of per fileset inodes by the fileset inode */ - sbi->ipimap = ipimap; - /* initialize fileset inode allocation map */ if ((rc = diMount(ipimap))) { jfs_err("jfs_mount: diMount failed w/rc = %d", rc); goto err_ipimap; } + /* map further access of per fileset inodes by the fileset inode */ + sbi->ipimap = ipimap; + return rc; /* -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 06/12] jfs: fix shift-out-of-bounds in dbJoin 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin ` (3 preceding siblings ...) 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 05/12] jfs: fix uaf in jfs_evict_inode Sasha Levin @ 2024-01-16 0:27 ` Sasha Levin 2024-01-16 0:28 ` Sasha Levin ` (5 subsequent siblings) 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:27 UTC (permalink / raw) To: linux-kernel, stable Cc: Manas Ghandat, syzbot+411debe54d318eaed386, Dave Kleikamp, Sasha Levin, shaggy, juntong.deng, osmtendev, yogi.kernel, wonguk.lee1023, code, jfs-discussion From: Manas Ghandat <ghandatmanas@gmail.com> [ Upstream commit cca974daeb6c43ea971f8ceff5a7080d7d49ee30 ] Currently while joining the leaf in a buddy system there is shift out of bound error in calculation of BUDSIZE. Added the required check to the BUDSIZE and fixed the documentation as well. Reported-by: syzbot+411debe54d318eaed386@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=411debe54d318eaed386 Signed-off-by: Manas Ghandat <ghandatmanas@gmail.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/jfs/jfs_dmap.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c index 893bc59658da..0cfdd52021f1 100644 --- a/fs/jfs/jfs_dmap.c +++ b/fs/jfs/jfs_dmap.c @@ -2840,7 +2840,9 @@ static int dbBackSplit(dmtree_t *tp, int leafno, bool is_ctl) * leafno - the number of the leaf to be updated. * newval - the new value for the leaf. * - * RETURN VALUES: none + * RETURN VALUES: + * 0 - success + * -EIO - i/o error */ static int dbJoin(dmtree_t *tp, int leafno, int newval, bool is_ctl) { @@ -2867,6 +2869,10 @@ static int dbJoin(dmtree_t *tp, int leafno, int newval, bool is_ctl) * get the buddy size (number of words covered) of * the new value. */ + + if ((newval - tp->dmt_budmin) > BUDMIN) + return -EIO; + budsz = BUDSIZE(newval, tp->dmt_budmin); /* try to join. -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 07/12] pstore/ram: Fix crash when setting number of cpus to an odd number 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin @ 2024-01-16 0:28 ` Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 03/12] jfs: fix slab-out-of-bounds Read in dtSearch Sasha Levin ` (9 subsequent siblings) 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:28 UTC (permalink / raw) To: linux-kernel, stable Cc: Weichen Chen, Matthias Brugger, Guilherme G. Piccoli, Kees Cook, Sasha Levin, angelogioacchino.delregno, linux-hardening, linux-arm-kernel, linux-mediatek From: Weichen Chen <weichen.chen@mediatek.com> [ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ] When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug. Signed-off-by: Weichen Chen <weichen.chen@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Tested-by: "Guilherme G. Piccoli" <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20230224023632.6840-1-weichen.chen@mediatek.com Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/pstore/ram.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index 33294dee7d7f..0050aa56b0fa 100644 --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -590,6 +590,7 @@ static int ramoops_init_przs(const char *name, } zone_sz = mem_sz / *cnt; + zone_sz = ALIGN_DOWN(zone_sz, 2); if (!zone_sz) { dev_err(dev, "%s zone size == 0\n", name); goto fail; -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 07/12] pstore/ram: Fix crash when setting number of cpus to an odd number @ 2024-01-16 0:28 ` Sasha Levin 0 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:28 UTC (permalink / raw) To: linux-kernel, stable Cc: Weichen Chen, Matthias Brugger, Guilherme G. Piccoli, Kees Cook, Sasha Levin, angelogioacchino.delregno, linux-hardening, linux-arm-kernel, linux-mediatek From: Weichen Chen <weichen.chen@mediatek.com> [ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ] When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug. Signed-off-by: Weichen Chen <weichen.chen@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Tested-by: "Guilherme G. Piccoli" <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20230224023632.6840-1-weichen.chen@mediatek.com Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/pstore/ram.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c index 33294dee7d7f..0050aa56b0fa 100644 --- a/fs/pstore/ram.c +++ b/fs/pstore/ram.c @@ -590,6 +590,7 @@ static int ramoops_init_przs(const char *name, } zone_sz = mem_sz / *cnt; + zone_sz = ALIGN_DOWN(zone_sz, 2); if (!zone_sz) { dev_err(dev, "%s zone size == 0\n", name); goto fail; -- 2.43.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 08/12] crypto: stm32/crc32 - fix parsing list of devices 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin @ 2024-01-16 0:28 ` Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 03/12] jfs: fix slab-out-of-bounds Read in dtSearch Sasha Levin ` (9 subsequent siblings) 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:28 UTC (permalink / raw) To: linux-kernel, stable Cc: Thomas Bourgoin, kernel test robot, Dan Carpenter, Herbert Xu, Sasha Levin, davem, mcoquelin.stm32, alexandre.torgue, linux-crypto, linux-stm32, linux-arm-kernel From: Thomas Bourgoin <thomas.bourgoin@foss.st.com> [ Upstream commit 0eaef675b94c746900dcea7f6c41b9a103ed5d53 ] smatch warnings: drivers/crypto/stm32/stm32-crc32.c:108 stm32_crc_get_next_crc() warn: can 'crc' even be NULL? Use list_first_entry_or_null instead of list_first_entry to retrieve the first device registered. The function list_first_entry always return a non NULL pointer even if the list is empty. Hence checking if the pointer returned is NULL does not tell if the list is empty or not. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/ Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/ Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/stm32/stm32_crc32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/stm32/stm32_crc32.c b/drivers/crypto/stm32/stm32_crc32.c index de645bf84980..04adc84d677c 100644 --- a/drivers/crypto/stm32/stm32_crc32.c +++ b/drivers/crypto/stm32/stm32_crc32.c @@ -98,7 +98,7 @@ static struct stm32_crc *stm32_crc_get_next_crc(void) struct stm32_crc *crc; spin_lock_bh(&crc_list.lock); - crc = list_first_entry(&crc_list.dev_list, struct stm32_crc, list); + crc = list_first_entry_or_null(&crc_list.dev_list, struct stm32_crc, list); if (crc) list_move_tail(&crc->list, &crc_list.dev_list); spin_unlock_bh(&crc_list.lock); -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 08/12] crypto: stm32/crc32 - fix parsing list of devices @ 2024-01-16 0:28 ` Sasha Levin 0 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:28 UTC (permalink / raw) To: linux-kernel, stable Cc: Thomas Bourgoin, kernel test robot, Dan Carpenter, Herbert Xu, Sasha Levin, davem, mcoquelin.stm32, alexandre.torgue, linux-crypto, linux-stm32, linux-arm-kernel From: Thomas Bourgoin <thomas.bourgoin@foss.st.com> [ Upstream commit 0eaef675b94c746900dcea7f6c41b9a103ed5d53 ] smatch warnings: drivers/crypto/stm32/stm32-crc32.c:108 stm32_crc_get_next_crc() warn: can 'crc' even be NULL? Use list_first_entry_or_null instead of list_first_entry to retrieve the first device registered. The function list_first_entry always return a non NULL pointer even if the list is empty. Hence checking if the pointer returned is NULL does not tell if the list is empty or not. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/ Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/ Signed-off-by: Thomas Bourgoin <thomas.bourgoin@foss.st.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/crypto/stm32/stm32_crc32.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/stm32/stm32_crc32.c b/drivers/crypto/stm32/stm32_crc32.c index de645bf84980..04adc84d677c 100644 --- a/drivers/crypto/stm32/stm32_crc32.c +++ b/drivers/crypto/stm32/stm32_crc32.c @@ -98,7 +98,7 @@ static struct stm32_crc *stm32_crc_get_next_crc(void) struct stm32_crc *crc; spin_lock_bh(&crc_list.lock); - crc = list_first_entry(&crc_list.dev_list, struct stm32_crc, list); + crc = list_first_entry_or_null(&crc_list.dev_list, struct stm32_crc, list); if (crc) list_move_tail(&crc->list, &crc_list.dev_list); spin_unlock_bh(&crc_list.lock); -- 2.43.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 09/12] afs: fix the usage of read_seqbegin_or_lock() in afs_find_server*() 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin ` (6 preceding siblings ...) 2024-01-16 0:28 ` Sasha Levin @ 2024-01-16 0:28 ` Sasha Levin 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 10/12] rxrpc_find_service_conn_rcu: fix the usage of read_seqbegin_or_lock() Sasha Levin ` (2 subsequent siblings) 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:28 UTC (permalink / raw) To: linux-kernel, stable Cc: Oleg Nesterov, David Howells, Marc Dionne, linux-afs, Sasha Levin From: Oleg Nesterov <oleg@redhat.com> [ Upstream commit 1702e0654ca9a7bcd7c7619c8a5004db58945b71 ] David Howells says: (5) afs_find_server(). There could be a lot of servers in the list and each server can have multiple addresses, so I think this would be better with an exclusive second pass. The server list isn't likely to change all that often, but when it does change, there's a good chance several servers are going to be added/removed one after the other. Further, this is only going to be used for incoming cache management/callback requests from the server, which hopefully aren't going to happen too often - but it is remotely drivable. (6) afs_find_server_by_uuid(). Similarly to (5), there could be a lot of servers to search through, but they are in a tree not a flat list, so it should be faster to process. Again, it's not likely to change that often and, again, when it does change it's likely to involve multiple changes. This can be driven remotely by an incoming cache management request but is mostly going to be driven by setting up or reconfiguring a volume's server list - something that also isn't likely to happen often. Make the "seq" counter odd on the 2nd pass, otherwise read_seqbegin_or_lock() never takes the lock. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/20231130115614.GA21581@redhat.com/ Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/afs/server.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/afs/server.c b/fs/afs/server.c index 2c7f6211c360..b12caa1acf53 100644 --- a/fs/afs/server.c +++ b/fs/afs/server.c @@ -37,7 +37,7 @@ struct afs_server *afs_find_server(struct afs_net *net, const struct afs_addr_list *alist; struct afs_server *server = NULL; unsigned int i; - int seq = 0, diff; + int seq = 1, diff; rcu_read_lock(); @@ -45,6 +45,7 @@ struct afs_server *afs_find_server(struct afs_net *net, if (server) afs_put_server(net, server); server = NULL; + seq++; /* 2 on the 1st/lockless path, otherwise odd */ read_seqbegin_or_lock(&net->fs_addr_lock, &seq); if (srx->transport.family == AF_INET6) { @@ -100,7 +101,7 @@ struct afs_server *afs_find_server_by_uuid(struct afs_net *net, const uuid_t *uu { struct afs_server *server = NULL; struct rb_node *p; - int diff, seq = 0; + int diff, seq = 1; _enter("%pU", uuid); @@ -112,7 +113,7 @@ struct afs_server *afs_find_server_by_uuid(struct afs_net *net, const uuid_t *uu if (server) afs_put_server(net, server); server = NULL; - + seq++; /* 2 on the 1st/lockless path, otherwise odd */ read_seqbegin_or_lock(&net->fs_lock, &seq); p = net->fs_servers.rb_node; -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 10/12] rxrpc_find_service_conn_rcu: fix the usage of read_seqbegin_or_lock() 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin ` (7 preceding siblings ...) 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 09/12] afs: fix the usage of read_seqbegin_or_lock() in afs_find_server*() Sasha Levin @ 2024-01-16 0:28 ` Sasha Levin 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super Sasha Levin 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 12/12] jfs: fix array-index-out-of-bounds in diNewExt Sasha Levin 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:28 UTC (permalink / raw) To: linux-kernel, stable Cc: Oleg Nesterov, David Howells, Marc Dionne, linux-afs, Sasha Levin, davem, edumazet, kuba, pabeni, netdev From: Oleg Nesterov <oleg@redhat.com> [ Upstream commit bad1a11c0f061aa073bab785389fe04f19ba02e1 ] rxrpc_find_service_conn_rcu() should make the "seq" counter odd on the second pass, otherwise read_seqbegin_or_lock() never takes the lock. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/20231117164846.GA10410@redhat.com/ Signed-off-by: Sasha Levin <sashal@kernel.org> --- net/rxrpc/conn_service.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/rxrpc/conn_service.c b/net/rxrpc/conn_service.c index 6da7c4bf15e8..4b1564824aed 100644 --- a/net/rxrpc/conn_service.c +++ b/net/rxrpc/conn_service.c @@ -29,7 +29,7 @@ struct rxrpc_connection *rxrpc_find_service_conn_rcu(struct rxrpc_peer *peer, struct rxrpc_conn_proto k; struct rxrpc_skb_priv *sp = rxrpc_skb(skb); struct rb_node *p; - unsigned int seq = 0; + unsigned int seq = 1; k.epoch = sp->hdr.epoch; k.cid = sp->hdr.cid & RXRPC_CIDMASK; @@ -39,6 +39,7 @@ struct rxrpc_connection *rxrpc_find_service_conn_rcu(struct rxrpc_peer *peer, * under just the RCU read lock, so we have to check for * changes. */ + seq++; /* 2 on the 1st/lockless path, otherwise odd */ read_seqbegin_or_lock(&peer->service_conn_lock, &seq); p = rcu_dereference_raw(peer->service_conns.rb_node); -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin ` (8 preceding siblings ...) 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 10/12] rxrpc_find_service_conn_rcu: fix the usage of read_seqbegin_or_lock() Sasha Levin @ 2024-01-16 0:28 ` Sasha Levin 2024-01-16 20:46 ` Pavel Machek 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 12/12] jfs: fix array-index-out-of-bounds in diNewExt Sasha Levin 10 siblings, 1 reply; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:28 UTC (permalink / raw) To: linux-kernel, stable; +Cc: Andreas Gruenbacher, Sasha Levin, gfs2 From: Andreas Gruenbacher <agruenba@redhat.com> [ Upstream commit 4e58543e7da4859c4ba61d15493e3522b6ad71fd ] It turns out that the .freeze_super and .thaw_super operations require the filesystem to manage the superblock refcount itself. We are using the freeze_super() and thaw_super() helpers to mostly take care of that for us, but this means that the superblock may no longer be around by when thaw_super() returns, and gfs2_thaw_super() will then access freed memory. Take an extra superblock reference in gfs2_thaw_super() to fix that. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/gfs2/super.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c index 29157f7d9663..2993598d18a4 100644 --- a/fs/gfs2/super.c +++ b/fs/gfs2/super.c @@ -1013,6 +1013,7 @@ static int gfs2_freeze(struct super_block *sb) goto out; } + atomic_inc(&sb->s_active); for (;;) { error = gfs2_lock_fs_check_clean(sdp, &sdp->sd_freeze_gh); if (!error) @@ -1034,6 +1035,7 @@ static int gfs2_freeze(struct super_block *sb) error = 0; out: mutex_unlock(&sdp->sd_freeze_mutex); + deactivate_super(sb); return error; } -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super Sasha Levin @ 2024-01-16 20:46 ` Pavel Machek 2024-01-18 11:50 ` Andreas Gruenbacher 0 siblings, 1 reply; 17+ messages in thread From: Pavel Machek @ 2024-01-16 20:46 UTC (permalink / raw) To: Sasha Levin; +Cc: linux-kernel, stable, Andreas Gruenbacher, gfs2 [-- Attachment #1: Type: text/plain, Size: 1371 bytes --] Hi! > From: Andreas Gruenbacher <agruenba@redhat.com> > > [ Upstream commit 4e58543e7da4859c4ba61d15493e3522b6ad71fd ] > > It turns out that the .freeze_super and .thaw_super operations require > the filesystem to manage the superblock refcount itself. We are using > the freeze_super() and thaw_super() helpers to mostly take care of that > for us, but this means that the superblock may no longer be around by > when thaw_super() returns, and gfs2_thaw_super() will then access freed > memory. Take an extra superblock reference in gfs2_thaw_super() to fix > that. Patch was broken during backport. > +++ b/fs/gfs2/super.c > @@ -1013,6 +1013,7 @@ static int gfs2_freeze(struct super_block *sb) > goto out; > } > > + atomic_inc(&sb->s_active); > for (;;) { > error = gfs2_lock_fs_check_clean(sdp, &sdp->sd_freeze_gh); > if (!error) > @@ -1034,6 +1035,7 @@ static int gfs2_freeze(struct super_block *sb) > error = 0; > out: > mutex_unlock(&sdp->sd_freeze_mutex); > + deactivate_super(sb); > return error; > } Notice the goto out? That now jumps around the atomic_inc, but we still do decrease. This will break 4.19, please fix or drop. BR, Pavel -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super 2024-01-16 20:46 ` Pavel Machek @ 2024-01-18 11:50 ` Andreas Gruenbacher 2024-01-30 21:16 ` Sasha Levin 0 siblings, 1 reply; 17+ messages in thread From: Andreas Gruenbacher @ 2024-01-18 11:50 UTC (permalink / raw) To: Sasha Levin, Pavel Machek; +Cc: linux-kernel, stable, gfs2 On Tue, Jan 16, 2024 at 9:53 PM Pavel Machek <pavel@denx.de> wrote: > Hi! > > > From: Andreas Gruenbacher <agruenba@redhat.com> > > > > [ Upstream commit 4e58543e7da4859c4ba61d15493e3522b6ad71fd ] > > > > It turns out that the .freeze_super and .thaw_super operations require > > the filesystem to manage the superblock refcount itself. We are using > > the freeze_super() and thaw_super() helpers to mostly take care of that > > for us, but this means that the superblock may no longer be around by > > when thaw_super() returns, and gfs2_thaw_super() will then access freed > > memory. Take an extra superblock reference in gfs2_thaw_super() to fix > > that. > > Patch was broken during backport. > > > +++ b/fs/gfs2/super.c > > @@ -1013,6 +1013,7 @@ static int gfs2_freeze(struct super_block *sb) > > goto out; > > } > > > > + atomic_inc(&sb->s_active); > > for (;;) { > > error = gfs2_lock_fs_check_clean(sdp, &sdp->sd_freeze_gh); > > if (!error) > > @@ -1034,6 +1035,7 @@ static int gfs2_freeze(struct super_block *sb) > > error = 0; > > out: > > mutex_unlock(&sdp->sd_freeze_mutex); > > + deactivate_super(sb); > > return error; > > } > > Notice the goto out? That now jumps around the atomic_inc, but we > still do decrease. This will break 4.19, please fix or drop. Thanks, Pavel. Sasha, you don't want that fix without "gfs2: Rework freeze / thaw logic" and the follow-up fixes, and backporting that probably isn't going to be worth it. Thanks, Andreas ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super 2024-01-18 11:50 ` Andreas Gruenbacher @ 2024-01-30 21:16 ` Sasha Levin 0 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-30 21:16 UTC (permalink / raw) To: Andreas Gruenbacher; +Cc: Pavel Machek, linux-kernel, stable, gfs2 On Thu, Jan 18, 2024 at 12:50:37PM +0100, Andreas Gruenbacher wrote: >On Tue, Jan 16, 2024 at 9:53 PM Pavel Machek <pavel@denx.de> wrote: >> Hi! >> >> > From: Andreas Gruenbacher <agruenba@redhat.com> >> > >> > [ Upstream commit 4e58543e7da4859c4ba61d15493e3522b6ad71fd ] >> > >> > It turns out that the .freeze_super and .thaw_super operations require >> > the filesystem to manage the superblock refcount itself. We are using >> > the freeze_super() and thaw_super() helpers to mostly take care of that >> > for us, but this means that the superblock may no longer be around by >> > when thaw_super() returns, and gfs2_thaw_super() will then access freed >> > memory. Take an extra superblock reference in gfs2_thaw_super() to fix >> > that. >> >> Patch was broken during backport. >> >> > +++ b/fs/gfs2/super.c >> > @@ -1013,6 +1013,7 @@ static int gfs2_freeze(struct super_block *sb) >> > goto out; >> > } >> > >> > + atomic_inc(&sb->s_active); >> > for (;;) { >> > error = gfs2_lock_fs_check_clean(sdp, &sdp->sd_freeze_gh); >> > if (!error) >> > @@ -1034,6 +1035,7 @@ static int gfs2_freeze(struct super_block *sb) >> > error = 0; >> > out: >> > mutex_unlock(&sdp->sd_freeze_mutex); >> > + deactivate_super(sb); >> > return error; >> > } >> >> Notice the goto out? That now jumps around the atomic_inc, but we >> still do decrease. This will break 4.19, please fix or drop. > >Thanks, Pavel. > >Sasha, you don't want that fix without "gfs2: Rework freeze / thaw >logic" and the follow-up fixes, and backporting that probably isn't >going to be worth it. I'll drop it, thanks! -- Thanks, Sasha ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH AUTOSEL 4.19 12/12] jfs: fix array-index-out-of-bounds in diNewExt 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin ` (9 preceding siblings ...) 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super Sasha Levin @ 2024-01-16 0:28 ` Sasha Levin 10 siblings, 0 replies; 17+ messages in thread From: Sasha Levin @ 2024-01-16 0:28 UTC (permalink / raw) To: linux-kernel, stable Cc: Edward Adam Davis, syzbot+553d90297e6d2f50dbc7, Dave Kleikamp, Sasha Levin, shaggy, brauner, jlayton, liushixin2, jfs-discussion, ghandatmanas From: Edward Adam Davis <eadavis@qq.com> [ Upstream commit 49f9637aafa6e63ba686c13cb8549bf5e6920402 ] [Syz report] UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2 index -878706688 is out of range for type 'struct iagctl[128]' CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360 diAllocExt fs/jfs/jfs_imap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129 __do_sys_mkdir fs/namei.c:4149 [inline] __se_sys_mkdir fs/namei.c:4147 [inline] __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140 RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [Analysis] When the agstart is too large, it can cause agno overflow. [Fix] After obtaining agno, if the value is invalid, exit the subsequent process. Reported-and-tested-by: syzbot+553d90297e6d2f50dbc7@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis@qq.com> Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next report by kernel test robot (Dan Carpenter). Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> --- fs/jfs/jfs_imap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/jfs/jfs_imap.c b/fs/jfs/jfs_imap.c index b45cc109e506..00800c8c6f07 100644 --- a/fs/jfs/jfs_imap.c +++ b/fs/jfs/jfs_imap.c @@ -2194,6 +2194,9 @@ static int diNewExt(struct inomap * imap, struct iag * iagp, int extno) /* get the ag and iag numbers for this iag. */ agno = BLKTOAG(le64_to_cpu(iagp->agstart), sbi); + if (agno >= MAXAG || agno < 0) + return -EIO; + iagno = le32_to_cpu(iagp->iagnum); /* check if this is the last free extent within the -- 2.43.0 ^ permalink raw reply related [flat|nested] 17+ messages in thread
end of thread, other threads:[~2024-01-30 21:16 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-01-16 0:27 [PATCH AUTOSEL 4.19 01/12] FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 02/12] UBSAN: array-index-out-of-bounds in dtSplitRoot Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 03/12] jfs: fix slab-out-of-bounds Read in dtSearch Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 04/12] jfs: fix array-index-out-of-bounds in dbAdjTree Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 05/12] jfs: fix uaf in jfs_evict_inode Sasha Levin 2024-01-16 0:27 ` [PATCH AUTOSEL 4.19 06/12] jfs: fix shift-out-of-bounds in dbJoin Sasha Levin 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 07/12] pstore/ram: Fix crash when setting number of cpus to an odd number Sasha Levin 2024-01-16 0:28 ` Sasha Levin 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 08/12] crypto: stm32/crc32 - fix parsing list of devices Sasha Levin 2024-01-16 0:28 ` Sasha Levin 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 09/12] afs: fix the usage of read_seqbegin_or_lock() in afs_find_server*() Sasha Levin 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 10/12] rxrpc_find_service_conn_rcu: fix the usage of read_seqbegin_or_lock() Sasha Levin 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 11/12] gfs2: Refcounting fix in gfs2_thaw_super Sasha Levin 2024-01-16 20:46 ` Pavel Machek 2024-01-18 11:50 ` Andreas Gruenbacher 2024-01-30 21:16 ` Sasha Levin 2024-01-16 0:28 ` [PATCH AUTOSEL 4.19 12/12] jfs: fix array-index-out-of-bounds in diNewExt Sasha Levin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.