From: Viacheslav Dubeyko slava@dubeyko.com

[ Upstream commit a431930c9bac518bf99d6b1da526a7f37ddee8d8 ]

This patch introduces is_bnode_offset_valid() method that checks the requested offset value. Also, it introduces check_and_correct_requested_length() method that checks and correct the requested length (if it is necessary). These methods are used in hfs_bnode_read(), hfs_bnode_write(), hfs_bnode_clear(), hfs_bnode_copy(), and hfs_bnode_move() with the goal to prevent the access out of allocated memory and triggering the crash.

Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Link: https://lore.kernel.org/r/20250703214912.244138-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should definitely be backported to stable kernel trees. Here's my detailed analysis:

## Critical Security Fix

This patch fixes a **critical security vulnerability** - a slab-out-of- bounds access that can lead to memory corruption and potentially local privilege escalation. The vulnerability exists in multiple HFS bnode operations:

1. **Affected Functions**: The patch adds bounds checking to `hfs_bnode_read()`, `hfs_bnode_write()`, `hfs_bnode_clear()`, `hfs_bnode_copy()`, and `hfs_bnode_move()` - all core operations for HFS B-tree node handling.

2. **Root Cause**: These functions previously accepted offset and length parameters without any validation, allowing reads/writes beyond allocated memory when processing malformed HFS filesystems.

## Nature of the Fix

The fix is well-designed and minimal:

1. **Two validation functions added**: - `is_bnode_offset_valid()`: Ensures offset is within node boundaries - `check_and_correct_requested_length()`: Adjusts length to prevent out-of-bounds access

2. **Defensive programming**: The functions log errors but continue safely rather than crashing, which is appropriate for filesystem code.

## Backporting Criteria Met

1. **Fixes a real bug affecting users**: Yes - security vulnerability with CVE assignments 2. **Small and contained**: Yes - adds ~56 lines of validation code, no architectural changes 3. **Clear side effects**: Minimal - only adds safety checks, no functional changes 4. **No major architectural changes**: Correct - just adds input validation 5. **Critical subsystem**: Yes - filesystem security vulnerability 6. **Risk assessment**: Low risk - purely defensive checks that prevent invalid operations

## Additional Context

- This is a **long-standing issue** (not a recent regression), making it even more important to backport - Similar fixes have been applied to HFS+ filesystem, showing this is a systematic issue - The vulnerability allows mounting malformed filesystems to trigger heap corruption - HFS is legacy but still supported for compatibility with older Mac systems

The patch perfectly fits stable tree criteria: it's a critical security fix that's minimal, well-contained, and has very low risk of introducing regressions while addressing a serious vulnerability.

fs/hfs/bnode.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+)

diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c index cb823a8a6ba9..1dac5d9c055f 100644 --- a/fs/hfs/bnode.c +++ b/fs/hfs/bnode.c @@ -15,6 +15,48 @@

#include "btree.h"

