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: Yeoreum Yun yeoreum.yun@arm.com

[ Upstream commit 746d9e9f62a6e8ba0eba2b83fc61cfe7fa8797ce ]

To generate the boot_aggregate log in the IMA subsystem using TPM PCR values, the TPM driver must be built as built-in and must be probed before the IMA subsystem is initialized.

However, when the TPM device operates over the FF-A protocol using the CRB interface, probing fails and returns -EPROBE_DEFER if the tpm_crb_ffa device — an FF-A device that provides the communication interface to the tpm_crb driver — has not yet been probed.

This issue occurs because both crb_acpi_driver_init() and tpm_crb_ffa_driver_init() are registered with device_initcall. As a result, crb_acpi_driver_init() may be invoked before tpm_crb_ffa_driver_init(), which is responsible for probing the tpm_crb_ffa device.

When this happens, IMA fails to detect the TPM device and logs the following message:

| ima: No TPM chip found, activating TPM-bypass!

Consequently, it cannot generate the boot_aggregate log with the PCR values provided by the TPM.

To resolve this issue, the tpm_crb_ffa_init() function explicitly attempts to probe the tpm_crb_ffa by register tpm_crb_ffa driver so that when tpm_crb_ffa device is created before tpm_crb_ffa_init(), probe the tpm_crb_ffa device in tpm_crb_ffa_init() to finish probe the TPM device completely.

This ensures that the TPM device using CRB over FF-A can be successfully probed, even if crb_acpi_driver_init() is called first.

[ jarkko: reformatted some of the paragraphs because they were going past the 75 character boundary. ]

Signed-off-by: Yeoreum Yun yeoreum.yun@arm.com Reviewed-by: Mimi Zohar zohar@linux.ibm.com Reviewed-by: Sudeep Holla sudeep.holla@arm.com Reviewed-by: Jarkko Sakkinen jarkko@kernel.org Signed-off-by: Jarkko Sakkinen jarkko@kernel.org 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. **Fixes a functional bug affecting users**: The commit addresses a race condition where IMA (Integrity Measurement Architecture) fails to detect TPM devices that use CRB over FF-A, resulting in the message "ima: No TPM chip found, activating TPM-bypass!" This prevents IMA from generating boot_aggregate logs with TPM PCR values, which is a critical security feature.

2. **Small and contained fix**: The change is minimal and focused: - Adds a static forward declaration of `tpm_crb_ffa_driver` - Modifies `tpm_crb_ffa_init()` to explicitly register the FFA driver when built-in - Adds conditional compilation guards around `module_ffa_driver()`

3. **No architectural changes**: The fix doesn't introduce new features or change the architecture. It simply ensures proper driver registration ordering when the driver is built-in.

4. **Clear root cause**: The issue occurs because both `crb_acpi_driver_init()` and `tpm_crb_ffa_driver_init()` are registered with `device_initcall`, leading to unpredictable initialization order. When `crb_acpi_driver_init()` runs first, it calls `tpm_crb_ffa_init()` which returns `-ENOENT` because the FFA driver hasn't been registered yet.

5. **Security implications**: TPM is a critical security component, and IMA's inability to use TPM measurements compromises system integrity attestation. This fix ensures security features work as intended.

6. **Minimal risk**: The changes only affect the initialization path when `CONFIG_TCG_ARM_CRB_FFA` is built-in (not as a module). The fix: - Only executes when `!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)` - Preserves existing error handling - Doesn't change the module case behavior

7. **Well-reviewed**: The commit has been reviewed by multiple maintainers including Mimi Zohar (IMA maintainer), Sudeep Holla (ARM FF-A maintainer), and Jarkko Sakkinen (TPM maintainer).

The fix is important for ARM systems using FF-A to communicate with TPM devices, ensuring that security features like IMA work correctly when TPM drivers are built into the kernel.

drivers/char/tpm/tpm_crb_ffa.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c index 4ead61f01299..462fcf610020 100644 --- a/drivers/char/tpm/tpm_crb_ffa.c +++ b/drivers/char/tpm/tpm_crb_ffa.c @@ -115,6 +115,7 @@ struct tpm_crb_ffa { };

