]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
5.15-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 20 Oct 2025 08:20:18 +0000 (10:20 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 20 Oct 2025 08:20:18 +0000 (10:20 +0200)
added patches:
btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch
ext4-detect-invalid-inline_data-extents-flag-combination.patch
jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch
kvm-arm64-prevent-access-to-vcpu-events-before-init.patch
r8152-add-error-handling-in-rtl8152_driver_init.patch
series

queue-5.15/btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch [new file with mode: 0644]
queue-5.15/ext4-detect-invalid-inline_data-extents-flag-combination.patch [new file with mode: 0644]
queue-5.15/jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch [new file with mode: 0644]
queue-5.15/kvm-arm64-prevent-access-to-vcpu-events-before-init.patch [new file with mode: 0644]
queue-5.15/r8152-add-error-handling-in-rtl8152_driver_init.patch [new file with mode: 0644]
queue-5.15/series [new file with mode: 0644]

diff --git a/queue-5.15/btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch b/queue-5.15/btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch
new file mode 100644 (file)
index 0000000..2afd078
--- /dev/null
@@ -0,0 +1,93 @@
+From 7e5a5983edda664e8e4bb20af17b80f5135c655c Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Wed, 24 Sep 2025 16:10:38 +0100
+Subject: btrfs: fix clearing of BTRFS_FS_RELOC_RUNNING if relocation already running
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 7e5a5983edda664e8e4bb20af17b80f5135c655c upstream.
+
+When starting relocation, at reloc_chunk_start(), if we happen to find
+the flag BTRFS_FS_RELOC_RUNNING is already set we return an error
+(-EINPROGRESS) to the callers, however the callers call reloc_chunk_end()
+which will clear the flag BTRFS_FS_RELOC_RUNNING, which is wrong since
+relocation was started by another task and still running.
+
+Finding the BTRFS_FS_RELOC_RUNNING flag already set is an unexpected
+scenario, but still our current behaviour is not correct.
+
+Fix this by never calling reloc_chunk_end() if reloc_chunk_start() has
+returned an error, which is what logically makes sense, since the general
+widespread pattern is to have end functions called only if the counterpart
+start functions succeeded. This requires changing reloc_chunk_start() to
+clear BTRFS_FS_RELOC_RUNNING if there's a pending cancel request.
+
+Fixes: 907d2710d727 ("btrfs: add cancellable chunk relocation support")
+CC: stable@vger.kernel.org # 5.15+
+Reviewed-by: Boris Burkov <boris@bur.io>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/relocation.c |   13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -3915,6 +3915,7 @@ out:
+ /*
+  * Mark start of chunk relocation that is cancellable. Check if the cancellation
+  * has been requested meanwhile and don't start in that case.
++ * NOTE: if this returns an error, reloc_chunk_end() must not be called.
+  *
+  * Return:
+  *   0             success
+@@ -3931,10 +3932,8 @@ static int reloc_chunk_start(struct btrf
+       if (atomic_read(&fs_info->reloc_cancel_req) > 0) {
+               btrfs_info(fs_info, "chunk relocation canceled on start");
+-              /*
+-               * On cancel, clear all requests but let the caller mark
+-               * the end after cleanup operations.
+-               */
++              /* On cancel, clear all requests. */
++              clear_and_wake_up_bit(BTRFS_FS_RELOC_RUNNING, &fs_info->flags);
+               atomic_set(&fs_info->reloc_cancel_req, 0);
+               return -ECANCELED;
+       }
+@@ -3943,9 +3942,11 @@ static int reloc_chunk_start(struct btrf
+ /*
+  * Mark end of chunk relocation that is cancellable and wake any waiters.
++ * NOTE: call only if a previous call to reloc_chunk_start() succeeded.
+  */
+ static void reloc_chunk_end(struct btrfs_fs_info *fs_info)
+ {
++      ASSERT(test_bit(BTRFS_FS_RELOC_RUNNING, &fs_info->flags));
+       /* Requested after start, clear bit first so any waiters can continue */
+       if (atomic_read(&fs_info->reloc_cancel_req) > 0)
+               btrfs_info(fs_info, "chunk relocation canceled during operation");
+@@ -4144,9 +4145,9 @@ out:
+       if (err && rw)
+               btrfs_dec_block_group_ro(rc->block_group);
+       iput(rc->data_inode);
++      reloc_chunk_end(fs_info);
+ out_put_bg:
+       btrfs_put_block_group(bg);
+-      reloc_chunk_end(fs_info);
+       free_reloc_control(rc);
+       return err;
+ }
+@@ -4337,8 +4338,8 @@ out_clean:
+               err = ret;
+ out_unset:
+       unset_reloc_control(rc);
+-out_end:
+       reloc_chunk_end(fs_info);
++out_end:
+       free_reloc_control(rc);
+ out:
+       free_reloc_roots(&reloc_roots);
diff --git a/queue-5.15/ext4-detect-invalid-inline_data-extents-flag-combination.patch b/queue-5.15/ext4-detect-invalid-inline_data-extents-flag-combination.patch
new file mode 100644 (file)
index 0000000..e94d03f
--- /dev/null
@@ -0,0 +1,63 @@
+From 1d3ad183943b38eec2acf72a0ae98e635dc8456b Mon Sep 17 00:00:00 2001
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+Date: Tue, 30 Sep 2025 16:58:10 +0530
+Subject: ext4: detect invalid INLINE_DATA + EXTENTS flag combination
+
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+
+commit 1d3ad183943b38eec2acf72a0ae98e635dc8456b upstream.
+
+syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity
+file on a corrupted ext4 filesystem mounted without a journal.
+
+The issue is that the filesystem has an inode with both the INLINE_DATA
+and EXTENTS flags set:
+
+    EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15:
+    comm syz.0.17: corrupted extent tree: lblk 0 < prev 66
+
+Investigation revealed that the inode has both flags set:
+    DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1
+
+This is an invalid combination since an inode should have either:
+- INLINE_DATA: data stored directly in the inode
+- EXTENTS: data stored in extent-mapped blocks
+
+Having both flags causes ext4_has_inline_data() to return true, skipping
+extent tree validation in __ext4_iget(). The unvalidated out-of-order
+extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer
+underflow when calculating hole sizes.
+
+Fix this by detecting this invalid flag combination early in ext4_iget()
+and rejecting the corrupted inode.
+
+Cc: stable@kernel.org
+Reported-and-tested-by: syzbot+038b7bf43423e132b308@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=038b7bf43423e132b308
+Suggested-by: Zhang Yi <yi.zhang@huawei.com>
+Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
+Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
+Message-ID: <20250930112810.315095-1-kartikey406@gmail.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/inode.c |    8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/fs/ext4/inode.c
++++ b/fs/ext4/inode.c
+@@ -4785,6 +4785,14 @@ struct inode *__ext4_iget(struct super_b
+       }
+       ei->i_flags = le32_to_cpu(raw_inode->i_flags);
+       ext4_set_inode_flags(inode, true);
++      /* Detect invalid flag combination - can't have both inline data and extents */
++      if (ext4_test_inode_flag(inode, EXT4_INODE_INLINE_DATA) &&
++          ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) {
++              ext4_error_inode(inode, function, line, 0,
++                      "inode has both inline data and extents flags");
++              ret = -EFSCORRUPTED;
++              goto bad_inode;
++      }
+       inode->i_blocks = ext4_inode_blocks(raw_inode, ei);
+       ei->i_file_acl = le32_to_cpu(raw_inode->i_file_acl_lo);
+       if (ext4_has_feature_64bit(sb))
diff --git a/queue-5.15/jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch b/queue-5.15/jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch
new file mode 100644 (file)
index 0000000..b9adedf
--- /dev/null
@@ -0,0 +1,85 @@
+From 3c652c3a71de1d30d72dc82c3bead8deb48eb749 Mon Sep 17 00:00:00 2001
+From: Zhang Yi <yi.zhang@huawei.com>
+Date: Tue, 16 Sep 2025 17:33:36 +0800
+Subject: jbd2: ensure that all ongoing I/O complete before freeing blocks
+
+From: Zhang Yi <yi.zhang@huawei.com>
+
+commit 3c652c3a71de1d30d72dc82c3bead8deb48eb749 upstream.
+
+When releasing file system metadata blocks in jbd2_journal_forget(), if
+this buffer has not yet been checkpointed, it may have already been
+written back, currently be in the process of being written back, or has
+not yet written back.  jbd2_journal_forget() calls
+jbd2_journal_try_remove_checkpoint() to check the buffer's status and
+add it to the current transaction if it has not been written back. This
+buffer can only be reallocated after the transaction is committed.
+
+jbd2_journal_try_remove_checkpoint() attempts to lock the buffer and
+check its dirty status while holding the buffer lock. If the buffer has
+already been written back, everything proceeds normally. However, there
+are two issues. First, the function returns immediately if the buffer is
+locked by the write-back process. It does not wait for the write-back to
+complete. Consequently, until the current transaction is committed and
+the block is reallocated, there is no guarantee that the I/O will
+complete. This means that ongoing I/O could write stale metadata to the
+newly allocated block, potentially corrupting data. Second, the function
+unlocks the buffer as soon as it detects that the buffer is still dirty.
+If a concurrent write-back occurs immediately after this unlocking and
+before clear_buffer_dirty() is called in jbd2_journal_forget(), data
+corruption can theoretically still occur.
+
+Although these two issues are unlikely to occur in practice since the
+undergoing metadata writeback I/O does not take this long to complete,
+it's better to explicitly ensure that all ongoing I/O operations are
+completed.
+
+Fixes: 597599268e3b ("jbd2: discard dirty data when forgetting an un-journalled buffer")
+Cc: stable@kernel.org
+Suggested-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Message-ID: <20250916093337.3161016-2-yi.zhang@huaweicloud.com>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jbd2/transaction.c |   13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/fs/jbd2/transaction.c
++++ b/fs/jbd2/transaction.c
+@@ -1669,6 +1669,7 @@ int jbd2_journal_forget(handle_t *handle
+       int drop_reserve = 0;
+       int err = 0;
+       int was_modified = 0;
++      int wait_for_writeback = 0;
+       if (is_handle_aborted(handle))
+               return -EROFS;
+@@ -1792,18 +1793,22 @@ int jbd2_journal_forget(handle_t *handle
+               }
+               /*
+-               * The buffer is still not written to disk, we should
+-               * attach this buffer to current transaction so that the
+-               * buffer can be checkpointed only after the current
+-               * transaction commits.
++               * The buffer has not yet been written to disk. We should
++               * either clear the buffer or ensure that the ongoing I/O
++               * is completed, and attach this buffer to current
++               * transaction so that the buffer can be checkpointed only
++               * after the current transaction commits.
+                */
+               clear_buffer_dirty(bh);
++              wait_for_writeback = 1;
+               __jbd2_journal_file_buffer(jh, transaction, BJ_Forget);
+               spin_unlock(&journal->j_list_lock);
+       }
+ drop:
+       __brelse(bh);
+       spin_unlock(&jh->b_state_lock);
++      if (wait_for_writeback)
++              wait_on_buffer(bh);
+       jbd2_journal_put_journal_head(jh);
+       if (drop_reserve) {
+               /* no need to reserve log space for this block -bzzz */
diff --git a/queue-5.15/kvm-arm64-prevent-access-to-vcpu-events-before-init.patch b/queue-5.15/kvm-arm64-prevent-access-to-vcpu-events-before-init.patch
new file mode 100644 (file)
index 0000000..71cac78
--- /dev/null
@@ -0,0 +1,86 @@
+From 0aa1b76fe1429629215a7c79820e4b96233ac4a3 Mon Sep 17 00:00:00 2001
+From: Oliver Upton <oliver.upton@linux.dev>
+Date: Tue, 30 Sep 2025 01:52:37 -0700
+Subject: KVM: arm64: Prevent access to vCPU events before init
+
+From: Oliver Upton <oliver.upton@linux.dev>
+
+commit 0aa1b76fe1429629215a7c79820e4b96233ac4a3 upstream.
+
+Another day, another syzkaller bug. KVM erroneously allows userspace to
+pend vCPU events for a vCPU that hasn't been initialized yet, leading to
+KVM interpreting a bunch of uninitialized garbage for routing /
+injecting the exception.
+
+In one case the injection code and the hyp disagree on whether the vCPU
+has a 32bit EL1 and put the vCPU into an illegal mode for AArch64,
+tripping the BUG() in exception_target_el() during the next injection:
+
+  kernel BUG at arch/arm64/kvm/inject_fault.c:40!
+  Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
+  CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT
+  Hardware name: linux,dummy-virt (DT)
+  pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
+  pc : exception_target_el+0x88/0x8c
+  lr : pend_serror_exception+0x18/0x13c
+  sp : ffff800082f03a10
+  x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000
+  x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000
+  x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004
+  x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000
+  x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0
+  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
+  x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
+  x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000
+  x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000
+  x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20
+  Call trace:
+   exception_target_el+0x88/0x8c (P)
+   kvm_inject_serror_esr+0x40/0x3b4
+   __kvm_arm_vcpu_set_events+0xf0/0x100
+   kvm_arch_vcpu_ioctl+0x180/0x9d4
+   kvm_vcpu_ioctl+0x60c/0x9f4
+   __arm64_sys_ioctl+0xac/0x104
+   invoke_syscall+0x48/0x110
+   el0_svc_common.constprop.0+0x40/0xe0
+   do_el0_svc+0x1c/0x28
+   el0_svc+0x34/0xf0
+   el0t_64_sync_handler+0xa0/0xe4
+   el0t_64_sync+0x198/0x19c
+  Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
+
+Reject the ioctls outright as no sane VMM would call these before
+KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been
+thrown away by the eventual reset of the vCPU's state.
+
+Cc: stable@vger.kernel.org # 6.17
+Fixes: b7b27facc7b5 ("arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS")
+Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kvm/arm.c |    6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/arm64/kvm/arm.c
++++ b/arch/arm64/kvm/arm.c
+@@ -1313,6 +1313,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi
+       case KVM_GET_VCPU_EVENTS: {
+               struct kvm_vcpu_events events;
++              if (!kvm_vcpu_initialized(vcpu))
++                      return -ENOEXEC;
++
+               if (kvm_arm_vcpu_get_events(vcpu, &events))
+                       return -EINVAL;
+@@ -1324,6 +1327,9 @@ long kvm_arch_vcpu_ioctl(struct file *fi
+       case KVM_SET_VCPU_EVENTS: {
+               struct kvm_vcpu_events events;
++              if (!kvm_vcpu_initialized(vcpu))
++                      return -ENOEXEC;
++
+               if (copy_from_user(&events, argp, sizeof(events)))
+                       return -EFAULT;
diff --git a/queue-5.15/r8152-add-error-handling-in-rtl8152_driver_init.patch b/queue-5.15/r8152-add-error-handling-in-rtl8152_driver_init.patch
new file mode 100644 (file)
index 0000000..5f59bf0
--- /dev/null
@@ -0,0 +1,41 @@
+From 75527d61d60d493d1eb064f335071a20ca581f54 Mon Sep 17 00:00:00 2001
+From: Yi Cong <yicong@kylinos.cn>
+Date: Sat, 11 Oct 2025 16:24:15 +0800
+Subject: r8152: add error handling in rtl8152_driver_init
+
+From: Yi Cong <yicong@kylinos.cn>
+
+commit 75527d61d60d493d1eb064f335071a20ca581f54 upstream.
+
+rtl8152_driver_init() is missing the error handling.
+When rtl8152_driver registration fails, rtl8152_cfgselector_driver
+should be deregistered.
+
+Fixes: ec51fbd1b8a2 ("r8152: add USB device driver for config selection")
+Cc: stable@vger.kernel.org
+Signed-off-by: Yi Cong <yicong@kylinos.cn>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20251011082415.580740-1-yicongsrfy@163.com
+[pabeni@redhat.com: clarified the commit message]
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/r8152.c |    7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/usb/r8152.c
++++ b/drivers/net/usb/r8152.c
+@@ -9925,7 +9925,12 @@ static int __init rtl8152_driver_init(vo
+       ret = usb_register_device_driver(&rtl8152_cfgselector_driver, THIS_MODULE);
+       if (ret)
+               return ret;
+-      return usb_register(&rtl8152_driver);
++
++      ret = usb_register(&rtl8152_driver);
++      if (ret)
++              usb_deregister_device_driver(&rtl8152_cfgselector_driver);
++
++      return ret;
+ }
+ static void __exit rtl8152_driver_exit(void)
diff --git a/queue-5.15/series b/queue-5.15/series
new file mode 100644 (file)
index 0000000..bafcad6
--- /dev/null
@@ -0,0 +1,5 @@
+r8152-add-error-handling-in-rtl8152_driver_init.patch
+kvm-arm64-prevent-access-to-vcpu-events-before-init.patch
+jbd2-ensure-that-all-ongoing-i-o-complete-before-freeing-blocks.patch
+ext4-detect-invalid-inline_data-extents-flag-combination.patch
+btrfs-fix-clearing-of-btrfs_fs_reloc_running-if-relocation-already-running.patch