October 2024 - Linux-stable-mirror

[PATCH 6.10 0/3] arm64: errata: Expand speculative SSBS workaround once more

by Mark Rutland

This series is a v6.10.y only backport (based on v6.10.13) of the recent MIDR updates for the speculative SSBS workaround, which were originally posted at: https://lore.kernel.org/linux-arm-kernel/20240930111705.3352047-1-mark.rutl… https://lore.kernel.org/linux-arm-kernel/20241003225239.321774-1-eahariha@l… ... and were originally merged upstream in v6.12-rc2. This series does not apply to earlier stable trees, which will receive a separate backport. Mark. Easwar Hariharan (1): arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386 Mark Rutland (2): arm64: cputype: Add Neoverse-N3 definitions arm64: errata: Expand speculative SSBS workaround once more Documentation/arch/arm64/silicon-errata.rst | 6 ++++++ arch/arm64/Kconfig | 2 ++ arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu_errata.c | 3 +++ 4 files changed, 13 insertions(+) -- 2.30.2

1 week, 5 days

1
3
0 0

[PATCH 6.11 0/3] arm64: errata: Expand speculative SSBS workaround once more

by Mark Rutland

This series is a v6.11.y only backport (based on v6.11.2) of the recent MIDR updates for the speculative SSBS workaround, which were originally posted at: https://lore.kernel.org/linux-arm-kernel/20240930111705.3352047-1-mark.rutl… https://lore.kernel.org/linux-arm-kernel/20241003225239.321774-1-eahariha@l… ... and were originally merged upstream in v6.12-rc2. This series does not apply to earlier stable trees, which will receive a separate backport. Mark. Easwar Hariharan (1): arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386 Mark Rutland (2): arm64: cputype: Add Neoverse-N3 definitions arm64: errata: Expand speculative SSBS workaround once more Documentation/arch/arm64/silicon-errata.rst | 6 ++++++ arch/arm64/Kconfig | 2 ++ arch/arm64/include/asm/cputype.h | 2 ++ arch/arm64/kernel/cpu_errata.c | 3 +++ 4 files changed, 13 insertions(+) -- 2.30.2

1 week, 5 days

1
3
0 0

[PATCH 0/3] crypto: Fix data mismatch over ipsec tunnel encrypted/decrypted with ppc64le AES/GCM module.

by Danny Tsen

Fix data mismatch over ipsec tunnel encrypted/decrypted with ppc64le AES/GCM module. This patch is to fix an issue when simd is not usable that data mismatch may occur. The fix is to register algs as SIMD modules so that the algorithm is excecuted when SIMD instructions is usable. A new module rfc4106(gcm(aes)) is also added. Re-write AES/GCM assembly codes with smaller footprints and small performance gain. This patch has been tested with the kernel crypto module tcrypt.ko and has passed the selftest. The patch is also tested with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS enabled. Fixes: fd0e9b3e2ee6 ("crypto: p10-aes-gcm - An accelerated AES/GCM stitched implementation") Fixes: cdcecfd9991f ("crypto: p10-aes-gcm - Glue code for AES/GCM stitched implementation") Fixes: 45a4672b9a6e2 ("crypto: p10-aes-gcm - Update Kconfig and Makefile") Signed-off-by: Danny Tsen <dtsen(a)linux.ibm.com> Danny Tsen (3): crypto: Re-write AES/GCM stitched implementation for ppcle64. crypto: Register modules as SIMD modules for ppcle64 AES/GCM algs. crypto: added CRYPTO_SIMD in Kconfig for CRYPTO_AES_GCM_P10. arch/powerpc/crypto/Kconfig | 2 +- arch/powerpc/crypto/aes-gcm-p10-glue.c | 141 +- arch/powerpc/crypto/aes-gcm-p10.S | 2421 +++++++++++------------- 3 files changed, 1187 insertions(+), 1377 deletions(-) -- 2.43.0

1 week, 5 days

3
6
0 0

[PATCH v2] pstore: Fix uaf when backend is unregistered

by Li XingYang