static struct tpm_crb_ffa *tpm_crb_ffa; +static struct ffa_driver tpm_crb_ffa_driver;

static int tpm_crb_ffa_to_linux_errno(int errno) { @@ -168,13 +169,23 @@ static int tpm_crb_ffa_to_linux_errno(int errno) */ int tpm_crb_ffa_init(void) { + int ret = 0; + + if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) { + ret = ffa_register(&tpm_crb_ffa_driver); + if (ret) { + tpm_crb_ffa = ERR_PTR(-ENODEV); + return ret; + } + } + if (!tpm_crb_ffa) - return -ENOENT; + ret = -ENOENT;

if (IS_ERR_VALUE(tpm_crb_ffa)) - return -ENODEV; + ret = -ENODEV;

- return 0; + return ret; } EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);

@@ -369,7 +380,9 @@ static struct ffa_driver tpm_crb_ffa_driver = { .id_table = tpm_crb_ffa_device_id, };

+#ifdef MODULE module_ffa_driver(tpm_crb_ffa_driver); +#endif

MODULE_AUTHOR("Arm"); MODULE_DESCRIPTION("TPM CRB FFA driver");

From: Filipe Manana fdmanana@suse.com

[ Upstream commit 6599716de2d68ab7b3c0429221deca306dbda878 ]

If we attempt a mmap write into a NOCOW file or a prealloc extent when there is no more available data space (or unallocated space to allocate a new data block group) and we can do a NOCOW write (there are no reflinks for the target extent or snapshots), we always fail due to -ENOSPC, unlike for the regular buffered write and direct IO paths where we check that we can do a NOCOW write in case we can't reserve data space.

Simple reproducer:

$ cat test.sh #!/bin/bash

DEV=/dev/sdi MNT=/mnt/sdi

umount $DEV &> /dev/null mkfs.btrfs -f -b $((512 * 1024 * 1024)) $DEV mount $DEV $MNT

touch $MNT/foobar # Make it a NOCOW file. chattr +C $MNT/foobar

# Add initial data to file. xfs_io -c "pwrite -S 0xab 0 1M" $MNT/foobar

# Fill all the remaining data space and unallocated space with data. dd if=/dev/zero of=$MNT/filler bs=4K &> /dev/null

# Overwrite the file with a mmap write. Should succeed. xfs_io -c "mmap -w 0 1M" \ -c "mwrite -S 0xcd 0 1M" \ -c "munmap" \ $MNT/foobar

# Unmount, mount again and verify the new data was persisted. umount $MNT mount $DEV $MNT

od -A d -t x1 $MNT/foobar

umount $MNT

Running this:

$ ./test.sh (...) wrote 1048576/1048576 bytes at offset 0 1 MiB, 256 ops; 0.0008 sec (1.188 GiB/sec and 311435.5231 ops/sec) ./test.sh: line 24: 234865 Bus error xfs_io -c "mmap -w 0 1M" -c "mwrite -S 0xcd 0 1M" -c "munmap" $MNT/foobar 0000000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab * 1048576

Fix this by not failing in case we can't allocate data space and we can NOCOW into the target extent - reserving only metadata space in this case.

After this change the test passes:

$ ./test.sh (...) wrote 1048576/1048576 bytes at offset 0 1 MiB, 256 ops; 0.0007 sec (1.262 GiB/sec and 330749.3540 ops/sec) 0000000 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd * 1048576

A test case for fstests will be added soon.

Reviewed-by: Qu Wenruo wqu@suse.com Signed-off-by: Filipe Manana fdmanana@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis of this commit, here is my determination:

**Backport Status: YES**

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

1. **Fixes a real user-visible bug**: The commit fixes a clear functional regression where mmap writes to NOCOW files fail with -ENOSPC even when they shouldn't. The bug causes legitimate write operations to fail when the filesystem is nearly full, even though NOCOW writes should succeed without requiring new data space allocation.

2. **Contains a simple reproducer**: The commit message includes a clear test case that demonstrates the problem, showing it's a reproducible issue that users can encounter in normal usage scenarios.

