January 2025 - Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1 0/1] CVE-2024-53158
by Lin Yujun 02 Jan '25

02 Jan '25

Dan Carpenter (1): soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get() drivers/soc/qcom/qcom-geni-se.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-6.6 0/9] ext4: correct behaviors under errors=remount-ro mode
by Baokun Li 02 Jan '25

02 Jan '25

Baokun Li (8): sb_writers: fix kabi broken Revert "ext4: don't set SB_RDONLY after filesystem errors" Revert "ext4: replace read-only check for shutdown check in mmp code" Revert "ext4: drop read-only check from ext4_force_commit()" Revert "ext4: drop read-only check in ext4_write_inode()" Revert "ext4: drop read-only check in ext4_init_inode_table()" Revert "ext4: warn on read-only filesystem in ext4_journal_check_start()" Revert "ext4: drop EXT4_MF_FS_ABORTED flag" Jan Kara (1): fs: fix a hungtask problem when freeze/unfreeze fs fs/ext4/ext4.h | 1 + fs/ext4/ext4_jbd2.c | 3 +-- fs/ext4/fsync.c | 7 ++++--- fs/ext4/ialloc.c | 6 ++++++ fs/ext4/inode.c | 11 +++++++---- fs/ext4/mballoc.c | 4 ++-- fs/ext4/mmp.c | 2 +- fs/ext4/super.c | 21 +++++++++++++-------- fs/super.c | 9 ++++++++- include/linux/fs.h | 5 ++++- 10 files changed, 47 insertions(+), 22 deletions(-) -- 2.46.1

2 10

[PATCH openEuler-22.03-LTS-SP1] smb: client: fix NULL ptr deref in crypto_aead_setkey()
by Baokun Li 02 Jan '25

02 Jan '25

From: Paulo Alcantara <pc(a)manguebit.com> stable inclusion from stable-v6.6.64 commit 46f8e25926817272ec8d5bfbd003569bdeb9a8c8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAG4 CVE: CVE-2024-53185 -------------------------------- commit 4bdec0d1f658f7c98749bd2c5a486e6cfa8565d2 upstream. Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4. Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added a @server->cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server->cipher_type is unset for SMB3.02. Fix the following KASAN splat by setting @server->cipher_type for SMB3.02 as well. mount.cifs //srv/share /mnt -o vers=3.02,seal,... BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cc: Tom Talpey <tom(a)talpey.com> Reported-by: Jianhong Yin <jiyin(a)redhat.com> Cc: stable(a)vger.kernel.org # v6.12 Fixes: b0abcd65ec54 ("smb: client: fix UAF in async decryption") Signed-off-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/smb/client/smb2pdu.c fs/cifs/smb2pdu.c [Context differences because there is no commit 38c8a9a52082 ("smb: move client and server files to common directory fs/smb").] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/cifs/smb2pdu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index ea82cd9e5512..c098e956d1cb 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -958,7 +958,9 @@ SMB2_negotiate(const unsigned int xid, struct cifs_ses *ses) * SMB3.0 supports only 1 cipher and doesn't have a encryption neg context * Set the cipher type manually. */ - if (server->dialect == SMB30_PROT_ID && (server->capabilities & SMB2_GLOBAL_CAP_ENCRYPTION)) + if ((server->dialect == SMB30_PROT_ID || + server->dialect == SMB302_PROT_ID) && + (server->capabilities & SMB2_GLOBAL_CAP_ENCRYPTION)) server->cipher_type = SMB2_ENCRYPTION_AES128_CCM; security_blob = smb2_get_data_area_len(&blob_offset, &blob_length, -- 2.46.1

2 1

[PATCH OLK-5.10] smb: client: fix NULL ptr deref in crypto_aead_setkey()
by Baokun Li 02 Jan '25

02 Jan '25