when unload pstore_blk, we will unlink the pstore file and set pos->dentry to NULL, but simple_unlink(d_inode(root), pos->dentry) may free inode of pos->dentry and free pos by free_pstore_private, this may trigger uaf. kasan report: kernel: ================================================================== kernel: BUG: KASAN: slab-use-after-free in pstore_put_backend_records+0x3a4/0x480 kernel: Write of size 8 at addr ffff8883efbe0390 by task modprobe/4308 kernel: kernel: CPU: 1 PID: 4308 Comm: modprobe Kdump: loaded Not tainted 6.10.9-arch1-2 #2 5fd36c90225554e2cc88363729bd91e76130a89f kernel: Hardware name: ASUS System Product Name/TUF GAMING X670E-PLUS, BIOS 3024 08/02/2024 kernel: Call Trace: kernel: <TASK> kernel: dump_stack_lvl+0x5d/0x80 kernel: print_report+0x174/0x505 kernel: ? __pfx__raw_spin_lock_irqsave+0x10/0x10 kernel: ? pstore_put_backend_records+0x3a4/0x480 kernel: kasan_report+0xd0/0x150 kernel: ? pstore_put_backend_records+0x3a4/0x480 kernel: pstore_put_backend_records+0x3a4/0x480 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: pstore_unregister+0x88/0x1b0 kernel: unregister_pstore_zone+0x2f/0xd0 [pstore_zone 35171c701a99c31efe207b7a718dc583e4a6503a] kernel: pstore_blk_exit+0x30/0x90 [pstore_blk 589d82101219208d8968e3adda9b96a2d42df635] kernel: __do_sys_delete_module+0x350/0x560 kernel: ? __pfx___do_sys_delete_module+0x10/0x10 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? __memcg_slab_free_hook+0x28e/0x470 kernel: ? __pfx___audit_syscall_exit+0x10/0x10 kernel: do_syscall_64+0x82/0x190 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? do_syscall_64+0x8e/0x190 kernel: ? seq_read_iter+0x62f/0x1220 kernel: ? __x64_sys_openat+0x300/0x380 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? kasan_save_track+0x14/0x30 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? vfs_read+0x9a7/0xf00 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? __audit_syscall_exit+0x38a/0x520 kernel: ? __pfx_vfs_read+0x10/0x10 kernel: ? __pfx___audit_syscall_exit+0x10/0x10 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? __audit_syscall_exit+0x38a/0x520 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? __pfx___audit_syscall_exit+0x10/0x10 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? __x64_sys_read+0x162/0x250 kernel: ? __pfx___x64_sys_read+0x10/0x10 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? syscall_exit_to_user_mode_prepare+0x148/0x170 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? syscall_exit_to_user_mode+0x73/0x1f0 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? do_syscall_64+0x8e/0x190 kernel: ? syscall_exit_to_user_mode+0x73/0x1f0 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: ? srso_alias_return_thunk+0x5/0xfbef5 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: RIP: 0033:0x741f9d72946b kernel: Code: 73 01 c3 48 8b 0d a5 c8 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 75 c8 0c 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffed7e621f8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 kernel: RAX: ffffffffffffffda RBX: 00006455e060ed30 RCX: 0000741f9d72946b kernel: RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00006455e060ed98 kernel: RBP: 00007ffed7e62220 R08: 1999999999999999 R09: 0000000000000000 kernel: R10: 0000741f9d7a5fe0 R11: 0000000000000206 R12: 0000000000000000 kernel: R13: 00007ffed7e62250 R14: 0000000000000000 R15: 0000000000000000 kernel: </TASK> kernel: kernel: Allocated by task 3957: kernel: kasan_save_stack+0x30/0x50 kernel: kasan_save_track+0x14/0x30 kernel: __kasan_kmalloc+0xaa/0xb0 kernel: pstore_mkfile+0x47e/0xbe0 kernel: pstore_get_backend_records+0x560/0x920 kernel: pstore_get_records+0xec/0x180 kernel: pstore_register+0x1c3/0x5a0 kernel: register_pstore_zone.cold+0x298/0x3d1 [pstore_zone] kernel: pstore_blk_init+0x63c/0xff0 [pstore_blk] kernel: do_one_initcall+0xa4/0x380 kernel: do_init_module+0x28a/0x7c0 kernel: load_module+0x7b57/0xb020 kernel: init_module_from_file+0xdf/0x150 kernel: idempotent_init_module+0x23c/0x780 kernel: __x64_sys_finit_module+0xbe/0x130 kernel: do_syscall_64+0x82/0x190 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: kernel: Freed by task 4308: kernel: kasan_save_stack+0x30/0x50 kernel: kasan_save_track+0x14/0x30 kernel: kasan_save_free_info+0x3b/0x60 kernel: __kasan_slab_free+0x12c/0x1b0 kernel: kfree+0x198/0x3b0 kernel: evict+0x33d/0xab0 kernel: __dentry_kill+0x17f/0x590 kernel: dput+0x2d9/0x810 kernel: simple_unlink+0xf4/0x140 kernel: pstore_put_backend_records+0x271/0x480 kernel: pstore_unregister+0x88/0x1b0 kernel: unregister_pstore_zone+0x2f/0xd0 [pstore_zone] kernel: pstore_blk_exit+0x30/0x90 [pstore_blk] kernel: __do_sys_delete_module+0x350/0x560 kernel: do_syscall_64+0x82/0x190 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: kernel: The buggy address belongs to the object at ffff8883efbe0380 which belongs to the cache kmalloc-64 of size 64 kernel: The buggy address is located 16 bytes inside of freed 64-byte region [ffff8883efbe0380, ffff8883efbe03c0) kernel: kernel: The buggy address belongs to the physical page: kernel: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3efbe0 kernel: memcg:ffff8883ef245801 kernel: flags: 0x2ffff8000000000(node=0|zone=2|lastcpupid=0x1ffff) kernel: page_type: 0xffffefff(slab) kernel: raw: 02ffff8000000000 ffff88810004c8c0 ffffea00043dcc40 dead000000000004 kernel: raw: 0000000000000000 0000000000200020 00000001ffffefff ffff8883ef245801 kernel: page dumped because: kasan: bad access detected kernel: kernel: Memory state around the buggy address: kernel: ffff8883efbe0280: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc kernel: ffff8883efbe0300: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc kernel: >ffff8883efbe0380: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc kernel: ^ kernel: ffff8883efbe0400: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc kernel: ffff8883efbe0480: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc kernel: ================================================================== kernel: Disabling lock debugging due to kernel taint kernel: pstore: Unregistered pstore_blk as persistent store backend kernel: ------------[ cut here ]------------ place the pos->dentry = NULL before simple_unlink(d_inode(root), pos->dentry) Fixes: 609e28bb139e ("pstore: Remove filesystem records when backend is unregistered") Cc: <stable(a)vger.kernel.org> # v5.8+ Signed-off-by: Li XingYang <lixingyang1(a)qq.com> Signed-off-by: Zach Wade <zachwade.k(a)gmail.com> --- fs/pstore/inode.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c index 56815799ce79..7561693e0f32 100644 --- a/fs/pstore/inode.c +++ b/fs/pstore/inode.c @@ -306,7 +306,7 @@ static struct dentry *psinfo_lock_root(void) int pstore_put_backend_records(struct pstore_info *psi) { struct pstore_private *pos, *tmp; - struct dentry *root; + struct dentry *root, *unlink_dentry; root = psinfo_lock_root(); if (!root) @@ -316,9 +316,10 @@ int pstore_put_backend_records(struct pstore_info *psi) list_for_each_entry_safe(pos, tmp, &records_list, list) { if (pos->record->psi == psi) { list_del_init(&pos->list); - d_invalidate(pos->dentry); - simple_unlink(d_inode(root), pos->dentry); + unlink_dentry = pos->dentry; pos->dentry = NULL; + d_invalidate(unlink_dentry); + simple_unlink(d_inode(root), unlink_dentry); } } } -- 2.46.2