3. **Limited scope and risk**: The fix is confined to the `btrfs_page_mkwrite()` function in fs/btrfs/file.c. It doesn't touch multiple subsystems or introduce architectural changes. The modification follows the same pattern already used in buffered write and direct IO paths.

4. **Follows existing patterns**: The fix applies the same NOCOW handling logic that already exists for regular buffered writes and direct IO. It's essentially fixing an inconsistency where mmap writes didn't have the same NOCOW fallback logic.

5. **Clear fix with minimal changes**: The patch adds proper NOCOW checking when data space reservation fails, similar to what's done in other write paths. It uses existing functions like `btrfs_check_nocow_lock()` and `btrfs_check_nocow_unlock()`.

6. **No new features**: This is purely a bug fix that restores expected behavior. It doesn't add any new functionality or APIs.

The code changes show a straightforward fix that: - Adds `only_release_metadata` flag to track NOCOW write scenarios - When data space reservation fails, checks if NOCOW write is possible - If NOCOW is possible, only reserves metadata space instead of failing - Properly releases resources in error paths based on whether it's a NOCOW operation

This is exactly the type of bug fix that stable kernels should receive - it fixes a specific functional problem without introducing new risks or complexity.

fs/btrfs/file.c | 59 ++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 8ce6f45f45e0..0a468bbfe015 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1842,6 +1842,7 @@ static vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf) loff_t size; size_t fsize = folio_size(folio); int ret; + bool only_release_metadata = false; u64 reserved_space; u64 page_start; u64 page_end; @@ -1862,10 +1863,34 @@ static vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf) * end up waiting indefinitely to get a lock on the page currently * being processed by btrfs_page_mkwrite() function. */ - ret = btrfs_delalloc_reserve_space(BTRFS_I(inode), &data_reserved, - page_start, reserved_space); - if (ret < 0) + ret = btrfs_check_data_free_space(BTRFS_I(inode), &data_reserved, + page_start, reserved_space, false); + if (ret < 0) { + size_t write_bytes = reserved_space; + + if (btrfs_check_nocow_lock(BTRFS_I(inode), page_start, + &write_bytes, false) <= 0) + goto out_noreserve; + + only_release_metadata = true; + + /* + * Can't write the whole range, there may be shared extents or + * holes in the range, bail out with @only_release_metadata set + * to true so that we unlock the nocow lock before returning the + * error. + */ + if (write_bytes < reserved_space) + goto out_noreserve; + } + ret = btrfs_delalloc_reserve_metadata(BTRFS_I(inode), reserved_space, + reserved_space, false); + if (ret < 0) { + if (!only_release_metadata) + btrfs_free_reserved_data_space(BTRFS_I(inode), data_reserved, + page_start, reserved_space); goto out_noreserve; + }

ret = file_update_time(vmf->vma->vm_file); if (ret < 0) @@ -1906,10 +1931,16 @@ static vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf) if (folio_contains(folio, (size - 1) >> PAGE_SHIFT)) { reserved_space = round_up(size - page_start, fs_info->sectorsize); if (reserved_space < fsize) { + const u64 to_free = fsize - reserved_space; + end = page_start + reserved_space - 1; - btrfs_delalloc_release_space(BTRFS_I(inode), - data_reserved, end + 1, - fsize - reserved_space, true); + if (only_release_metadata) + btrfs_delalloc_release_metadata(BTRFS_I(inode), + to_free, true); + else + btrfs_delalloc_release_space(BTRFS_I(inode), + data_reserved, end + 1, + to_free, true); } }

@@ -1946,10 +1977,16 @@ static vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf)

btrfs_set_inode_last_sub_trans(BTRFS_I(inode));

+ if (only_release_metadata) + btrfs_set_extent_bit(io_tree, page_start, end, EXTENT_NORESERVE, + &cached_state); + btrfs_unlock_extent(io_tree, page_start, page_end, &cached_state); up_read(&BTRFS_I(inode)->i_mmap_lock);