+static inline +bool is_bnode_offset_valid(struct hfs_bnode *node, int off) +{ + bool is_valid = off < node->tree->node_size; + + if (!is_valid) { + pr_err("requested invalid offset: " + "NODE: id %u, type %#x, height %u, " + "node_size %u, offset %d\n", + node->this, node->type, node->height, + node->tree->node_size, off); + } + + return is_valid; +} + +static inline +int check_and_correct_requested_length(struct hfs_bnode *node, int off, int len) +{ + unsigned int node_size; + + if (!is_bnode_offset_valid(node, off)) + return 0; + + node_size = node->tree->node_size; + + if ((off + len) > node_size) { + int new_len = (int)node_size - off; + + pr_err("requested length has been corrected: " + "NODE: id %u, type %#x, height %u, " + "node_size %u, offset %d, " + "requested_len %d, corrected_len %d\n", + node->this, node->type, node->height, + node->tree->node_size, off, len, new_len); + + return new_len; + } + + return len; +} + void hfs_bnode_read(struct hfs_bnode *node, void *buf, int off, int len) { struct page *page; @@ -22,6 +64,20 @@ void hfs_bnode_read(struct hfs_bnode *node, void *buf, int off, int len) int bytes_read; int bytes_to_read;

+ if (!is_bnode_offset_valid(node, off)) + return; + + if (len == 0) { + pr_err("requested zero length: " + "NODE: id %u, type %#x, height %u, " + "node_size %u, offset %d, len %d\n", + node->this, node->type, node->height, + node->tree->node_size, off, len); + return; + } + + len = check_and_correct_requested_length(node, off, len); + off += node->page_offset; pagenum = off >> PAGE_SHIFT; off &= ~PAGE_MASK; /* compute page offset for the first page */ @@ -80,6 +136,20 @@ void hfs_bnode_write(struct hfs_bnode *node, void *buf, int off, int len) { struct page *page;

+ if (!is_bnode_offset_valid(node, off)) + return; + + if (len == 0) { + pr_err("requested zero length: " + "NODE: id %u, type %#x, height %u, " + "node_size %u, offset %d, len %d\n", + node->this, node->type, node->height, + node->tree->node_size, off, len); + return; + } + + len = check_and_correct_requested_length(node, off, len); + off += node->page_offset; page = node->page[0];

@@ -104,6 +174,20 @@ void hfs_bnode_clear(struct hfs_bnode *node, int off, int len) { struct page *page;

+ if (!is_bnode_offset_valid(node, off)) + return; + + if (len == 0) { + pr_err("requested zero length: " + "NODE: id %u, type %#x, height %u, " + "node_size %u, offset %d, len %d\n", + node->this, node->type, node->height, + node->tree->node_size, off, len); + return; + } + + len = check_and_correct_requested_length(node, off, len); + off += node->page_offset; page = node->page[0];

@@ -119,6 +203,10 @@ void hfs_bnode_copy(struct hfs_bnode *dst_node, int dst, hfs_dbg(BNODE_MOD, "copybytes: %u,%u,%u\n", dst, src, len); if (!len) return; + + len = check_and_correct_requested_length(src_node, src, len); + len = check_and_correct_requested_length(dst_node, dst, len); + src += src_node->page_offset; dst += dst_node->page_offset; src_page = src_node->page[0]; @@ -136,6 +224,10 @@ void hfs_bnode_move(struct hfs_bnode *node, int dst, int src, int len) hfs_dbg(BNODE_MOD, "movebytes: %u,%u,%u\n", dst, src, len); if (!len) return; + + len = check_and_correct_requested_length(node, src, len); + len = check_and_correct_requested_length(node, dst, len); + src += node->page_offset; dst += node->page_offset; page = node->page[0];

From: Viacheslav Dubeyko slava@dubeyko.com

[ Upstream commit 94458781aee6045bd3d0ad4b80b02886b9e2219b ]

The hfsplus_readdir() method is capable to crash by calling hfsplus_uni2asc():

[ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] <TASK> [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0 [ 667.124911][ T9805] print_report+0xd0/0x660 [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610 [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124942][ T9805] kasan_report+0xc6/0x100 [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360 [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0 [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10 [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0 [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0 [ 667.125022][ T9805] ? lock_acquire+0x30/0x80 [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10 [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0 [ 667.125069][ T9805] iterate_dir+0x296/0xb20 [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? __pfx___x64_sys_getdents64+0x10/0x10 [ 667.125091][ T9805] ? __x64_sys_openat+0x141/0x200 [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10 [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0 [ 667.125143][ T9805] do_syscall_64+0xc9/0x480 [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] </TASK> [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasan_save_stack+0x20/0x40 [ 667.146352][ T9805] kasan_save_track+0x14/0x30 [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0 [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550 [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0 [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0 [ 667.148174][ T9805] iterate_dir+0x296/0xb20 [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.148937][ T9805] do_syscall_64+0xc9/0x480 [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.152580][ T9805] [ 667.152798][ T9805] The buggy address belongs to the physical page: [ 667.153373][ T9805] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x25928 [ 667.154157][ T9805] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 667.154916][ T9805] anon flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff) [ 667.155631][ T9805] page_type: f5(slab) [ 667.155997][ T9805] raw: 00fff00000000040 ffff88801b442f00 0000000000000000 dead000000000001 [ 667.156770][ T9805] raw: 0000000000000000 0000000080080008 00000000f5000000 0000000000000000 [ 667.157536][ T9805] head: 00fff00000000040 ffff88801b442f00 0000000000000000 dead000000000001 [ 667.158317][ T9805] head: 0000000000000000 0000000080080008 00000000f5000000 0000000000000000 [ 667.159088][ T9805] head: 00fff00000000003 ffffea0000964a01 00000000ffffffff 00000000ffffffff [ 667.159865][ T9805] head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 [ 667.160643][ T9805] page dumped because: kasan: bad access detected [ 667.161216][ T9805] page_owner tracks the page as allocated [ 667.161732][ T9805] page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN9 [ 667.163566][ T9805] post_alloc_hook+0x1c0/0x230 [ 667.164003][ T9805] get_page_from_freelist+0xdeb/0x3b30 [ 667.164503][ T9805] __alloc_frozen_pages_noprof+0x25c/0x2460 [ 667.165040][ T9805] alloc_pages_mpol+0x1fb/0x550 [ 667.165489][ T9805] new_slab+0x23b/0x340 [ 667.165872][ T9805] ___slab_alloc+0xd81/0x1960 [ 667.166313][ T9805] __slab_alloc.isra.0+0x56/0xb0 [ 667.166767][ T9805] __kmalloc_cache_noprof+0x255/0x3e0 [ 667.167255][ T9805] psi_cgroup_alloc+0x52/0x2d0 [ 667.167693][ T9805] cgroup_mkdir+0x694/0x1210 [ 667.168118][ T9805] kernfs_iop_mkdir+0x111/0x190 [ 667.168568][ T9805] vfs_mkdir+0x59b/0x8d0 [ 667.168956][ T9805] do_mkdirat+0x2ed/0x3d0 [ 667.169353][ T9805] __x64_sys_mkdir+0xef/0x140 [ 667.169784][ T9805] do_syscall_64+0xc9/0x480 [ 667.170195][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.170730][ T9805] page last free pid 1257 tgid 1257 stack trace: [ 667.171304][ T9805] __free_frozen_pages+0x80c/0x1250 [ 667.171770][ T9805] vfree.part.0+0x12b/0xab0 [ 667.172182][ T9805] delayed_vfree_work+0x93/0xd0 [ 667.172612][ T9805] process_one_work+0x9b5/0x1b80 [ 667.173067][ T9805] worker_thread+0x630/0xe60 [ 667.173486][ T9805] kthread+0x3a8/0x770 [ 667.173857][ T9805] ret_from_fork+0x517/0x6e0 [ 667.174278][ T9805] ret_from_fork_asm+0x1a/0x30 [ 667.174703][ T9805] [ 667.174917][ T9805] Memory state around the buggy address: [ 667.175411][ T9805] ffff88802592f300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 667.176114][ T9805] ffff88802592f380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 667.176830][ T9805] >ffff88802592f400: 00 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 667.177547][ T9805] ^ [ 667.177933][ T9805] ffff88802592f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 667.178640][ T9805] ffff88802592f500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 667.179350][ T9805] ==================================================================

The hfsplus_uni2asc() method operates by struct hfsplus_unistr:

struct hfsplus_unistr { __be16 length; hfsplus_unichr unicode[HFSPLUS_MAX_STRLEN]; } __packed;

where HFSPLUS_MAX_STRLEN is 255 bytes. The issue happens if length of the structure instance has value bigger than 255 (for example, 65283). In such case, pointer on unicode buffer is going beyond of the allocated memory.

The patch fixes the issue by checking the length value of hfsplus_unistr instance and using 255 value in the case if length value is bigger than HFSPLUS_MAX_STRLEN. Potential reason of such situation could be a corruption of Catalog File b-tree's node.

Reported-by: Wenzhi Wang wenzhi.wang@uwaterloo.ca Signed-off-by: Liu Shixin liushixin2@huawei.com Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com cc: John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de cc: Yangtao Li frank.li@vivo.com cc: linux-fsdevel@vger.kernel.org Reviewed-by: Yangtao Li frank.li@vivo.com Link: https://lore.kernel.org/r/20250710230830.110500-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Critical Security Vulnerability**: The commit fixes a slab-out-of- bounds read vulnerability in `hfsplus_uni2asc()` that can be triggered when processing malformed HFS+ filesystem data. The KASAN report shows this causes memory corruption with reads beyond allocated bounds.

2. **Exploitable Attack Vector**: The vulnerability can be triggered through normal filesystem operations (readdir) on a crafted/corrupted HFS+ filesystem. An attacker could craft a malicious HFS+ image with `ustr->length` values exceeding `HFSPLUS_MAX_STRLEN` (255) to trigger out-of-bounds reads.

3. **Simple and Contained Fix**: The fix is minimal and straightforward - it adds a bounds check that limits `ustrlen` to `HFSPLUS_MAX_STRLEN` before using it in the loop that reads from the `unicode` array. The change is only 7 lines of code addition with no architectural changes.

4. **Low Risk of Regression**: The fix only adds a defensive check and doesn't change normal operation for valid HFS+ filesystems. It simply prevents reading beyond the allocated buffer when corrupted data is encountered.

5. **Pattern of Similar Issues**: The git history shows multiple similar slab-out-of-bounds fixes in HFS+ recently (`ac7825c41213`, `bb5e07cb9277`), indicating this filesystem has ongoing boundary checking issues that need to be addressed in stable kernels.

6. **User Impact**: HFS+ filesystems are commonly used for compatibility with macOS systems. Users mounting untrusted HFS+ media (USB drives, disk images) could be vulnerable to crashes or potential exploitation without this fix.

The commit clearly meets stable kernel criteria: it fixes a real bug that affects users, the fix is small and contained, and the risk of regression is minimal while the security benefit is significant.

fs/hfsplus/unicode.c | 7 +++++++ 1 file changed, 7 insertions(+)

diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c index 73342c925a4b..36b6cf2a3abb 100644 --- a/fs/hfsplus/unicode.c +++ b/fs/hfsplus/unicode.c @@ -132,7 +132,14 @@ int hfsplus_uni2asc(struct super_block *sb,

op = astr; ip = ustr->unicode; + ustrlen = be16_to_cpu(ustr->length); + if (ustrlen > HFSPLUS_MAX_STRLEN) { + ustrlen = HFSPLUS_MAX_STRLEN; + pr_err("invalid length %u has been corrected to %d\n", + be16_to_cpu(ustr->length), ustrlen); + } + len = *len_p; ce1 = NULL; compose = !test_bit(HFSPLUS_SB_NODECOMPOSE, &HFSPLUS_SB(sb)->flags);

From: Kees Cook kees@kernel.org

[ Upstream commit 65c430906efffee9bd7551d474f01a6b1197df90 ]

GCC appears to have kind of fragile inlining heuristics, in the sense that it can change whether or not it inlines something based on optimizations. It looks like the kcov instrumentation being added (or in this case, removed) from a function changes the optimization results, and some functions marked "inline" are _not_ inlined. In that case, we end up with __init code calling a function not marked __init, and we get the build warnings I'm trying to eliminate in the coming patch that adds __no_sanitize_coverage to __init functions:

WARNING: modpost: vmlinux: section mismatch in reference: acpi_get_enable_method+0x1c (section: .text.unlikely) -> acpi_psci_present (section: .init.text)

This problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it), but we've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on.

For arm64 this requires forcing one ACPI function to be inlined with __always_inline.

Link: https://lore.kernel.org/r/20250724055029.3623499-1-kees@kernel.org Signed-off-by: Kees Cook kees@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis, here is my determination:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Fixes a real build warning/bug**: The commit addresses section mismatch warnings that occur when GCC's inlining heuristics change due to KCOV instrumentation. These warnings indicate potential runtime issues where __init code (which gets discarded after boot) calls non-__init functions, which could lead to crashes if those functions are called after the __init sections are freed.

2. **Minimal and contained change**: The fix is extremely simple - it only changes one function declaration from `static inline` to `static __always_inline` in arch/arm64/include/asm/acpi.h:153. This is a minimal change with very low risk.

4. **Prevents build regressions**: Without this fix, enabling KCOV instrumentation could cause build failures or warnings in stable kernels, which would be a regression for users who need to use KCOV for testing.

5. **Well-understood issue**: The commit message clearly explains the root cause - GCC's fragile inlining heuristics that change based on optimizations/instrumentation. The solution (__always_inline) is a well-established pattern in the kernel for forcing inlining.

6. **No functional change**: The change only affects compilation behavior by forcing inlining. The actual runtime behavior remains identical - `acpi_get_enable_method()` still calls `acpi_psci_present()` (marked __init) and returns the same values.

The specific code change shows `acpi_get_enable_method()` being changed from `static inline` to `static __always_inline`. This function calls `acpi_psci_present()`, which is marked `__init` (as seen in arch/arm64/kernel/acpi.c:110). Without forced inlining, GCC might not inline `acpi_get_enable_method()`, resulting in non-__init code calling __init code, triggering the section mismatch warning.

This is exactly the type of targeted, low-risk fix that stable trees are meant to include.

arch/arm64/include/asm/acpi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index a407f9cd549e..c07a58b96329 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -150,7 +150,7 @@ acpi_set_mailbox_entry(int cpu, struct acpi_madt_generic_interrupt *processor) {} #endif

-static inline const char *acpi_get_enable_method(int cpu) +static __always_inline const char *acpi_get_enable_method(int cpu) { if (acpi_psci_present()) return "psci";

From: Keith Busch kbusch@kernel.org

[ Upstream commit 5b2c214a95942f7997d1916a4c44017becbc3cac ]

NVMe devices from multiple vendors appear to get stuck in a reset state that we can't get out of with an NVMe level Controller Reset. The kernel would report these with messages that look like:

Device not ready; aborting reset, CSTS=0x1

These have historically required a power cycle to make them usable again, but in many cases, a PCIe FLR is sufficient to restart operation without a power cycle. Try it if the initial controller reset fails during any nvme reset attempt.

Signed-off-by: Keith Busch kbusch@kernel.org Reviewed-by: Chaitanya Kulkarni kch@nvidia.com Reviewed-by: Nitesh Shetty nj.shetty@samsung.com Signed-off-by: Christoph Hellwig hch@lst.de Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees based on the following analysis:

## 1. Fixes a Real User-Impacting Bug

The commit addresses a significant hardware issue where NVMe devices from multiple vendors get stuck in a reset state showing "Device not ready; aborting reset, CSTS=0x1". This is a real-world problem that: - Affects multiple vendors' devices (not vendor-specific) - Historically required a full power cycle to recover - Renders the storage device completely unusable

## 2. Minimal and Contained Fix

The code change is very focused and minimal: - Only adds ~20 lines of code in a single location - The fix is contained within the `nvme_pci_configure_admin_queue()` function - Only executes when the initial controller reset fails (error path) - No architectural changes or new features

## 3. Clear Recovery Mechanism

The fix implements a well-understood recovery mechanism: ```c if (result < 0) { struct pci_dev *pdev = to_pci_dev(dev->dev); result = pcie_reset_flr(pdev, false); if (result < 0) return result;

pci_restore_state(pdev); result = nvme_disable_ctrl(&dev->ctrl, false); ```

It uses PCIe Function Level Reset (FLR) as a "bigger hammer" when the NVMe-level controller reset fails, which is a standard PCIe recovery mechanism.

## 4. Low Risk of Regression

- Only triggers in error conditions (when `nvme_disable_ctrl` fails) - Falls back gracefully if FLR also fails - Uses existing, well-tested PCIe APIs (`pcie_reset_flr`, `pci_restore_state`) - Adds informative logging when recovery succeeds

## 5. Follows Stable Tree Rules

- Fixes a bug that prevents device initialization - No new features or functionality - Small, self-contained change - Clear benefit (avoiding power cycles) with minimal risk

## 6. Similar Issues Fixed in Stable

The git history shows multiple commits addressing "stuck reset" issues in the NVMe driver (e.g., `3f674e7b670b`, `ebef7368571d`), indicating this is an ongoing class of problems that stable kernels need to handle.

The commit message explicitly states this affects devices from "multiple vendors" and provides a solution that avoids requiring power cycles, making it a clear candidate for stable backporting to improve system reliability.

drivers/nvme/host/pci.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 97ab91a479d1..136dba6221d8 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -1755,8 +1755,28 @@ static int nvme_pci_configure_admin_queue(struct nvme_dev *dev) * might be pointing at! */ result = nvme_disable_ctrl(&dev->ctrl, false); - if (result < 0) - return result; + if (result < 0) { + struct pci_dev *pdev = to_pci_dev(dev->dev); + + /* + * The NVMe Controller Reset method did not get an expected + * CSTS.RDY transition, so something with the device appears to + * be stuck. Use the lower level and bigger hammer PCIe + * Function Level Reset to attempt restoring the device to its + * initial state, and try again. + */ + result = pcie_reset_flr(pdev, false); + if (result < 0) + return result; + + pci_restore_state(pdev); + result = nvme_disable_ctrl(&dev->ctrl, false); + if (result < 0) + return result; + + dev_info(dev->ctrl.device, + "controller reset completed after pcie flr\n"); + }

result = nvme_alloc_queue(dev, 0, NVME_AQ_DEPTH); if (result)

From: Xiao Ni xni@redhat.com

[ Upstream commit 9e59d609763f70a992a8f3808dabcce60f14eb5c ]

Now del_gendisk and put_disk are called asynchronously in workqueue work. The asynchronous way has a problem that the device node can still exist after mdadm --stop command returns in a short window. So udev rule can open this device node and create the struct mddev in kernel again. So put del_gendisk in control path and still leave put_disk in md_kobj_release to avoid uaf of gendisk.

Function del_gendisk can't be called with reconfig_mutex. If it's called with reconfig mutex, a deadlock can happen. del_gendisk waits all sysfs files access to finish and sysfs file access waits reconfig mutex. So put del_gendisk after releasing reconfig mutex.

But there is still a window that sysfs can be accessed between mddev_unlock and del_gendisk. So some actions (add disk, change level, .e.g) can happen which lead unexpected results. MD_DELETED is used to resolve this problem. MD_DELETED is set before releasing reconfig mutex and it should be checked for these sysfs access which need reconfig mutex. For sysfs access which don't need reconfig mutex, del_gendisk will wait them to finish.

But it doesn't need to do this in function mddev_lock_nointr. There are ten places that call it. * Five of them are in dm raid which we don't need to care. MD_DELETED is only used for md raid. * stop_sync_thread, md_do_sync and md_start_sync are related sync request, and it needs to wait sync thread to finish before stopping an array. * md_ioctl: md_open is called before md_ioctl, so ->openers is added. It will fail to stop the array. So it doesn't need to check MD_DELETED here * md_set_readonly: It needs to call mddev_set_closing_and_sync_blockdev when setting readonly or read_auto. So it will fail to stop the array too because MD_CLOSING is already set.

Reviewed-by: Yu Kuai yukuai3@huawei.com Signed-off-by: Xiao Ni xni@redhat.com Link: https://lore.kernel.org/linux-raid/20250611073108.25463-2-xni@redhat.com Signed-off-by: Yu Kuai yukuai3@huawei.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees. Here's my extensive analysis:

## 1. **Critical Race Condition Fix**

The commit addresses a serious race condition between `mdadm --stop` and udev that can lead to unexpected behavior:

```c // Before: del_gendisk was called asynchronously in md_kobj_release - del_gendisk(mddev->gendisk); put_disk(mddev->gendisk);

// After: del_gendisk moved to control path in mddev_unlock + if (test_bit(MD_DELETED, &mddev->flags)) + del_gendisk(mddev->gendisk); ```

The race window allows udev to reopen the device node after `mdadm --stop` returns but before `del_gendisk()` completes, creating a new `struct mddev` in the kernel unexpectedly.

## 2. **Use-After-Free Prevention**

The commit prevents a potential use-after-free (UAF) of gendisk by properly sequencing the cleanup: - `del_gendisk()` is called synchronously in the control path - `put_disk()` remains in `md_kobj_release()` to avoid UAF

## 3. **Deadlock Avoidance**

The implementation carefully avoids deadlocks by calling `del_gendisk()` after releasing `reconfig_mutex`:

```c // In mddev_unlock(): + /* Call del_gendisk after release reconfig_mutex to avoid + * deadlock (e.g. call del_gendisk under the lock and an + * access to sysfs files waits the lock) + */ + if (test_bit(MD_DELETED, &mddev->flags)) + del_gendisk(mddev->gendisk); ```

## 4. **MD_DELETED Flag Protection**

The commit introduces proper synchronization using the `MD_DELETED` flag:

```c // In mddev_lock(): + if (!ret && test_bit(MD_DELETED, &mddev->flags)) { + ret = -ENODEV; + mutex_unlock(&mddev->reconfig_mutex); + } ```

This prevents sysfs operations from racing with array shutdown.

## 5. **Minimal and Contained Changes**

The fix is: - Relatively small (~100 lines) - Confined to the md subsystem - Does not introduce new features - Does not make architectural changes - Only modifies the cleanup path timing

## 6. **Clear Bug Fix Criteria**

This meets all stable backport criteria: - Fixes a real bug that affects users (race condition causing unexpected device recreation) - Prevents potential data corruption/loss scenarios - Has minimal risk of regression (only affects shutdown path) - Is well-tested (has Reviewed-by tag) - Fixes behavior that violates expected semantics (device should be gone after `mdadm --stop`)

## 7. **Related UAF History**

Recent commit history shows ongoing UAF issues in md: - `8542870237c3 md: fix mddev uaf while iterating all_mddevs list` - This indicates the subsystem has had similar issues that required fixes

The synchronous `del_gendisk()` approach is the correct fix for this class of problems, making this an important stability improvement for the md subsystem.

drivers/md/md.c | 33 +++++++++++++++++++++++---------- drivers/md/md.h | 26 ++++++++++++++++++++++++-- 2 files changed, 47 insertions(+), 12 deletions(-)

diff --git a/drivers/md/md.c b/drivers/md/md.c index ca7ae3aad265..2758c3ee2f56 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -639,9 +639,6 @@ static void __mddev_put(struct mddev *mddev) mddev->ctime || mddev->hold_active) return;

- /* Array is not configured at all, and not held active, so destroy it */ - set_bit(MD_DELETED, &mddev->flags); - /* * Call queue_work inside the spinlock so that flush_workqueue() after * mddev_find will succeed in waiting for the work to be done. @@ -837,6 +834,16 @@ void mddev_unlock(struct mddev *mddev) kobject_del(&rdev->kobj); export_rdev(rdev, mddev); } + + /* Call del_gendisk after release reconfig_mutex to avoid + * deadlock (e.g. call del_gendisk under the lock and an + * access to sysfs files waits the lock) + * And MD_DELETED is only used for md raid which is set in + * do_md_stop. dm raid only uses md_stop to stop. So dm raid + * doesn't need to check MD_DELETED when getting reconfig lock + */ + if (test_bit(MD_DELETED, &mddev->flags)) + del_gendisk(mddev->gendisk); } EXPORT_SYMBOL_GPL(mddev_unlock);

@@ -5616,19 +5623,30 @@ md_attr_store(struct kobject *kobj, struct attribute *attr, struct md_sysfs_entry *entry = container_of(attr, struct md_sysfs_entry, attr); struct mddev *mddev = container_of(kobj, struct mddev, kobj); ssize_t rv; + struct kernfs_node *kn = NULL;

if (!entry->store) return -EIO; if (!capable(CAP_SYS_ADMIN)) return -EACCES; + + if (entry->store == array_state_store && cmd_match(page, "clear")) + kn = sysfs_break_active_protection(kobj, attr); + spin_lock(&all_mddevs_lock); if (!mddev_get(mddev)) { spin_unlock(&all_mddevs_lock); + if (kn) + sysfs_unbreak_active_protection(kn); return -EBUSY; } spin_unlock(&all_mddevs_lock); rv = entry->store(mddev, page, length); mddev_put(mddev); + + if (kn) + sysfs_unbreak_active_protection(kn); + return rv; }

@@ -5636,12 +5654,6 @@ static void md_kobj_release(struct kobject *ko) { struct mddev *mddev = container_of(ko, struct mddev, kobj);

- if (mddev->sysfs_state) - sysfs_put(mddev->sysfs_state); - if (mddev->sysfs_level) - sysfs_put(mddev->sysfs_level); - - del_gendisk(mddev->gendisk); put_disk(mddev->gendisk); }

@@ -6531,8 +6543,9 @@ static int do_md_stop(struct mddev *mddev, int mode, mddev->bitmap_info.offset = 0;

export_array(mddev); - md_clean(mddev); + set_bit(MD_DELETED, &mddev->flags); + if (mddev->hold_active == UNTIL_STOP) mddev->hold_active = 0; } diff --git a/drivers/md/md.h b/drivers/md/md.h index 46995558d3bd..0a7c9122db50 100644 --- a/drivers/md/md.h +++ b/drivers/md/md.h @@ -589,11 +589,26 @@ static inline bool is_md_suspended(struct mddev *mddev)

static inline int __must_check mddev_lock(struct mddev *mddev) { - return mutex_lock_interruptible(&mddev->reconfig_mutex); + int ret; + + ret = mutex_lock_interruptible(&mddev->reconfig_mutex); + + /* MD_DELETED is set in do_md_stop with reconfig_mutex. + * So check it here. + */ + if (!ret && test_bit(MD_DELETED, &mddev->flags)) { + ret = -ENODEV; + mutex_unlock(&mddev->reconfig_mutex); + } + + return ret; }

/* Sometimes we need to take the lock in a situation where * failure due to interrupts is not acceptable. + * It doesn't need to check MD_DELETED here, the owner which + * holds the lock here can't be stopped. And all paths can't + * call this function after do_md_stop. */ static inline void mddev_lock_nointr(struct mddev *mddev) { @@ -602,7 +617,14 @@ static inline void mddev_lock_nointr(struct mddev *mddev)

static inline int mddev_trylock(struct mddev *mddev) { - return mutex_trylock(&mddev->reconfig_mutex); + int ret; + + ret = mutex_trylock(&mddev->reconfig_mutex); + if (!ret && test_bit(MD_DELETED, &mddev->flags)) { + ret = -ENODEV; + mutex_unlock(&mddev->reconfig_mutex); + } + return ret; } extern void mddev_unlock(struct mddev *mddev);

From: Jan Kara jack@suse.cz

[ Upstream commit 1a11201668e8635602577dcf06f2e96c591d8819 ]

Verify that number of partition maps isn't insanely high which can lead to large allocation in udf_sb_alloc_partition_maps(). All partition maps have to fit in the LVD which is in a single block.

Reported-by: syzbot+478f2c1a6f0f447a46bb@syzkaller.appspotmail.com Signed-off-by: Jan Kara jack@suse.cz Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees based on the following analysis:

1. **Security Fix**: The commit addresses a security vulnerability reported by syzbot (syzbot+478f2c1a6f0f447a46bb@syzkaller.appspotmail.com), indicating this is fixing a real bug discovered through fuzzing. The issue could lead to excessive memory allocation in `udf_sb_alloc_partition_maps()`.

2. **Integer Overflow/Memory Exhaustion Prevention**: The code adds a crucial bounds check that prevents potentially huge allocations. Without this check, a malformed UDF filesystem could specify an arbitrarily large `numPartitionMaps` value, causing `kcalloc()` in `udf_sb_alloc_partition_maps()` to allocate excessive memory or fail.

3. **Small, Contained Fix**: The change is minimal - only 11 lines added and 2 modified. It adds a simple validation check: ```c if (part_map_count > table_len / sizeof(struct genericPartitionMap1)) ``` This ensures the partition map count doesn't exceed what can physically fit in the table.

4. **Clear Bug Fix Pattern**: The fix follows a standard pattern of input validation before allocation, which is a well-understood security best practice. The logic is straightforward: all partition maps must fit within the Logical Volume Descriptor (LVD) block.

5. **No Feature Changes**: This is purely a defensive check that prevents invalid input from causing problems. It doesn't change any functionality for valid UDF filesystems.

6. **Affects User-Facing Code**: UDF filesystem mounting is user-facing functionality that could be triggered by inserting malicious media or mounting crafted filesystem images, making this an important security boundary.

7. **Low Risk of Regression**: The added check only rejects invalid filesystems that would likely cause problems anyway. Valid UDF filesystems will pass this check without issue.

The commit follows stable kernel rules by fixing an important bug (potential DoS through memory exhaustion) with minimal, low-risk changes to a filesystem that handles untrusted input.

fs/udf/super.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/fs/udf/super.c b/fs/udf/super.c index 20dff9ed2471..cb13a07a4aa8 100644 --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -1409,7 +1409,7 @@ static int udf_load_logicalvol(struct super_block *sb, sector_t block, struct genericPartitionMap *gpm; uint16_t ident; struct buffer_head *bh; - unsigned int table_len; + unsigned int table_len, part_map_count; int ret;

bh = udf_read_tagged(sb, block, block, &ident); @@ -1430,7 +1430,16 @@ static int udf_load_logicalvol(struct super_block *sb, sector_t block, "logical volume"); if (ret) goto out_bh; - ret = udf_sb_alloc_partition_maps(sb, le32_to_cpu(lvd->numPartitionMaps)); + + part_map_count = le32_to_cpu(lvd->numPartitionMaps); + if (part_map_count > table_len / sizeof(struct genericPartitionMap1)) { + udf_err(sb, "error loading logical volume descriptor: " + "Too many partition maps (%u > %u)\n", part_map_count, + table_len / (unsigned)sizeof(struct genericPartitionMap1)); + ret = -EIO; + goto out_bh; + } + ret = udf_sb_alloc_partition_maps(sb, part_map_count); if (ret) goto out_bh;

From: Viacheslav Dubeyko slava@dubeyko.com

[ Upstream commit d3ed6d6981f4756f145766753c872482bc3b28d3 ]

The generic/001 test of xfstests suite fails and corrupts the HFS volume:

sudo ./check generic/001 FSTYP -- hfs PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.15.0-rc2+ #3 SMP PREEMPT_DYNAMIC Fri Apr 25 17:13:00 PDT 2> MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/001 32s ... _check_generic_filesystem: filesystem on /dev/loop50 is inconsistent (see /home/slavad/XFSTESTS-2/xfstests-dev/results//generic/001.full for details)

Ran: generic/001 Failures: generic/001 Failed 1 of 1 tests

fsck.hfs -d -n ./test-image.bin ** ./test-image.bin (NO WRITE) Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking HFS volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. Unused node is not erased (node = 2) Unused node is not erased (node = 4) <skipped> Unused node is not erased (node = 253) Unused node is not erased (node = 254) Unused node is not erased (node = 255) Unused node is not erased (node = 256) ** Checking catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000 CBTStat = 0x0004 CatStat = 0x00000000 ** The volume untitled was found corrupt and needs to be repaired. volume type is HFS primary MDB is at block 2 0x02 alternate MDB is at block 20971518 0x13ffffe primary VHB is at block 0 0x00 alternate VHB is at block 0 0x00 sector size = 512 0x200 VolumeObject flags = 0x19 total sectors for volume = 20971520 0x1400000 total sectors for embedded volume = 0 0x00

This patch adds logic of clearing the deleted b-tree node.

sudo ./check generic/001 FSTYP -- hfs PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.15.0-rc2+ #3 SMP PREEMPT_DYNAMIC Fri Apr 25 17:13:00 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/001 9s ... 32s Ran: generic/001 Passed all 1 tests

fsck.hfs -d -n ./test-image.bin ** ./test-image.bin (NO WRITE) Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking HFS volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled appears to be OK.

Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Reviewed-by: Johannes Thumshirn johannes.thumshirn@wdc.com Link: https://lore.kernel.org/r/20250430001211.1912533-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the commit and the surrounding code, I can now provide a determination on whether this should be backported to stable kernel trees.

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Fixes a real bug that causes filesystem corruption**: The commit fixes a bug where deleted b-tree nodes in HFS filesystems are not properly erased, leading to filesystem corruption that is detected by fsck.hfs. The commit message shows clear evidence of filesystem corruption with "Unused node is not erased" errors across multiple nodes (2, 4, 253-256).

2. **Small and contained fix**: The patch is only 1 line of code addition (`hfs_bnode_clear(node, 0, tree->node_size);`), well within the 100-line stable tree limit. The fix is localized to the HFS b-tree node management code and doesn't affect other subsystems.

3. **Obviously correct**: The fix adds a missing step that already exists in the HFS+ implementation. Looking at fs/hfsplus/bnode.c:728-729, the HFS+ code already calls `hfs_bnode_clear()` when deleting b-tree nodes (conditionally based on a volume attribute). The HFS code was missing this critical step entirely.

4. **Tested with concrete results**: The commit message includes before and after test results using xfstests generic/001, showing that the filesystem corruption is resolved after applying the patch. The "after" test shows "The volume untitled appears to be OK" from fsck.hfs.

5. **Data corruption prevention**: Without this fix, HFS filesystems can become corrupted during normal operations that involve b-tree node deletion, potentially leading to data loss. This is a serious issue that affects filesystem integrity.

6. **No architectural changes**: The commit doesn't introduce any new features or architectural changes - it simply adds a missing cleanup step that should have been there all along.

7. **Low regression risk**: The `hfs_bnode_clear()` function being called already exists and is used elsewhere in the HFS code. The fix follows the established pattern from HFS+ and uses existing, tested infrastructure.

The commit meets all the stable kernel rules criteria: it fixes a real bug that causes filesystem corruption, is small and contained, is obviously correct (matches HFS+ implementation), and has been tested to resolve the issue.

fs/hfs/bnode.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c index 1dac5d9c055f..e8cd1a31f247 100644 --- a/fs/hfs/bnode.c +++ b/fs/hfs/bnode.c @@ -574,6 +574,7 @@ void hfs_bnode_put(struct hfs_bnode *node) if (test_bit(HFS_BNODE_DELETED, &node->flags)) { hfs_bnode_unhash(node); spin_unlock(&tree->hash_lock); + hfs_bnode_clear(node, 0, tree->node_size); hfs_bmap_free(node); hfs_bnode_free(node); return;

From: Damien Le Moal dlemoal@kernel.org

[ Upstream commit 413e800cadbf67550d76c77c230b2ecd96bce83a ]

Modify ata_scsi_lpm_store() to return an error if a user attempts to set a link power management policy for a port that does not support LPM, that is, ports flagged with ATA_FLAG_NO_LPM.

Signed-off-by: Damien Le Moal dlemoal@kernel.org Reviewed-by: Niklas Cassel cassel@kernel.org Reviewed-by: Hannes Reinecke hare@suse.de Link: https://lore.kernel.org/r/20250701125321.69496-6-dlemoal@kernel.org Signed-off-by: Niklas Cassel cassel@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the commit and the surrounding code context, here's my determination:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Fixes a clear bug**: Without this check, users can attempt to change LPM policy on ports that don't support LPM (flagged with ATA_FLAG_NO_LPM), which could lead to undefined behavior or system issues. The code already prevents setting the policy but doesn't inform the user that the operation failed.

2. **User-visible issue**: The bug allows sysfs writes to succeed silently when they should fail with an error. This violates the principle of least surprise - users expect operations to either succeed or return an error, not silently fail.

3. **Small and contained fix**: The patch adds just 5 lines of code (lines 927-930) that perform a simple flag check and return -EOPNOTSUPP if the port doesn't support LPM. This is a minimal change with low risk of regression.

4. **Consistency with existing checks**: The function already has similar validation for device-level quirks (ATA_QUIRK_NOLPM at lines 934-937). This patch adds the missing port-level validation, making the code more consistent and complete.

5. **Related to recent fixes**: Looking at recent commits (65b2c92f69d3, 4edf1505b76d), there's been work to properly handle ports that don't support LPM. This patch completes that work by ensuring the sysfs interface properly rejects invalid operations.

6. **Prevents potential hardware issues**: Attempting to set LPM policies on hardware that doesn't support them could potentially cause hardware malfunctions or unexpected behavior. This fix prevents such attempts at the sysfs interface level.

The fix follows stable kernel rules: it's a clear bug fix, minimal in scope, doesn't introduce new features, and addresses a real user-facing issue where invalid operations appear to succeed when they should fail with an appropriate error code.

drivers/ata/libata-sata.c | 5 +++++ 1 file changed, 5 insertions(+)

diff --git a/drivers/ata/libata-sata.c b/drivers/ata/libata-sata.c index be72030a500d..9e0a820d6961 100644 --- a/drivers/ata/libata-sata.c +++ b/drivers/ata/libata-sata.c @@ -817,6 +817,11 @@ static ssize_t ata_scsi_lpm_store(struct device *device,

spin_lock_irqsave(ap->lock, flags);

+ if (ap->flags & ATA_FLAG_NO_LPM) { + count = -EOPNOTSUPP; + goto out_unlock; + } + ata_for_each_link(link, ap, EDGE) { ata_for_each_dev(dev, &ap->link, ENABLED) { if (dev->horkage & ATA_HORKAGE_NOLPM) {

From: Rong Zhang ulin0208@gmail.com

[ Upstream commit b1e9d89408f402858c00103f9831b25ffa0994d3 ]

After applying this patch, could correctly create symlink:

ln -s "relative/path/to/file" symlink

Signed-off-by: Rong Zhang ulin0208@gmail.com [almaz.alexandrovich@paragon-software.com: added cpu_to_le32 macro to rs->Flags assignment] Signed-off-by: Konstantin Komarov almaz.alexandrovich@paragon-software.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

**Backport Status: YES**

This commit should be backported to stable kernel trees for the following reasons:

1. **Bug Fix for User-Facing Functionality**: The commit fixes a specific bug where creating relative symlinks in NTFS3 filesystems would fail. The commit message clearly states it fixes the ability to run `ln -s "relative/path/to/file" symlink`, which is a basic filesystem operation that users expect to work correctly.

2. **Small and Contained Change**: The fix is relatively small and well- contained within the NTFS3 symlink creation code. The changes are limited to: - Adding an `is_absolute` parameter to `ntfs_reparse_bytes()` function - Modifying buffer size calculations based on whether the path is absolute or relative - Setting the `SYMLINK_FLAG_RELATIVE` flag correctly in `rs->Flags` - Conditionally adding the Windows path decoration (`??`) only for absolute paths

3. **Clear Root Cause**: The original code always treated symlinks as absolute paths by: - Always setting `rs->Flags = 0` (line 1125 in original), which means absolute path - Always adding 4 extra characters for the `??` prefix in buffer calculations - Always decorating paths with `??` prefix regardless of path type

4. **Minimal Risk of Regression**: The changes are straightforward: - The fix correctly identifies absolute paths by checking if the second character is ':' (Windows drive letter format) - It properly sets `SYMLINK_FLAG_RELATIVE` (value 1) for relative paths using `cpu_to_le32()` for endianness - Buffer calculations and path decorations are adjusted accordingly

5. **No Architectural Changes**: This is purely a bug fix that corrects the handling of relative symlinks. It doesn't introduce new features or change any fundamental behavior of the filesystem.

6. **Important for Interoperability**: NTFS3 is used for compatibility with Windows filesystems. Having broken relative symlink support impacts users who need to share filesystems between Linux and Windows, making this an important functionality fix.

The commit follows stable kernel rules by being a clear bug fix with minimal changes and low risk of introducing new issues. The fact that the maintainer added the proper endianness conversion (`cpu_to_le32`) shows careful attention to correctness.

fs/ntfs3/inode.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c index af7c0cbba74e..0150a2210209 100644 --- a/fs/ntfs3/inode.c +++ b/fs/ntfs3/inode.c @@ -1130,10 +1130,10 @@ int inode_write_data(struct inode *inode, const void *data, size_t bytes) * Number of bytes for REPARSE_DATA_BUFFER(IO_REPARSE_TAG_SYMLINK) * for unicode string of @uni_len length. */ -static inline u32 ntfs_reparse_bytes(u32 uni_len) +static inline u32 ntfs_reparse_bytes(u32 uni_len, bool is_absolute) { /* Header + unicode string + decorated unicode string. */ - return sizeof(short) * (2 * uni_len + 4) + + return sizeof(short) * (2 * uni_len + (is_absolute ? 4 : 0)) + offsetof(struct REPARSE_DATA_BUFFER, SymbolicLinkReparseBuffer.PathBuffer); } @@ -1146,8 +1146,11 @@ ntfs_create_reparse_buffer(struct ntfs_sb_info *sbi, const char *symname, struct REPARSE_DATA_BUFFER *rp; __le16 *rp_name; typeof(rp->SymbolicLinkReparseBuffer) *rs; + bool is_absolute;

- rp = kzalloc(ntfs_reparse_bytes(2 * size + 2), GFP_NOFS); + is_absolute = (strlen(symname) > 1 && symname[1] == ':'); + + rp = kzalloc(ntfs_reparse_bytes(2 * size + 2, is_absolute), GFP_NOFS); if (!rp) return ERR_PTR(-ENOMEM);

@@ -1162,7 +1165,7 @@ ntfs_create_reparse_buffer(struct ntfs_sb_info *sbi, const char *symname, goto out;

/* err = the length of unicode name of symlink. */ - *nsize = ntfs_reparse_bytes(err); + *nsize = ntfs_reparse_bytes(err, is_absolute);

if (*nsize > sbi->reparse.max_size) { err = -EFBIG; @@ -1182,7 +1185,7 @@ ntfs_create_reparse_buffer(struct ntfs_sb_info *sbi, const char *symname,

/* PrintName + SubstituteName. */ rs->SubstituteNameOffset = cpu_to_le16(sizeof(short) * err); - rs->SubstituteNameLength = cpu_to_le16(sizeof(short) * err + 8); + rs->SubstituteNameLength = cpu_to_le16(sizeof(short) * err + (is_absolute ? 8 : 0)); rs->PrintNameLength = rs->SubstituteNameOffset;

/* @@ -1190,16 +1193,18 @@ ntfs_create_reparse_buffer(struct ntfs_sb_info *sbi, const char *symname, * parse this path. * 0-absolute path 1- relative path (SYMLINK_FLAG_RELATIVE). */ - rs->Flags = 0; + rs->Flags = cpu_to_le32(is_absolute ? 0 : SYMLINK_FLAG_RELATIVE);

- memmove(rp_name + err + 4, rp_name, sizeof(short) * err); + memmove(rp_name + err + (is_absolute ? 4 : 0), rp_name, sizeof(short) * err);

- /* Decorate SubstituteName. */ - rp_name += err; - rp_name[0] = cpu_to_le16('\'); - rp_name[1] = cpu_to_le16('?'); - rp_name[2] = cpu_to_le16('?'); - rp_name[3] = cpu_to_le16('\'); + if (is_absolute) { + /* Decorate SubstituteName. */ + rp_name += err; + rp_name[0] = cpu_to_le16('\'); + rp_name[1] = cpu_to_le16('?'); + rp_name[2] = cpu_to_le16('?'); + rp_name[3] = cpu_to_le16('\'); + }

return rp; out:

From: Wei Gao wegao@suse.com

[ Upstream commit a099b09a3342a0b28ea330e405501b5b4d0424b4 ]

Previously, ext2_fiemap would unconditionally apply "len = min_t(u64, len, i_size_read(inode));", When inode->i_size was 0 (for an empty file), this would reduce the requested len to 0. Passing len = 0 to iomap_fiemap could then result in an -EINVAL error, even for valid queries on empty files.

Link: https://github.com/linux-test-project/ltp/issues/1246 Signed-off-by: Wei Gao wegao@suse.com Signed-off-by: Jan Kara jack@suse.cz Link: https://patch.msgid.link/20250613152402.3432135-1-wegao@suse.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of the commit and its context:

**Backport Status: YES**

This commit should be backported to stable kernel trees. Here's the extensive analysis:

**1. Bug Fix Analysis:** The commit fixes a user-visible bug where `fiemap` operations on empty files (i_size = 0) could fail with -EINVAL. Looking at the code change in fs/ext2/inode.c:

- **Before the fix**: `len = min_t(u64, len, i_size_read(inode));` would set len to 0 for empty files - **After the fix**: The code adds a special check: ```c if (i_size == 0) i_size = 1; len = min_t(u64, len, i_size); ```

This ensures that even for empty files, we pass a non-zero length to `iomap_fiemap()`.

**2. Root Cause:** From examining fs/ioctl.c:175-176, I found that `fiemap_prep()` explicitly returns -EINVAL when len is 0: ```c if (*len == 0) return -EINVAL; ```

This means `iomap_fiemap()` would fail when passed a zero length, which is exactly what was happening for empty ext2 files.

**3. Impact Assessment:** - **User-visible impact**: Applications using fiemap on empty ext2 files would receive unexpected EINVAL errors - **Test failure**: The commit references an LTP (Linux Test Project) issue (#1246), indicating this breaks existing tests - **Functional impact**: fiemap is a commonly used interface for discovering file extent mappings, and it should work on empty files (they simply have no extents)

**4. Fix Quality:** - **Minimal and contained**: The fix adds only 10 lines of code with a clear comment explaining the rationale - **Safe approach**: Setting i_size to 1 for the length calculation is safe because: - It only affects the length passed to iomap_fiemap - The comment explains this is specifically to avoid EINVAL from iomap_fiemap - The actual file size remains unchanged - **No architectural changes**: This is a simple boundary condition fix

**5. Regression Risk:** - **Low risk**: The change only affects the fiemap path for empty files - **Well-tested path**: fiemap is a read-only operation - **Clear boundary**: Only affects files where i_size == 0

**6. Stable Tree Criteria:** This fix meets all the stable tree criteria: - Fixes a real bug that users/tests hit - Small, self-contained change - No new features or architectural changes - Clear fix for a specific problem - Low risk of introducing regressions

**7. Similar Patterns:** The comment in the fix mentions that "ext2_get_blocks() iterates unmapped space block by block which is slow" - this suggests the min_t() optimization is important for performance on large sparse files, but shouldn't break functionality for empty files.

The fix properly balances maintaining the performance optimization while ensuring correctness for the edge case of empty files.

fs/ext2/inode.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c index 314b415ee518..6ff1f8f29a3c 100644 --- a/fs/ext2/inode.c +++ b/fs/ext2/inode.c @@ -895,9 +895,19 @@ int ext2_fiemap(struct inode *inode, struct fiemap_extent_info *fieinfo, u64 start, u64 len) { int ret; + loff_t i_size;

inode_lock(inode); - len = min_t(u64, len, i_size_read(inode)); + i_size = i_size_read(inode); + /* + * iomap_fiemap() returns EINVAL for 0 length. Make sure we don't trim + * length to 0 but still trim the range as much as possible since + * ext2_get_blocks() iterates unmapped space block by block which is + * slow. + */ + if (i_size == 0) + i_size = 1; + len = min_t(u64, len, i_size); ret = iomap_fiemap(inode, fieinfo, start, len, &ext2_iomap_ops); inode_unlock(inode);

From: Al Viro viro@zeniv.linux.org.uk

[ Upstream commit 27cd1bf1240d482e4f02ca4f9812e748f3106e4f ]

incidentally, securityfs_recursive_remove() is broken without that - it leaks dentries, since simple_recursive_removal() does not expect anything of that sort. It could be worked around by dput() in remove_one() callback, but it's easier to just drop that double-get stuff.

Signed-off-by: Al Viro viro@zeniv.linux.org.uk Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Now I have a clear understanding of the issue. Let me analyze this:

**YES**

This commit should be backported to stable kernel trees. Here's the extensive analysis:

## Analysis of the Double Dentry Reference Issue

The commit fixes a clear bug in securityfs where dentries are being pinned twice:

1. **The Bug**: In `securityfs_create_dentry()` at line 162, there's a `dget(dentry)` call immediately after `d_instantiate(dentry, inode)`. This creates an extra reference count on the dentry that is never properly balanced.

2. **Impact on `securityfs_remove()`**: The traditional `securityfs_remove()` function does call `dput(dentry)` at line 309, which would balance the extra `dget()`. However, this only happens for the simple remove case.

3. **Critical Impact on `securityfs_recursive_remove()`**: The newly added `securityfs_recursive_remove()` function (added in commit 7138679ff2a2) uses `simple_recursive_removal()` which expects normal dentry reference counting. The `simple_recursive_removal()` function in fs/libfs.c: - Takes its own reference with `dget(dentry)` at the beginning - Properly releases references with `dput()` calls throughout its execution - Does NOT expect the dentries to have extra references

4. **The Leak**: When `securityfs_recursive_remove()` is called, the extra reference from the `dget()` in `securityfs_create_dentry()` is never released because: - `simple_recursive_removal()` only releases the references it takes - The `remove_one()` callback only calls `simple_release_fs()` but doesn't do any `dput()` - This results in dentries being leaked with a refcount that never reaches zero

5. **Pattern Consistency**: Looking at similar filesystem implementations like debugfs (fs/debugfs/inode.c), they do NOT add an extra `dget()` after `d_instantiate()`. The pattern is simply: ```c d_instantiate(dentry, inode); return end_creating(dentry); ``` No extra reference is taken.

6. **Backport Criteria Met**: - **Fixes a real bug**: Memory leak of dentries when using `securityfs_recursive_remove()` - **Small and contained**: Single-line removal in two locations - **No side effects**: Removing the extra `dget()` brings the code in line with standard VFS patterns - **Low regression risk**: The fix makes securityfs consistent with other similar filesystems - **Important for stability**: Memory leaks in kernel filesystem code can accumulate over time

The commit message clearly identifies this as a bug fix ("securityfs_recursive_remove() is broken without that - it leaks dentries"), and the fix is minimal and correct. This makes it an ideal candidate for stable backporting.

security/inode.c | 2 -- 1 file changed, 2 deletions(-)

diff --git a/security/inode.c b/security/inode.c index 3aa75fffa8c9..a90b043695d9 100644 --- a/security/inode.c +++ b/security/inode.c @@ -159,7 +159,6 @@ static struct dentry *securityfs_create_dentry(const char *name, umode_t mode, inode->i_fop = fops; } d_instantiate(dentry, inode); - dget(dentry); inode_unlock(dir); return dentry;

@@ -306,7 +305,6 @@ void securityfs_remove(struct dentry *dentry) simple_rmdir(dir, dentry); else simple_unlink(dir, dentry); - dput(dentry); } inode_unlock(dir); simple_release_fs(&mount, &mount_count);