October 2024 - Linux-stable-mirror

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

by Mark Rutland

This series is a v5.15.y only backport (based on v5.15.167) 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… ... and were originally merged upstream in v6.12-rc2. The Cortex-A715 cputype definitions (which were originally merged upstream in v6.2) are backported as a prerequisite. This series does not apply to earlier stable trees, which will receive a separate backport. Mark. Anshuman Khandual (1): arm64: Add Cortex-715 CPU part definition Mark Rutland (2): arm64: cputype: Add Neoverse-N3 definitions arm64: errata: Expand speculative SSBS workaround once more Documentation/arm64/silicon-errata.rst | 4 ++++ arch/arm64/Kconfig | 2 ++ arch/arm64/include/asm/cputype.h | 4 ++++ arch/arm64/kernel/cpu_errata.c | 2 ++ 4 files changed, 12 insertions(+) -- 2.30.2

3 months, 1 week

1
3
0 0

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

by Mark Rutland

This series is a v6.1 only backport (based on v6.1.112) 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… ... and were originally merged upstream in v6.12-rc2. The Cortex-A715 cputype definitions (which were originally merged upstream in v6.2) are backported as a prerequisite. This series does not apply to earlier stable trees, which will receive a separate backport. Mark. Anshuman Khandual (1): arm64: Add Cortex-715 CPU part definition Mark Rutland (2): arm64: cputype: Add Neoverse-N3 definitions arm64: errata: Expand speculative SSBS workaround once more Documentation/arm64/silicon-errata.rst | 4 ++++ arch/arm64/Kconfig | 2 ++ arch/arm64/include/asm/cputype.h | 4 ++++ arch/arm64/kernel/cpu_errata.c | 2 ++ 4 files changed, 12 insertions(+) -- 2.30.2

3 months, 1 week

1
3
0 0

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

by Mark Rutland

This series is a v6.6.y only backport (based on v6.6.54) 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

3 months, 1 week

1
3
0 0

[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

3 months, 1 week

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

3 months, 1 week

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

3 months, 1 week

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

3 months, 1 week

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);

3 months, 1 week

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);

3 months, 1 week

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);

3 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024