1 week, 5 days

1
0
0 0

FAILED: patch "[PATCH] ext4: dax: fix overflowing extents beyond inode size when" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x dda898d7ffe85931f9cca6d702a51f33717c501e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100734-evasion-strung-a779@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: dda898d7ffe8 ("ext4: dax: fix overflowing extents beyond inode size when partially writing") 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO") 5899593f51e6 ("ext4: Fix occasional generic/418 failure") 60263d5889e6 ("iomap: fall back to buffered writes for invalidation failures") 54752de928c4 ("iomap: Only invalidate page cache pages on direct IO writes") 4209ae12b122 ("ext4: handle ext4_mark_inode_dirty errors") 9c94b39560c3 ("Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dda898d7ffe85931f9cca6d702a51f33717c501e Mon Sep 17 00:00:00 2001 From: Zhihao Cheng <chengzhihao1(a)huawei.com> Date: Fri, 9 Aug 2024 20:15:32 +0800 Subject: [PATCH] ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected. Fixes: 776722e85d3b ("ext4: DAX iomap write support") CC: stable(a)vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=219136 Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Link: https://patch.msgid.link/20240809121532.2105494-1-chengzhihao@huaweicloud.c… Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/file.c b/fs/ext4/file.c index c89e434db6b7..be061bb64067 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -334,10 +334,10 @@ static ssize_t ext4_handle_inode_extension(struct inode *inode, loff_t offset, * Clean up the inode after DIO or DAX extending write has completed and the * inode size has been updated using ext4_handle_inode_extension(). */ -static void ext4_inode_extension_cleanup(struct inode *inode, ssize_t count) +static void ext4_inode_extension_cleanup(struct inode *inode, bool need_trunc) { lockdep_assert_held_write(&inode->i_rwsem); - if (count < 0) { + if (need_trunc) { ext4_truncate_failed_write(inode); /* * If the truncate operation failed early, then the inode may @@ -586,7 +586,7 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, struct iov_iter *from) * writeback of delalloc blocks. */ WARN_ON_ONCE(ret == -EIOCBQUEUED); - ext4_inode_extension_cleanup(inode, ret); + ext4_inode_extension_cleanup(inode, ret < 0); } out: @@ -670,7 +670,7 @@ ext4_dax_write_iter(struct kiocb *iocb, struct iov_iter *from) if (extend) { ret = ext4_handle_inode_extension(inode, offset, ret); - ext4_inode_extension_cleanup(inode, ret); + ext4_inode_extension_cleanup(inode, ret < (ssize_t)count); } out: inode_unlock(inode);