btrfs_delalloc_release_extents(BTRFS_I(inode), fsize); + if (only_release_metadata) + btrfs_check_nocow_unlock(BTRFS_I(inode)); sb_end_pagefault(inode->i_sb); extent_changeset_free(data_reserved); return VM_FAULT_LOCKED; @@ -1959,10 +1996,16 @@ static vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf) up_read(&BTRFS_I(inode)->i_mmap_lock); out: btrfs_delalloc_release_extents(BTRFS_I(inode), fsize); - btrfs_delalloc_release_space(BTRFS_I(inode), data_reserved, page_start, - reserved_space, true); + if (only_release_metadata) + btrfs_delalloc_release_metadata(BTRFS_I(inode), reserved_space, true); + else + btrfs_delalloc_release_space(BTRFS_I(inode), data_reserved, + page_start, reserved_space, true); extent_changeset_free(data_reserved); out_noreserve: + if (only_release_metadata) + btrfs_check_nocow_unlock(BTRFS_I(inode)); + sb_end_pagefault(inode->i_sb);

if (ret < 0)

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 320aaa41ec39..3ef30c36bf10 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -1958,8 +1958,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: John Garry john.g.garry@oracle.com

[ Upstream commit 7ef50c4c6a9c36fa3ea6f1681a80c0bf9a797345 ]

Same as done for raid0, set chunk_sectors limit to appropriately set the atomic write size limit.

Reviewed-by: Nilay Shroff nilay@linux.ibm.com Reviewed-by: Yu Kuai yukuai3@huawei.com Signed-off-by: John Garry john.g.garry@oracle.com Reviewed-by: Martin K. Petersen martin.petersen@oracle.com Link: https://lore.kernel.org/r/20250711105258.3135198-5-john.g.garry@oracle.com Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Based on my analysis, here's my assessment:

**Backport Status: YES**

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

1. **Bug Fix for Correctness**: The commit fixes a missing configuration that causes incorrect atomic write size limits in RAID10. The code shows that `lim.chunk_sectors` needs to be set properly for the atomic writes feature to work correctly. Without this, the `blk_stack_atomic_writes_chunk_sectors()` function in block/blk- settings.c won't have the correct chunk size information, leading to incorrect atomic write size calculations.

3. **Small and Contained Change**: The fix is a single line addition: ```c lim.chunk_sectors = mddev->chunk_sectors; ``` This is a minimal change that only affects the RAID10 queue limits setup.

4. **No Architectural Changes**: The change doesn't introduce new features or modify existing architecture. It simply ensures an existing field is properly initialized with the correct value that's already available (`mddev->chunk_sectors`).

5. **Prevents Data Corruption Risk**: Without proper chunk_sectors limits, atomic writes may not work correctly on RAID10 arrays. This could lead to writes that are supposed to be atomic being split incorrectly, potentially causing data integrity issues.

6. **Affects Users**: Any system using RAID10 with applications that rely on atomic writes (databases, filesystems) would be affected by this missing configuration. The fix ensures that atomic write guarantees are properly honored.

7. **Low Risk**: The change has minimal risk of regression as it only sets a field that was previously uninitialized. The value being set (`mddev->chunk_sectors`) is already validated and used elsewhere in the RAID10 code.

The commit is clearly a bug fix that corrects an oversight where RAID10 wasn't setting the chunk_sectors limit while RAID0 was already fixed for the same issue. This makes it an excellent candidate for stable backporting.

drivers/md/raid10.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index c9bd2005bfd0..a7594be2a704 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -4012,6 +4012,7 @@ static int raid10_set_queue_limits(struct mddev *mddev) md_init_stacking_limits(&lim); lim.max_write_zeroes_sectors = 0; lim.io_min = mddev->chunk_sectors << 9; + lim.chunk_sectors = mddev->chunk_sectors; lim.io_opt = lim.io_min * raid10_nr_stripes(conf); lim.features |= BLK_FEAT_ATOMIC_WRITES; err = mddev_stack_rdev_limits(mddev, &lim, MDDEV_STACK_INTEGRITY);

From: Andrew Price anprice@redhat.com

[ Upstream commit 557c024ca7250bb65ae60f16c02074106c2f197b ]

A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at:

index = hash >> (32 - dip->i_depth);

As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time.

So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there.

Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated.

Tested with the syzkaller repro.c and xfstests '-g quick'.