From: Paulo Alcantara <pc(a)manguebit.com> stable inclusion from stable-v6.6.64 commit 46f8e25926817272ec8d5bfbd003569bdeb9a8c8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAG4 CVE: CVE-2024-53185 -------------------------------- commit 4bdec0d1f658f7c98749bd2c5a486e6cfa8565d2 upstream. Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4. Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added a @server->cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server->cipher_type is unset for SMB3.02. Fix the following KASAN splat by setting @server->cipher_type for SMB3.02 as well. mount.cifs //srv/share /mnt -o vers=3.02,seal,... BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cc: Tom Talpey <tom(a)talpey.com> Reported-by: Jianhong Yin <jiyin(a)redhat.com> Cc: stable(a)vger.kernel.org # v6.12 Fixes: b0abcd65ec54 ("smb: client: fix UAF in async decryption") Signed-off-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: fs/smb/client/smb2pdu.c fs/cifs/smb2pdu.c [Context differences because there is no commit 38c8a9a52082 ("smb: move client and server files to common directory fs/smb").] Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/cifs/smb2pdu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 245e2dd5a194..4197096e7fdb 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -963,7 +963,9 @@ SMB2_negotiate(const unsigned int xid, struct cifs_ses *ses) * SMB3.0 supports only 1 cipher and doesn't have a encryption neg context * Set the cipher type manually. */ - if (server->dialect == SMB30_PROT_ID && (server->capabilities & SMB2_GLOBAL_CAP_ENCRYPTION)) + if ((server->dialect == SMB30_PROT_ID || + server->dialect == SMB302_PROT_ID) && + (server->capabilities & SMB2_GLOBAL_CAP_ENCRYPTION)) server->cipher_type = SMB2_ENCRYPTION_AES128_CCM; security_blob = smb2_get_data_area_len(&blob_offset, &blob_length, -- 2.46.1

2 1

[PATCH OLK-6.6] jfs: fix array-index-out-of-bounds in jfs_readdir
by Long Li 02 Jan '25

02 Jan '25