1 week, 5 days

1
0
0 0

FAILED: patch "[PATCH] ext4: dax: fix overflowing extents beyond inode size when" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x dda898d7ffe85931f9cca6d702a51f33717c501e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100732-outscore-hardcore-8271@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: dda898d7ffe8 ("ext4: dax: fix overflowing extents beyond inode size when partially writing") 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO") 5899593f51e6 ("ext4: Fix occasional generic/418 failure") 60263d5889e6 ("iomap: fall back to buffered writes for invalidation failures") 54752de928c4 ("iomap: Only invalidate page cache pages on direct IO writes") 4209ae12b122 ("ext4: handle ext4_mark_inode_dirty errors") 9c94b39560c3 ("Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dda898d7ffe85931f9cca6d702a51f33717c501e Mon Sep 17 00:00:00 2001 From: Zhihao Cheng <chengzhihao1(a)huawei.com> Date: Fri, 9 Aug 2024 20:15:32 +0800 Subject: [PATCH] ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected. Fixes: 776722e85d3b ("ext4: DAX iomap write support") CC: stable(a)vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=219136 Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Link: https://patch.msgid.link/20240809121532.2105494-1-chengzhihao@huaweicloud.c… Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/file.c b/fs/ext4/file.c index c89e434db6b7..be061bb64067 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -334,10 +334,10 @@ static ssize_t ext4_handle_inode_extension(struct inode *inode, loff_t offset, * Clean up the inode after DIO or DAX extending write has completed and the * inode size has been updated using ext4_handle_inode_extension(). */ -static void ext4_inode_extension_cleanup(struct inode *inode, ssize_t count) +static void ext4_inode_extension_cleanup(struct inode *inode, bool need_trunc) { lockdep_assert_held_write(&inode->i_rwsem); - if (count < 0) { + if (need_trunc) { ext4_truncate_failed_write(inode); /* * If the truncate operation failed early, then the inode may @@ -586,7 +586,7 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, struct iov_iter *from) * writeback of delalloc blocks. */ WARN_ON_ONCE(ret == -EIOCBQUEUED); - ext4_inode_extension_cleanup(inode, ret); + ext4_inode_extension_cleanup(inode, ret < 0); } out: @@ -670,7 +670,7 @@ ext4_dax_write_iter(struct kiocb *iocb, struct iov_iter *from) if (extend) { ret = ext4_handle_inode_extension(inode, offset, ret); - ext4_inode_extension_cleanup(inode, ret); + ext4_inode_extension_cleanup(inode, ret < (ssize_t)count); } out: inode_unlock(inode);