Reported-by: syzbot+4708579bb230a0582a57@syzkaller.appspotmail.com Signed-off-by: Andrew Price anprice@redhat.com Signed-off-by: Andreas Gruenbacher agruenba@redhat.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. **Fixes a Critical Security Bug**: The commit fixes an undefined behavior caused by an invalid shift operation (`index = hash >> (32 - dip->i_depth)`) when `i_depth` is 0. This results in a shift by 32, which is undefined behavior in C and can lead to unpredictable results or crashes.

2. **Reported by Syzbot**: The bug was discovered by syzbot (Google's kernel fuzzer), indicating it's a real issue that can be triggered, not just theoretical. The commit message includes `Reported-by: syzbot+4708579bb230a0582a57@syzkaller.appspotmail.com`.

3. **Small and Contained Fix**: The changes are minimal and focused: - In `fs/gfs2/dir.c`: Simply replaces an open-coded calculation with `ilog2()` for clarity - In `fs/gfs2/glops.c`: Adds a validation check for `i_depth` to ensure it's not less than the minimum valid value

4. **Clear Boundary Checking**: The fix adds proper validation in `gfs2_dinode_in()`: ```c if ((ip->i_diskflags & GFS2_DIF_EXHASH) && depth < ilog2(sdp->sd_hash_ptrs)) { gfs2_consist_inode(ip); return -EIO; } ``` This ensures exhash directories have a valid minimum depth based on the hash pointer count.

5. **No Feature Changes**: The commit doesn't introduce new features or change the filesystem behavior - it only adds validation to prevent corruption from causing undefined behavior.

7. **Tested**: The commit message indicates it was tested with both the syzkaller reproducer and xfstests, providing confidence in the fix.

The fix prevents filesystem corruption from causing undefined behavior that could lead to crashes or security issues, making it an excellent candidate for stable backporting according to stable tree rules.

fs/gfs2/dir.c | 6 ++---- fs/gfs2/glops.c | 6 ++++++ 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c index dbf1aede744c..509e2f0d97e7 100644 --- a/fs/gfs2/dir.c +++ b/fs/gfs2/dir.c @@ -60,6 +60,7 @@ #include <linux/crc32.h> #include <linux/vmalloc.h> #include <linux/bio.h> +#include <linux/log2.h>

#include "gfs2.h" #include "incore.h" @@ -912,7 +913,6 @@ static int dir_make_exhash(struct inode *inode) struct qstr args; struct buffer_head *bh, *dibh; struct gfs2_leaf *leaf; - int y; u32 x; __be64 *lp; u64 bn; @@ -979,9 +979,7 @@ static int dir_make_exhash(struct inode *inode) i_size_write(inode, sdp->sd_sb.sb_bsize / 2); gfs2_add_inode_blocks(&dip->i_inode, 1); dip->i_diskflags |= GFS2_DIF_EXHASH; - - for (x = sdp->sd_hash_ptrs, y = -1; x; x >>= 1, y++) ; - dip->i_depth = y; + dip->i_depth = ilog2(sdp->sd_hash_ptrs);

gfs2_dinode_out(dip, dibh->b_data);

diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c index cebd66b22694..fe0faad4892f 100644 --- a/fs/gfs2/glops.c +++ b/fs/gfs2/glops.c @@ -11,6 +11,7 @@ #include <linux/bio.h> #include <linux/posix_acl.h> #include <linux/security.h> +#include <linux/log2.h>

#include "gfs2.h" #include "incore.h" @@ -450,6 +451,11 @@ static int gfs2_dinode_in(struct gfs2_inode *ip, const void *buf) gfs2_consist_inode(ip); return -EIO; } + if ((ip->i_diskflags & GFS2_DIF_EXHASH) && + depth < ilog2(sdp->sd_hash_ptrs)) { + gfs2_consist_inode(ip); + return -EIO; + } ip->i_depth = (u8)depth; ip->i_entries = be32_to_cpu(str->di_entries);

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 0f03b21e66e4..7445e44eabff 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -636,9 +636,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. @@ -873,6 +870,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);

@@ -5774,19 +5781,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; }

@@ -5794,12 +5812,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); }