From: Ghanshyam Agrawal <ghanshyam1898(a)gmail.com> mainline inclusion from mainline-v6.10-rc2 commit 839f102efb168f02dfdd46717b7c6dddb26b015e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAOO CVE: CVE-2024-56596 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The stbl might contain some invalid values. Added a check to return error code in that case. Reported-by: syzbot+0315f8fe99120601ba88(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0315f8fe99120601ba88 Signed-off-by: Ghanshyam Agrawal <ghanshyam1898(a)gmail.com> Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/jfs/jfs_dtree.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c index 5d3127ca68a4..65e75d92487d 100644 --- a/fs/jfs/jfs_dtree.c +++ b/fs/jfs/jfs_dtree.c @@ -2891,6 +2891,14 @@ int jfs_readdir(struct file *file, struct dir_context *ctx) stbl = DT_GETSTBL(p); for (i = index; i < p->header.nextindex; i++) { + if (stbl[i] < 0 || stbl[i] > 127) { + jfs_err("JFS: Invalid stbl[%d] = %d for inode %ld, block = %lld", + i, stbl[i], (long)ip->i_ino, (long long)bn); + free_page(dirent_buf); + DT_PUTPAGE(mp); + return -EIO; + } + d = (struct ldtentry *) & p->slot[stbl[i]]; if (((long) jfs_dirent + d->namlen + 1) > -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read
by Long Li 02 Jan '25

02 Jan '25

From: Jordy Zomer <jordyzomer(a)google.com> mainline inclusion from mainline-v6.10-rc2 commit fc342cf86e2dc4d2edb0fc2ff5e28b6c7845adb9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAPD CVE: CVE-2024-56627 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- An offset from client could be a negative value, It could lead to an out-of-bounds read from the stream_buf. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf. Cc: stable(a)vger.kernel.org # v5.15+ Reported-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/smb2pdu.c fs/smb/server/smb2pdu.c [Conflicts due to ksmbd rename to smb/server] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ksmbd/smb2pdu.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index f104de64493b..b6194837028a 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -6319,6 +6319,10 @@ int smb2_read(struct ksmbd_work *work) } offset = le64_to_cpu(req->Offset); + if (offset < 0) { + err = -EINVAL; + goto out; + } length = le32_to_cpu(req->Length); mincount = le32_to_cpu(req->MinimumCount); -- 2.39.2

2 1

[PATCH OLK-5.10] ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read
by Long Li 02 Jan '25

02 Jan '25

From: Jordy Zomer <jordyzomer(a)google.com> mainline inclusion from mainline-v6.10-rc2 commit fc342cf86e2dc4d2edb0fc2ff5e28b6c7845adb9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAPD CVE: CVE-2024-56627 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- An offset from client could be a negative value, It could lead to an out-of-bounds read from the stream_buf. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf. Cc: stable(a)vger.kernel.org # v5.15+ Reported-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/smb2pdu.c fs/smb/server/smb2pdu.c [Conflicts due to ksmbd rename to smb/server] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ksmbd/smb2pdu.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index f104de64493b..b6194837028a 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -6319,6 +6319,10 @@ int smb2_read(struct ksmbd_work *work) } offset = le64_to_cpu(req->Offset); + if (offset < 0) { + err = -EINVAL; + goto out; + } length = le32_to_cpu(req->Length); mincount = le32_to_cpu(req->MinimumCount); -- 2.39.2

2 1

[PATCH OLK-6.6] io_uring/tctx: work around xa_store() allocation error issue
by Long Li 02 Jan '25

02 Jan '25

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v6.10-rc2 commit 7eb75ce7527129d7f1fee6951566af409a37a1c4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAP3 CVE: CVE-2024-56584 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found. Reported-by: syzbot+cc36d44ec9f368e443d3(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/io-uring/673c1643.050a0220.87769.0066.GAE@google.co… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- io_uring/tctx.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/io_uring/tctx.c b/io_uring/tctx.c index c043fe93a3f2..84f6a8385720 100644 --- a/io_uring/tctx.c +++ b/io_uring/tctx.c @@ -47,8 +47,19 @@ static struct io_wq *io_init_wq_offload(struct io_ring_ctx *ctx, void __io_uring_free(struct task_struct *tsk) { struct io_uring_task *tctx = tsk->io_uring; + struct io_tctx_node *node; + unsigned long index; - WARN_ON_ONCE(!xa_empty(&tctx->xa)); + /* + * Fault injection forcing allocation errors in the xa_store() path + * can lead to xa_empty() returning false, even though no actual + * node is stored in the xarray. Until that gets sorted out, attempt + * an iteration here and warn if any entries are found. + */ + xa_for_each(&tctx->xa, index, node) { + WARN_ON_ONCE(1); + break; + } WARN_ON_ONCE(tctx->io_wq); WARN_ON_ONCE(tctx->cached_refs); -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] io_uring/tctx: work around xa_store() allocation error issue
by Long Li 02 Jan '25

02 Jan '25

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v6.10-rc2 commit 7eb75ce7527129d7f1fee6951566af409a37a1c4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAP3 CVE: CVE-2024-56584 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found. Reported-by: syzbot+cc36d44ec9f368e443d3(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/io-uring/673c1643.050a0220.87769.0066.GAE@google.co… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: io_uring/io_uring.c io_uring/tctx.c [Conflicts due to __io_uring_free() move to io_uring/tctx.c in mainline] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- io_uring/io_uring.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index 4d69fb4cf803..e058ce8bb8e2 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -8341,8 +8341,19 @@ static int io_uring_alloc_task_context(struct task_struct *task, void __io_uring_free(struct task_struct *tsk) { struct io_uring_task *tctx = tsk->io_uring; + struct io_tctx_node *node; + unsigned long index; - WARN_ON_ONCE(!xa_empty(&tctx->xa)); + /* + * Fault injection forcing allocation errors in the xa_store() path + * can lead to xa_empty() returning false, even though no actual + * node is stored in the xarray. Until that gets sorted out, attempt + * an iteration here and warn if any entries are found. + */ + xa_for_each(&tctx->xa, index, node) { + WARN_ON_ONCE(1); + break; + } WARN_ON_ONCE(tctx->io_wq); WARN_ON_ONCE(tctx->cached_refs); -- 2.39.2

2 1

[PATCH OLK-5.10] io_uring/tctx: work around xa_store() allocation error issue
by Long Li 02 Jan '25

02 Jan '25

From: Jens Axboe <axboe(a)kernel.dk> mainline inclusion from mainline-v6.10-rc2 commit 7eb75ce7527129d7f1fee6951566af409a37a1c4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAP3 CVE: CVE-2024-56584 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- syzbot triggered the following WARN_ON: WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51 which is the WARN_ON_ONCE(!xa_empty(&tctx->xa)); sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with ->head being non-NULL even though no entries exist in the xarray. Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found. Reported-by: syzbot+cc36d44ec9f368e443d3(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/io-uring/673c1643.050a0220.87769.0066.GAE@google.co… Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: io_uring/io_uring.c io_uring/tctx.c [Conflicts due to __io_uring_free() move to io_uring/tctx.c in mainline] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- io_uring/io_uring.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index 6e5e00a7692c..170b3dbf0750 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -8537,8 +8537,19 @@ static int io_uring_alloc_task_context(struct task_struct *task, void __io_uring_free(struct task_struct *tsk) { struct io_uring_task *tctx = tsk->io_uring; + struct io_tctx_node *node; + unsigned long index; - WARN_ON_ONCE(!xa_empty(&tctx->xa)); + /* + * Fault injection forcing allocation errors in the xa_store() path + * can lead to xa_empty() returning false, even though no actual + * node is stored in the xarray. Until that gets sorted out, attempt + * an iteration here and warn if any entries are found. + */ + xa_for_each(&tctx->xa, index, node) { + WARN_ON_ONCE(1); + break; + } WARN_ON_ONCE(tctx->io_wq); WARN_ON_ONCE(tctx->cached_refs); -- 2.39.2

2 1

2025

2024

2023

2022

2021

2020

2019

Kernel January 2025