1 week, 5 days

1
0
0 0

FAILED: patch "[PATCH] ext4: dax: fix overflowing extents beyond inode size when" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x dda898d7ffe85931f9cca6d702a51f33717c501e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100731-crawfish-voucher-f47b@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: dda898d7ffe8 ("ext4: dax: fix overflowing extents beyond inode size when partially writing") 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO") 5899593f51e6 ("ext4: Fix occasional generic/418 failure") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dda898d7ffe85931f9cca6d702a51f33717c501e Mon Sep 17 00:00:00 2001 From: Zhihao Cheng <chengzhihao1(a)huawei.com> Date: Fri, 9 Aug 2024 20:15:32 +0800 Subject: [PATCH] ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected. Fixes: 776722e85d3b ("ext4: DAX iomap write support") CC: stable(a)vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=219136 Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Link: https://patch.msgid.link/20240809121532.2105494-1-chengzhihao@huaweicloud.c… Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/file.c b/fs/ext4/file.c index c89e434db6b7..be061bb64067 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -334,10 +334,10 @@ static ssize_t ext4_handle_inode_extension(struct inode *inode, loff_t offset, * Clean up the inode after DIO or DAX extending write has completed and the * inode size has been updated using ext4_handle_inode_extension(). */ -static void ext4_inode_extension_cleanup(struct inode *inode, ssize_t count) +static void ext4_inode_extension_cleanup(struct inode *inode, bool need_trunc) { lockdep_assert_held_write(&inode->i_rwsem); - if (count < 0) { + if (need_trunc) { ext4_truncate_failed_write(inode); /* * If the truncate operation failed early, then the inode may @@ -586,7 +586,7 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, struct iov_iter *from) * writeback of delalloc blocks. */ WARN_ON_ONCE(ret == -EIOCBQUEUED); - ext4_inode_extension_cleanup(inode, ret); + ext4_inode_extension_cleanup(inode, ret < 0); } out: @@ -670,7 +670,7 @@ ext4_dax_write_iter(struct kiocb *iocb, struct iov_iter *from) if (extend) { ret = ext4_handle_inode_extension(inode, offset, ret); - ext4_inode_extension_cleanup(inode, ret); + ext4_inode_extension_cleanup(inode, ret < (ssize_t)count); } out: inode_unlock(inode);

1 week, 5 days

1
0
0 0