@@ -6646,8 +6658,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 d45a9e6ead80..67b365621507 100644 --- a/drivers/md/md.h +++ b/drivers/md/md.h @@ -700,11 +700,26 @@ static inline bool reshape_interrupted(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) { @@ -713,7 +728,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 1c8a736b3309..b2f168b0a0d1 100644 --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -1440,7 +1440,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); @@ -1461,7 +1461,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 65b2c92f69d3df81422d27e5be012e357e733241 ]

Commit fa997b0576c9 ("ata: ahci: Do not enable LPM if no LPM states are supported by the HBA") introduced an early return in ahci_update_initial_lpm_policy() to ensure that the target_lpm_policy of ports belonging to a host that does not support the Partial, Slumber and DevSleep power states is unchanged and remains set to ATA_LPM_UNKNOWN and thus prevents the execution of ata_eh_link_set_lpm().

However, a user or a system daemon (e.g. systemd-udevd) may still attempt changing the LPM policy through the sysfs link_power_management_policy of the host.

Improve this to prevent sysfs LPM policy changes by setting the flag ATA_FLAG_NO_LPM for the port of such host, and initialize the port target_lpm_policy to ATA_LPM_MAX_POWER to guarantee that no unsupported low power state is being used on the port and its link.

Signed-off-by: Damien Le Moal dlemoal@kernel.org Reviewed-by: Hannes Reinecke hare@suse.de Reviewed-by: Niklas Cassel cassel@kernel.org Link: https://lore.kernel.org/r/20250701125321.69496-9-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 message, code changes, and examination of the kernel repository context, I can provide the following assessment:

**Backport Status: YES**

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

1. **Bug Fix Nature**: This commit fixes a real bug where users could still change LPM (Link Power Management) policy through sysfs even when the hardware doesn't support any LPM states. The original commit fa997b0576c9 only prevented automatic LPM enablement but didn't block manual sysfs changes.

2. **User-Visible Issue**: The commit message explicitly mentions that "a user or a system daemon (e.g. systemd-udevd) may still attempt changing the LPM policy through the sysfs link_power_management_policy". This is a user-visible issue that could lead to unexpected behavior or system instability.

3. **Small and Contained Fix**: The code changes are minimal and well- contained: - Only adds 2 lines setting `ATA_FLAG_NO_LPM` flag and `target_lpm_policy = ATA_LPM_MAX_POWER` - Changes one debug message from "not enabling LPM" to "forcing LPM max_power" - The fix is localized to the `ahci_update_initial_lpm_policy()` function

4. **Follows Established Pattern**: The code already uses this exact same pattern for external ports (lines above show `ap->flags |= ATA_FLAG_NO_LPM; ap->target_lpm_policy = ATA_LPM_MAX_POWER;`), so this is extending an existing, proven approach.

5. **Prevents Invalid Configuration**: Looking at the sysfs handler `ata_scsi_lpm_store()` in libata-sata.c, it checks for `ATA_FLAG_NO_LPM` and returns `-EOPNOTSUPP`, which is the correct behavior this patch enables for unsupported hardware.

6. **Builds on Previous Stable Fix**: The referenced commit fa997b0576c9 was already marked for stable ("Cc: stable@vger.kernel.org"), and this commit completes that fix by closing the remaining gap.

7. **Low Risk**: The change has minimal risk of regression since it only affects hardware that doesn't support any LPM states, and for such hardware, preventing LPM policy changes is the correct behavior.

The commit follows stable kernel rules by fixing an important bug with minimal changes and low regression risk, making it an ideal candidate for stable backporting.

drivers/ata/ahci.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index aa93b0ecbbc6..04c9b601cac1 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1782,7 +1782,10 @@ static void ahci_update_initial_lpm_policy(struct ata_port *ap) if ((ap->host->flags & ATA_HOST_NO_PART) && (ap->host->flags & ATA_HOST_NO_SSC) && (ap->host->flags & ATA_HOST_NO_DEVSLP)) { - ata_port_dbg(ap, "no LPM states supported, not enabling LPM\n"); + ata_port_dbg(ap, + "No LPM states supported, forcing LPM max_power\n"); + ap->flags |= ATA_FLAG_NO_LPM; + ap->target_lpm_policy = ATA_LPM_MAX_POWER; return; }