--- /dev/null
+From 0c0b4a49d3e7f49690a6827a41faeffad5df7e21 Mon Sep 17 00:00:00 2001
+From: Baokun Li <libaokun1@huawei.com>
+Date: Sat, 4 May 2024 15:55:25 +0800
+Subject: ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
+
+From: Baokun Li <libaokun1@huawei.com>
+
+commit 0c0b4a49d3e7f49690a6827a41faeffad5df7e21 upstream.
+
+Syzbot reports a warning as follows:
+
+============================================
+WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290
+Modules linked in:
+CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7
+RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419
+Call Trace:
+ <TASK>
+ ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375
+ generic_shutdown_super+0x136/0x2d0 fs/super.c:641
+ kill_block_super+0x44/0x90 fs/super.c:1675
+ ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327
+[...]
+============================================
+
+This is because when finding an entry in ext4_xattr_block_cache_find(), if
+ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown
+in the __entry_find(), won't be put away, and eventually trigger the above
+issue in mb_cache_destroy() due to reference count leakage.
+
+So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.
+
+Reported-by: syzbot+dd43bd0f7474512edc47@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=dd43bd0f7474512edc47
+Fixes: fb265c9cb49e ("ext4: add ext4_sb_bread() to disambiguate ENOMEM cases")
+Cc: stable@kernel.org
+Signed-off-by: Baokun Li <libaokun1@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20240504075526.2254349-2-libaokun@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/xattr.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/ext4/xattr.c
++++ b/fs/ext4/xattr.c
+@@ -3079,8 +3079,10 @@ ext4_xattr_block_cache_find(struct inode
+
+ bh = ext4_sb_bread(inode->i_sb, ce->e_value, REQ_PRIO);
+ if (IS_ERR(bh)) {
+- if (PTR_ERR(bh) == -ENOMEM)
++ if (PTR_ERR(bh) == -ENOMEM) {
++ mb_cache_entry_put(ea_block_cache, ce);
+ return NULL;
++ }
+ bh = NULL;
+ EXT4_ERROR_INODE(inode, "block %lu read error",
+ (unsigned long)ce->e_value);
--- /dev/null
+From d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9 Mon Sep 17 00:00:00 2001
+From: Harald Freudenberger <freude@linux.ibm.com>
+Date: Mon, 13 May 2024 14:49:13 +0200
+Subject: s390/ap: Fix crash in AP internal function modify_bitmap()
+
+From: Harald Freudenberger <freude@linux.ibm.com>
+
+commit d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9 upstream.
+
+A system crash like this
+
+ Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
+ Fault in home space mode while using kernel ASCE.
+ AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
+ Oops: 0038 ilc:3 [#1] PREEMPT SMP
+ Modules linked in: mlx5_ib ...
+ CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
+ Hardware name: IBM 3931 A01 704 (LPAR)
+ Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
+ R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
+ Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
+ 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
+ 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
+ 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
+ Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a
+ 0000014b75e7b600: 18b2 lr %r11,%r2
+ #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616
+ >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13)
+ 0000014b75e7b60c: a7680001 lhi %r6,1
+ 0000014b75e7b610: 187b lr %r7,%r11
+ 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654
+ 0000014b75e7b616: 18e9 lr %r14,%r9
+ Call Trace:
+ [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8
+ ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8)
+ [<0000014b75e7b758>] apmask_store+0x68/0x140
+ [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8
+ [<0000014b75598524>] vfs_write+0x1b4/0x448
+ [<0000014b7559894c>] ksys_write+0x74/0x100
+ [<0000014b7618a440>] __do_syscall+0x268/0x328
+ [<0000014b761a3558>] system_call+0x70/0x98
+ INFO: lockdep is turned off.
+ Last Breaking-Event-Address:
+ [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8
+ Kernel panic - not syncing: Fatal exception: panic_on_oops
+
+occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
+(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
+
+The fix is simple: use unsigned long values for the internal variables. The
+correct checks are already in place in the function but a simple int for
+the internal variables was used with the possibility to overflow.
+
+Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
+Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
+Tested-by: Marc Hartmayer <mhartmay@linux.ibm.com>
+Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/crypto/ap_bus.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/s390/crypto/ap_bus.c
++++ b/drivers/s390/crypto/ap_bus.c
+@@ -947,7 +947,7 @@ static int hex2bitmap(const char *str, u
+ */
+ static int modify_bitmap(const char *str, unsigned long *bitmap, int bits)
+ {
+- int a, i, z;
++ unsigned long a, i, z;
+ char *np, sign;
+
+ /* bits needs to be a multiple of 8 */