FAILED: patch "[PATCH] ext4: dax: fix overflowing extents beyond inode size when" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x dda898d7ffe85931f9cca6d702a51f33717c501e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100730-sleeve-exalted-315e@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: dda898d7ffe8 ("ext4: dax: fix overflowing extents beyond inode size when partially writing") 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dda898d7ffe85931f9cca6d702a51f33717c501e Mon Sep 17 00:00:00 2001 From: Zhihao Cheng <chengzhihao1(a)huawei.com> Date: Fri, 9 Aug 2024 20:15:32 +0800 Subject: [PATCH] ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected. Fixes: 776722e85d3b ("ext4: DAX iomap write support") CC: stable(a)vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=219136 Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Link: https://patch.msgid.link/20240809121532.2105494-1-chengzhihao@huaweicloud.c… Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/file.c b/fs/ext4/file.c index c89e434db6b7..be061bb64067 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -334,10 +334,10 @@ static ssize_t ext4_handle_inode_extension(struct inode *inode, loff_t offset, * Clean up the inode after DIO or DAX extending write has completed and the * inode size has been updated using ext4_handle_inode_extension(). */ -static void ext4_inode_extension_cleanup(struct inode *inode, ssize_t count) +static void ext4_inode_extension_cleanup(struct inode *inode, bool need_trunc) { lockdep_assert_held_write(&inode->i_rwsem); - if (count < 0) { + if (need_trunc) { ext4_truncate_failed_write(inode); /* * If the truncate operation failed early, then the inode may @@ -586,7 +586,7 @@ static ssize_t ext4_dio_write_iter(struct kiocb *iocb, struct iov_iter *from) * writeback of delalloc blocks. */ WARN_ON_ONCE(ret == -EIOCBQUEUED); - ext4_inode_extension_cleanup(inode, ret); + ext4_inode_extension_cleanup(inode, ret < 0); } out: @@ -670,7 +670,7 @@ ext4_dax_write_iter(struct kiocb *iocb, struct iov_iter *from) if (extend) { ret = ext4_handle_inode_extension(inode, offset, ret); - ext4_inode_extension_cleanup(inode, ret); + ext4_inode_extension_cleanup(inode, ret < (ssize_t)count); } out: inode_unlock(inode);

1 week, 5 days

1
0
0 0

Re: Patch "cgroup: Disallow mounting v1 hierarchies without controller implementation" has been added to the 6.10-stable tree

by Michal Koutný

Hello. On Sun, Oct 06, 2024 at 11:27:58AM GMT, Sasha Levin <sashal(a)kernel.org> wrote: > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. There's little benefit of this patch in kernels (pre-v6.11) without 773e9ae77fe77 ("mm: memcg: factor out legacy socket memory accounting code") (and later reworks) HTH, Michal

1 week, 5 days

1
0
0 0

FAILED: patch "[PATCH] mm, slub: avoid zeroing kmalloc redzone" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 59090e479ac78ae18facd4c58eb332562a23020e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100708-unhidden-unscathed-7372@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 59090e479ac7 ("mm, slub: avoid zeroing kmalloc redzone") 8f828aa48812 ("mm/slub: avoid zeroing outside-object freepointer for single free") 2d5524635b00 ("slub, kasan: improve interaction of KASAN and slub_debug poisoning") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 59090e479ac78ae18facd4c58eb332562a23020e Mon Sep 17 00:00:00 2001 From: Peng Fan <peng.fan(a)nxp.com> Date: Thu, 29 Aug 2024 11:29:11 +0800 Subject: [PATCH] mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with "slub_debug=FUZ init_on_free=1": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size. Fixes: 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested") Cc: <stable(a)vger.kernel.org> Reviewed-by: Feng Tang <feng.tang(a)intel.com> Acked-by: David Rientjes <rientjes(a)google.com> Signed-off-by: Peng Fan <peng.fan(a)nxp.com> Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> diff --git a/mm/slub.c b/mm/slub.c index 60004bfc2dc2..d52c88f29f69 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -756,6 +756,50 @@ static inline bool slab_update_freelist(struct kmem_cache *s, struct slab *slab, return false; } +/* + * kmalloc caches has fixed sizes (mostly power of 2), and kmalloc() API + * family will round up the real request size to these fixed ones, so + * there could be an extra area than what is requested. Save the original + * request size in the meta data area, for better debug and sanity check. + */ +static inline void set_orig_size(struct kmem_cache *s, + void *object, unsigned int orig_size) +{ + void *p = kasan_reset_tag(object); + unsigned int kasan_meta_size; + + if (!slub_debug_orig_size(s)) + return; + + /* + * KASAN can save its free meta data inside of the object at offset 0. + * If this meta data size is larger than 'orig_size', it will overlap + * the data redzone in [orig_size+1, object_size]. Thus, we adjust + * 'orig_size' to be as at least as big as KASAN's meta data. + */ + kasan_meta_size = kasan_metadata_size(s, true); + if (kasan_meta_size > orig_size) + orig_size = kasan_meta_size; + + p += get_info_end(s); + p += sizeof(struct track) * 2; + + *(unsigned int *)p = orig_size; +} + +static inline unsigned int get_orig_size(struct kmem_cache *s, void *object) +{ + void *p = kasan_reset_tag(object); + + if (!slub_debug_orig_size(s)) + return s->object_size; + + p += get_info_end(s); + p += sizeof(struct track) * 2; + + return *(unsigned int *)p; +} + #ifdef CONFIG_SLUB_DEBUG static unsigned long object_map[BITS_TO_LONGS(MAX_OBJS_PER_PAGE)]; static DEFINE_SPINLOCK(object_map_lock); @@ -985,50 +1029,6 @@ static void print_slab_info(const struct slab *slab) &slab->__page_flags); } -/* - * kmalloc caches has fixed sizes (mostly power of 2), and kmalloc() API - * family will round up the real request size to these fixed ones, so - * there could be an extra area than what is requested. Save the original - * request size in the meta data area, for better debug and sanity check. - */ -static inline void set_orig_size(struct kmem_cache *s, - void *object, unsigned int orig_size) -{ - void *p = kasan_reset_tag(object); - unsigned int kasan_meta_size; - - if (!slub_debug_orig_size(s)) - return; - - /* - * KASAN can save its free meta data inside of the object at offset 0. - * If this meta data size is larger than 'orig_size', it will overlap - * the data redzone in [orig_size+1, object_size]. Thus, we adjust - * 'orig_size' to be as at least as big as KASAN's meta data. - */ - kasan_meta_size = kasan_metadata_size(s, true); - if (kasan_meta_size > orig_size) - orig_size = kasan_meta_size; - - p += get_info_end(s); - p += sizeof(struct track) * 2; - - *(unsigned int *)p = orig_size; -} - -static inline unsigned int get_orig_size(struct kmem_cache *s, void *object) -{ - void *p = kasan_reset_tag(object); - - if (!slub_debug_orig_size(s)) - return s->object_size; - - p += get_info_end(s); - p += sizeof(struct track) * 2; - - return *(unsigned int *)p; -} - void skip_orig_size_check(struct kmem_cache *s, const void *object) { set_orig_size(s, (void *)object, s->object_size); @@ -1894,7 +1894,6 @@ static inline void inc_slabs_node(struct kmem_cache *s, int node, int objects) {} static inline void dec_slabs_node(struct kmem_cache *s, int node, int objects) {} - #ifndef CONFIG_SLUB_TINY static bool freelist_corrupted(struct kmem_cache *s, struct slab *slab, void **freelist, void *nextfree) @@ -2239,14 +2238,21 @@ bool slab_free_hook(struct kmem_cache *s, void *x, bool init) */ if (unlikely(init)) { int rsize; - unsigned int inuse; + unsigned int inuse, orig_size; inuse = get_info_end(s); + orig_size = get_orig_size(s, x); if (!kasan_has_integrated_init()) - memset(kasan_reset_tag(x), 0, s->object_size); + memset(kasan_reset_tag(x), 0, orig_size); rsize = (s->flags & SLAB_RED_ZONE) ? s->red_left_pad : 0; memset((char *)kasan_reset_tag(x) + inuse, 0, s->size - inuse - rsize); + /* + * Restore orig_size, otherwize kmalloc redzone overwritten + * would be reported + */ + set_orig_size(s, x, orig_size); + } /* KASAN might put x into memory quarantine, delaying its reuse. */ return !kasan_slab_free(s, x, init);

1 week, 5 days

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024