libceph: define and enforce CEPH_MAX_KEY_LEN

From: Ilya Dryomov <[email protected]>

[ Upstream commit ac431d597a9bdfc2ba6b314813f29a6ef2b4a3bf ]

When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length.

The new CEPH_MAX_KEY_LEN check replaces the existing check for a key with no key material which is a) not universal since CEPH_CRYPTO_NONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.

---

LLM Generated explanations, may be completely bogus:

This confirms the vulnerability. Now let me provide my complete analysis.

## Analysis

### What the commit does

This commit makes three changes to the libceph subsystem:

1. **Renames CEPH_KEY_LEN to CEPH_MAX_KEY_LEN** (value remains 16) in net/ceph/crypto.h to clarify the constant's purpose as a maximum bound.

2. **Adds a bounds check** in ceph_crypto_key_decode() (net/ceph/crypto.c:83-86) that validates key->len <= CEPH_MAX_KEY_LEN before the key material is used. The old !key->len check in set_secret() is removed as it's superseded by this.

3. **Updates the buffer reference** in process_auth_done() (net/ceph/messenger_v2.c:2363) to use the renamed constant.

### The vulnerability: Stack buffer overflow from network data

This is a **security fix** preventing a potential stack buffer overflow:

1. process_auth_done() allocates a fixed-size stack buffer: u8 session_key_buf[CEPH_KEY_LEN + 16] (32 bytes, of which 16 are usable after alignment).

2. This buffer is passed to handle_auth_done() → ceph_auth_handle_reply_done() → handle_auth_session_key() in auth_x.c:627-629, which does:

  ```c
  memcpy(session_key, th->session_key.key, th->session_key.len);
  ```

3. th->session_key is populated by ceph_crypto_key_decode() in process_one_ticket() (auth_x.c:207), where key->len is decoded directly from the network as a 16-bit integer with **no upper bounds validation**.

4. A malicious or compromised Ceph server (or MITM attacker) could send a key length > 16, causing a stack buffer overflow when the key material is memcpy'd into the 16-byte session_key_buf.

### Stable kernel criteria assessment

- **Fixes a real bug**: Yes - a security vulnerability (stack buffer overflow from network input)
- **Obviously correct**: Yes - adding a bounds check on network-decoded length against a buffer size constant is straightforward
- **Small and contained**: Yes - only ~10 lines of meaningful change across 3 files
- **No new features**: Correct - this only adds input validation
- **Tested**: The author is Ilya Dryomov, the Ceph subsystem maintainer himself

### Risk assessment

- **Very low risk**: The only behavioral change is rejecting keys with length > 16 bytes. AES-128 keys are 16 bytes, so valid Ceph keys will never be larger. There's no possibility of breaking existing working setups.
- **High benefit**: Prevents a remotely triggerable stack buffer overflow in the kernel.

### Related commits

Commit 818156caffbf5 ("libceph: prevent potential out-of-bounds reads in handle_auth_done()") was a related security fix with explicit `Cc:
[email protected]`, showing the Ceph maintainer considers these auth handling bounds checks to be stable-worthy.

### Verification

- **Verified call chain**: process_auth_done() (messenger_v2.c:2361) → handle_auth_done callback → handle_auth_session_key() (auth_x.c:627-629) copies th->session_key.key with length th->session_key.len into the fixed-size session_key buffer via memcpy.
- **Verified network origin of key->len**: ceph_crypto_key_decode() (crypto.c:82) reads key->len = ceph_decode_16(p) directly from network-supplied data, with only ceph_decode_need() checking buffer availability, not the value itself.
- **Verified buffer size**: session_key_buf at messenger_v2.c:2363 is CEPH_KEY_LEN + 16 = 32 bytes, with usable session key portion being only 16 bytes after PTR_ALIGN.
- **Verified related commit**: git show 818156caffbf5 confirmed it's another auth bounds-check fix with explicit `Cc:
[email protected]` and review from the same maintainer (Ilya Dryomov).
- **Verified the process_one_ticket path**: auth_x.c:207 shows ceph_crypto_key_decode(&new_session_key, &dp, dend) decoding the key from encrypted ticket data received from the network.
- **Verified the old check was insufficient**: The removed if (!key->len) return -EINVAL in set_secret() only rejected zero- length keys, not oversized ones.

### Conclusion

This is a clear security fix that prevents a remotely triggerable stack buffer overflow in the Ceph authentication path. The fix is minimal, obviously correct, and has no risk of regression. The Ceph subsystem maintainer authored it himself, and a closely related commit was explicitly marked for stable. This meets all stable kernel criteria.

**YES**

 net/ceph/crypto.c       | 8 +++++---
 net/ceph/crypto.h       | 2 +-
 net/ceph/messenger_v2.c | 2 +-
 3 files changed, 7 insertions(+), 5 deletions(-)

index 01b2ce1e8fc06..5601732cf4faa 100644
@@ -37,9 +37,6 @@ static int set_secret(struct ceph_crypto_key *key, void *buf)
 		return -ENOTSUPP;
 	}
 
-	if (!key->len)
-		return -EINVAL;
-
 	key->key = kmemdup(buf, key->len, GFP_NOIO);
 	if (!key->key) {
 		ret = -ENOMEM;

@@ -83,6 +80,11 @@ int ceph_crypto_key_decode(struct ceph_crypto_key *key, void **p, void *end)
 	ceph_decode_copy(p, &key->created, sizeof(key->created));
 	key->len = ceph_decode_16(p);
 	ceph_decode_need(p, end, key->len, bad);
+	if (key->len > CEPH_MAX_KEY_LEN) {
+		pr_err("secret too big %d\n", key->len);
+		return -EINVAL;
+	}
+
 	ret = set_secret(key, *p);
 	memzero_explicit(*p, key->len);
 	*p += key->len;

index 23de29fc613cf..a20bad6d1e964 100644
@@ -5,7 +5,7 @@
 #include <linux/ceph/types.h>
 #include <linux/ceph/buffer.h>
 
-#define CEPH_KEY_LEN			16
+#define CEPH_MAX_KEY_LEN		16
 #define CEPH_MAX_CON_SECRET_LEN		64
 
 /*

index c9d50c0dcd33a..31e042dc1b3f2 100644
@@ -2360,7 +2360,7 @@ static int process_auth_reply_more(struct ceph_connection *con,
  */
 static int process_auth_done(struct ceph_connection *con, void *p, void *end)
 {
-	u8 session_key_buf[CEPH_KEY_LEN + 16];
+	u8 session_key_buf[CEPH_MAX_KEY_LEN + 16];
 	u8 con_secret_buf[CEPH_MAX_CON_SECRET_LEN + 16];
 	u8 *session_key = PTR_ALIGN(&session_key_buf[0], 16);
 	u8 *con_secret = PTR_ALIGN(&con_secret_buf[0], 16);

2.51.0

From: Jaehun Gou <[email protected]>

[ Upstream commit 06909b2549d631a47fcda249d34be26f7ca1711d ]

We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition.

A malformed NTFS image can cause an infinite loop when an ATTR_LIST attribute indicates a zero data size while the driver allocates memory for it.

When ntfs_load_attr_list() processes a resident ATTR_LIST with data_size set to zero, it still allocates memory because of al_aligned(0). This creates an inconsistent state where ni->attr_list.size is zero, but ni->attr_list.le is non-null. This causes ni_enum_attr_ex to incorrectly assume that no attribute list exists and enumerates only the primary MFT record. When it finds ATTR_LIST, the code reloads it and restarts the enumeration, repeating indefinitely. The mount operation never completes, hanging the kernel thread.

This patch adds validation to ensure that data_size is non-zero before memory allocation. When a zero-sized ATTR_LIST is detected, the function returns -EINVAL, preventing a DoS vulnerability.

---

LLM Generated explanations, may be completely bogus:

Now I have a comprehensive understanding. Let me write up the analysis.

## Analysis

### 1. Commit Message Analysis

The commit explicitly describes an **infinite loop bug** (DoS vulnerability) in the ntfs3 filesystem. A malformed NTFS image with a zero-sized ATTR_LIST attribute causes the mount operation to hang indefinitely, consuming a kernel thread. The commit message is detailed and explains the exact mechanism clearly.

### 2. Code Change Analysis

The fix adds **two simple zero-size validation checks** — one for resident and one for non-resident ATTR_LIST attributes:

- **Resident path** (line ~54): After reading lsize = le32_to_cpu(attr->res.data_size), if lsize == 0, return -EINVAL.
- **Non-resident path** (line ~71): After reading lsize = le64_to_cpu(attr->nres.data_size), if lsize == 0, return -EINVAL.

Both checks use the existing goto out error path and follow the existing error handling pattern.

### 3. Root Cause (Verified)

The subagent analysis confirmed the exact mechanism:

1. al_aligned(0) returns 1024 (not 0), so memory gets allocated even for zero-size data.
2. ni->attr_list.size is set to 0, but ni->attr_list.le becomes non- NULL.
3. ni_enum_attr_ex() in fs/ntfs3/frecord.c:259 checks if (!ni->attr_list.size) — this is true, so it only enumerates the primary MFT record.
4. Finding ATTR_LIST in the primary record triggers a reload via ntfs_load_attr_list(), which returns 0 early (size already set to 0 but le is allocated), creating an infinite loop.

### 4. Stable Criteria Assessment

| Criterion | Assessment |
|-----------|-----------|
| Obviously correct | **YES** — A zero-sized attribute list is invalid;
rejecting it with -EINVAL is the right thing to do |
| Fixes a real bug | **YES** — Infinite loop / kernel hang on mount
(DoS) |
| Important issue | **YES** — DoS vulnerability from crafted filesystem
image |
| Small and contained | **YES** — Only adds 8 lines (two 4-line checks)
in a single file |
| No new features | **YES** — Pure input validation |
| Applies cleanly | **Likely** — The surrounding code has been stable;
minor context changes from kvmalloc/kvfree patches may need checking |

### 5. Risk Assessment

- **Risk: VERY LOW** — Two simple if (!lsize) checks that return an error. Cannot introduce regressions because a zero-sized ATTR_LIST is inherently invalid on a well-formed NTFS volume.
- **Benefit: HIGH** — Prevents a kernel hang (DoS) from a crafted NTFS image. This is security-relevant as NTFS images can come from untrusted sources (USB drives, network shares, etc.).

### 6. Affected Versions

The ntfs3 driver was introduced in v5.15 (commit be71b5cba2e6). The vulnerable ntfs_load_attr_list() function has existed since the driver's introduction. All stable trees with ntfs3 (5.15.y, 6.1.y, 6.6.y, 6.12.y) are affected.

### 7. Dependencies

The fix is self-contained — no dependencies on other patches. It uses only existing error handling patterns (goto out with err = -EINVAL).

### Verification

- **git log** confirmed attrlist.c has been in the tree since commit be71b5cba2e6 ("fs/ntfs3: Add attrib operations")
- **git merge-base** verified ntfs3 is present in v5.15, confirming all current stable trees are affected
- **Subagent analysis** of al_aligned() in fs/ntfs3/ntfs_fs.h:484-487 confirmed al_aligned(0) returns 1024
- **Subagent analysis** of ni_enum_attr_ex() in fs/ntfs3/frecord.c:259 confirmed the infinite loop mechanism via the .size == 0 check
- **Subagent analysis** of ntfs_load_attr_list() callers confirmed it's called from fs/ntfs3/inode.c:187-192 during inode loading
- **git show 06909b2549d63** confirmed the commit exists and matches the described fix
- The claim that this is a DoS vulnerability is verified by the code analysis showing the infinite loop mechanism

This is a textbook stable backport candidate: a small, surgical fix for a DoS vulnerability (infinite loop / kernel hang) triggered by a malformed filesystem image, with zero risk of regression.

**YES**

 fs/ntfs3/attrlist.c | 9 +++++++++
 1 file changed, 9 insertions(+)

index a4d74bed74fab..098bd7e8c3d64 100644
@@ -52,6 +52,11 @@ int ntfs_load_attr_list(struct ntfs_inode *ni, struct ATTRIB *attr)
 
 	if (!attr->non_res) {
 		lsize = le32_to_cpu(attr->res.data_size);
+		if (!lsize) {
+			err = -EINVAL;
+			goto out;
+		}
+
 		/* attr is resident: lsize < record_size (1K or 4K) */
 		le = kvmalloc(al_aligned(lsize), GFP_KERNEL);
 		if (!le) {

@@ -66,6 +71,10 @@ int ntfs_load_attr_list(struct ntfs_inode *ni, struct ATTRIB *attr)
 		u16 run_off = le16_to_cpu(attr->nres.run_off);
 
 		lsize = le64_to_cpu(attr->nres.data_size);
+		if (!lsize) {
+			err = -EINVAL;
+			goto out;
+		}
 
 		run_init(&ni->attr_list.run);
 

2.51.0

From: Kaushlendra Kumar <[email protected]>

[ Upstream commit 15176b818e048ccf6ef4b96db34eda7b7e98938a ]

When DLVR sysfs group creation fails in proc_thermal_rfim_add(), the function returns immediately without cleaning up the FIVR group that may have been created earlier.

Add proper error unwinding to remove the FIVR group before returning failure.

---

LLM Generated explanations, may be completely bogus:

Now I have a complete understanding of the code. Let me do a final check on the existing error handling in the DVFS section, which already had cleanup for FIVR and DLVR (but note: the DVFS section also has a bug - it returns after removing FIVR but doesn't also remove DLVR, and vice versa. However, that's a separate issue).

## Analysis

### 1. Commit Message Analysis
The commit message clearly describes a **resource leak bug fix**: when DLVR sysfs group creation fails, the previously created FIVR sysfs group is not cleaned up. The fix adds proper error unwinding.

### 2. Code Change Analysis
The bug is straightforward and real:

In proc_thermal_rfim_add():
1. First, the FIVR sysfs group is created (line 447)
2. Then, the DLVR sysfs group is created (line 468)
3. If the DLVR creation fails (line 469), the code returns immediately **without** removing the FIVR group

The fix adds a conditional cleanup: if FIVR was created (checked via PROC_THERMAL_FEATURE_FIVR mask) and DLVR creation fails, remove the FIVR group before returning the error.

Interestingly, the DVFS section (lines 473-482) already had similar cleanup logic (removing both FIVR and DLVR on DVFS failure), showing the author's intent was always to have proper unwinding. The DLVR section was simply missing the same pattern.

### 3. Classification
- **Bug type**: Resource leak (sysfs group leak on error path)
- **Severity**: Low-to-medium. A leaked sysfs group during probe failure could lead to:
- Stale sysfs entries
- Issues on subsequent probe attempts
- Resource leak
- **Fix correctness**: Obviously correct. The pattern matches what's already done in the DVFS error handling section of the same function.

### 4. Scope and Risk Assessment
- **Change size**: +3 lines changed (adding cleanup in one error path)
- **Files touched**: 1 file
- **Risk**: Very low. The fix only adds cleanup that mirrors existing patterns in the same function.
- **Regression potential**: Extremely low - removing a sysfs group that was just created in a failure path cannot break anything.

### 5. Stable Kernel Rules Compliance
- **Obviously correct**: Yes, the pattern is identical to existing cleanup in the DVFS section
- **Fixes a real bug**: Yes, a sysfs group resource leak on error path
- **Small and contained**: Yes, 3 lines in 1 file
- **No new features**: Correct, pure bug fix
- **Tested**: Acked by the subsystem maintainer (Srinivas Pandruvada)

### 6. Affected Versions
The DLVR feature was introduced in commit 5bc6b1df65c87 (v6.4..v6.5 cycle), so this bug affects kernels v6.5 and later. Current stable trees that would need this: 6.6.y, 6.12.y (and possibly others depending on active stable branches).

### Verification
- git log --oneline on the file confirmed commit history and that the fix is 15176b818e048
- git show 5bc6b1df65c87 confirmed DLVR support was added in the v6.4→v6.5 window, introducing the buggy error path
- Read of processor_thermal_rfim.c lines 442-486 confirmed the pre-fix
code: DLVR error path at line 469-470 returns without FIVR cleanup
- Read confirmed DVFS section (lines 473-482) already had the cleanup pattern the DLVR section was missing
- git tag --contains 5bc6b1df65c87 confirmed affected versions start at v6.5 era
- Commit is Acked-by Srinivas Pandruvada (Intel thermal subsystem maintainer), confirming correctness

### Conclusion
This is a textbook stable backport candidate: a small, obvious resource leak fix on an error path, with minimal risk, acked by the subsystem maintainer, and following an existing pattern in the same function. It affects Intel thermal driver users on platforms with both FIVR and DLVR features when DLVR probe fails.

**YES**

 .../thermal/intel/int340x_thermal/processor_thermal_rfim.c   | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

index 589a3a71f0c4c..ba88d878c998d 100644
@@ -466,8 +466,11 @@ int proc_thermal_rfim_add(struct pci_dev *pdev, struct proc_thermal_device *proc
 			break;
 		}
 		ret = sysfs_create_group(&pdev->dev.kobj, &dlvr_attribute_group);
-		if (ret)
+		if (ret) {
+			if (proc_priv->mmio_feature_mask & PROC_THERMAL_FEATURE_FIVR)
+				sysfs_remove_group(&pdev->dev.kobj, &fivr_attribute_group);
 			return ret;
+		}
 	}
 
 	if (proc_priv->mmio_feature_mask & PROC_THERMAL_FEATURE_DVFS) {

2.51.0

From: Jaehun Gou <[email protected]>

[ Upstream commit 1732053c8a6b360e2d5afb1b34fe9779398b072c ]

We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition.

A malformed dentry in the ntfs3 filesystem can cause the kernel to hang during the lookup operations. By setting the HAS_SUB_NODE flag in an INDEX_ENTRY within a directory's INDEX_ALLOCATION block and manipulating the VCN pointer, an attacker can cause the indx_find() function to repeatedly read the same block, allocating 4 KB of memory each time. The kernel lacks VCN loop detection and depth limits, causing memory exhaustion and an OOM crash.

This patch adds a return value check for fnd_push() to prevent a memory exhaustion vulnerability caused by infinite loops. When the index exceeds the size of the fnd->nodes array, fnd_push() returns -EINVAL. The indx_find() function checks this return value and stops processing, preventing further memory allocation.

---

LLM Generated explanations, may be completely bogus:

This is the original ntfs3 driver introduction commit (v5.15-rc1 era). The bug has been present since ntfs3 was first added.

Now let me verify what happens when fnd_push fails but its return value is ignored:

When fnd_push returns -EINVAL (because fnd->level >= ARRAY_SIZE(fnd->nodes), i.e., >= 20), the current code at line 1193 ignores this return value. The loop continues iterating:
1. fnd_push fails — the node is NOT added to the fnd->nodes array, so fnd->level stays at 20
2. The loop continues, reading more index blocks via indx_read, allocating memory each time
3. Since the node isn't tracked in fnd->nodes, it's never freed (memory leak)
4. A crafted filesystem with circular VCN references will cause an infinite loop, each iteration allocating 4KB, leading to OOM

This is a clear DoS vulnerability via crafted filesystem.

## Analysis

### 1. COMMIT MESSAGE ANALYSIS
- **Clear bug description**: Infinite loop in ntfs3 leading to DoS / OOM crash
- **Attack vector**: Malformed NTFS filesystem image with manipulated VCN pointers and HAS_SUB_NODE flag
- **Mechanism**: fnd_push() return value is ignored; when array is full, the node is leaked and the loop continues infinitely
- **Severity**: DoS / memory exhaustion / OOM kill — this is a security- relevant bug

### 2. CODE CHANGE ANALYSIS
The fix is minimal and surgical:
- Changes fnd_push(fnd, node, e); to err = fnd_push(fnd, node, e);
- Adds error checking: if fnd_push fails, properly cleans up (put_indx_node(node)) and returns the error
- Only 5 lines of new code added (plus removal of 1 line)
- No functional changes beyond the error handling

### 3. CLASSIFICATION
- **Bug fix**: Yes — fixes an infinite loop / memory exhaustion vulnerability
- **Security**: Yes — DoS via crafted filesystem (mountable by unprivileged user in many configs, e.g., USB automount)
- **Stable criteria met**: Obviously correct, fixes a real bug, small and contained, no new features

### 4. SCOPE AND RISK
- **Lines changed**: ~6 lines net
- **Files changed**: 1 (fs/ntfs3/index.c)
- **Risk**: Extremely low — the only behavioral change is that an already-defined error path is now properly taken instead of being silently ignored
- **Could break something**: No — fnd_push already returned an error; it was just ignored. Now that error propagates correctly.

### 5. USER IMPACT
- Affects any system that can mount NTFS filesystems (common for USB drives, dual-boot systems)
- A crafted USB drive could trigger OOM on any system with ntfs3 enabled
- Impact: System hang / OOM kill — HIGH severity

### 6. STABILITY
- Signed off by the ntfs3 maintainer (Konstantin Komarov)
- The fix pattern (check return value, propagate error) is a well- understood and safe pattern

### 7. DEPENDENCY CHECK
- fnd_push() already returns int with proper bounds checking since it was introduced
- The fix only adds the return value check in the caller — no dependencies on other commits
- The affected code (indx_find and fnd_push) has been present since ntfs3 was first merged (commit 82cae269cfa95, v5.15-rc1)
- This fix applies cleanly to all stable trees that have ntfs3 (5.15+)

### Verification

- **git blame** confirmed the vulnerable code at line 1193 has been present since commit 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") — the original ntfs3 introduction
- **Read of fnd_push()** at lines 673-684 confirms it already returns -EINVAL when i >= ARRAY_SIZE(fnd->nodes) (which is 20), verifying the commit message's claim
- **Read of struct ntfs_fnd** (from agent exploration) confirms nodes[20] — hardcoded array of 20 entries, so the depth limit is real
- **Current code at lines 1173-1198** confirms fnd_push return value is currently ignored on line 1193 (the bug)
- **git log history** shows no prior fix for this specific issue (no fnd_push return value check commits found)

This is a textbook stable backport candidate: a small, obviously correct fix for a security-relevant DoS vulnerability in a filesystem accessible from user space, present in all stable trees with ntfs3 support.

**YES**

 fs/ntfs3/index.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

index 7157cfd70fdcb..75b94beac1613 100644
@@ -1190,7 +1190,12 @@ int indx_find(struct ntfs_index *indx, struct ntfs_inode *ni,
 			return -EINVAL;
 		}
 
-		fnd_push(fnd, node, e);
+		err = fnd_push(fnd, node, e);
+
+		if (err) {
+			put_indx_node(node);
+			return err;
+		}
 	}
 
 	*entry = e;

2.51.0

From: Yauhen Kharuzhy <[email protected]>

[ Upstream commit a8c975302868c716afef0f50467bebbd069a35b8 ]

The PWM2 on YB1-X90 tablets is used for keyboard backlight control but it is disabled in the ACPI DSDT table. Add it to the override_status_ids list to allow keyboard function control driver (drivers/platform/x86/lenovo/yogabook.c) to use it.

---

LLM Generated explanations, may be completely bogus:

Now I have a comprehensive picture. Let me analyze this commit.

## Analysis

### 1. Commit Message Analysis

The commit adds an entry to the override_status_ids list in drivers/acpi/x86/utils.c to force-enable the PWM2 ACPI device on Lenovo Yoga Book YB1-X90 tablets. The PWM2 is used for keyboard backlight control but is disabled in the ACPI DSDT table. Without this override, the yogabook platform driver cannot control the keyboard backlight.

### 2. Code Change Analysis

The change is a straightforward addition of a PRESENT_ENTRY_HID entry to the existing quirk table. It:
- Targets HID "80862289" (Intel Cherry Trail PWM), UID "2" (PWM2 specifically)
- Scopes to INTEL_ATOM_AIRMONT CPU platform (Cherry Trail)
- Narrows with 3 DMI_EXACT_MATCH entries specific to the Yoga Book Android variant (YETI-11)
- This is the exact same pattern as the existing Xiaomi Mi Pad 2 entry (lines 78-82) which also enables PWM2 for touchkey backlight control

The change is ~12 lines including the comment. It follows an established, well-understood pattern that's been used in this file for years.

### 3. Classification: Hardware Quirk

This is a **hardware quirk/workaround** — one of the explicitly allowed exception categories for stable backports. The device has broken ACPI firmware (DSDT disables a needed device), and this quirk works around it by forcing the device present.

### 4. Scope and Risk Assessment

- **Very small change**: ~12 lines added to a data table
- **Zero risk to other hardware**: The DMI_EXACT_MATCH conditions ensure this only triggers on the exact Lenovo Yoga Book YB1-X90 (YETI-11 variant)
- **Well-tested pattern**: Identical to the Xiaomi Mi Pad 2 entry that's been in the kernel since v4.18
- **No code logic changes**: Only adds data to an existing table

### 5. Dependencies

The change depends on:
- The override_status_ids mechanism — present since at least v4.x
- The yogabook platform driver (drivers/platform/x86/lenovo/yogabook.c) — added in v6.6 via commit 6df1523fa0b79
- The keyboard backlight support in the platform driver — added in v6.6 via commit fc4f1d88bc6b1

The prerequisite code exists in all current stable trees (6.6+). The file path changed recently (moved to lenovo/ subdirectory in commit 651b57dd40871), so older stable trees may need minor context adjustment, but the data-table addition itself is trivially portable.

### 6. User Impact

Without this quirk, the keyboard backlight on Lenovo Yoga Book YB1-X90 tablets doesn't work under Linux. This is a real hardware enablement issue for a specific consumer tablet.

### 7. Stable Suitability

- **Obviously correct**: Follows the exact same pattern as existing entries
- **Fixes a real issue**: Keyboard backlight doesn't work without it
- **Small and contained**: Data-only addition to a quirk table
- **No new features**: Enables existing functionality on specific hardware
- **No new APIs**: Pure internal quirk

### Verification

- Verified fc4f1d88bc6b1 (keyboard backlight platform driver) is in v6.6 via git merge-base --is-ancestor
- Verified 6df1523fa0b79 (platform driver support) is in v6.6 via git merge-base --is-ancestor
- Verified 1a1e7540cf501 (ACPI quirk for i2c clients) is in v6.6 via git merge-base --is-ancestor
- Verified the existing Xiaomi Mi Pad 2 PWM2 entry (b72cd8e0fa34d) is in v6.6 via git merge-base --is-ancestor, confirming the infrastructure exists
- Read drivers/acpi/x86/utils.c lines 55-104 to confirm the existing code structure and similar entries
- Confirmed via git log that the commit a8c975302868c exists and matches the described change
- The agent exploration confirmed the yogabook platform driver at drivers/platform/x86/lenovo/yogabook.c uses devm_pwm_get(dev, "pwm_soc_lpss_2") at line 488, which is the PWM2 device being enabled by this quirk

This is a textbook hardware quirk addition — small, safe, DMI-scoped to one specific device, follows an established pattern, and enables real hardware functionality for users. It meets all stable kernel criteria.

**YES**

 drivers/acpi/x86/utils.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

index 4ee30c2897a2b..418951639f511 100644
@@ -81,6 +81,18 @@ static const struct override_status_id override_status_ids[] = {
 		DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"),
 	      }),
 
+	/*
+	 * Lenovo Yoga Book uses PWM2 for touch keyboard backlight control.
+	 * It needs to be enabled only for the Android device version (YB1-X90*
+	 * aka YETI-11); the Windows version (YB1-X91*) uses ACPI control
+	 * methods.
+	 */
+	PRESENT_ENTRY_HID("80862289", "2", INTEL_ATOM_AIRMONT, {
+		DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+		DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+		DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+	      }),
+
 	/*
 	 * The INT0002 device is necessary to clear wakeup interrupt sources
 	 * on Cherry Trail devices, without it we get nobody cared IRQ msgs.

2.51.0

From: Konstantin Komarov <[email protected]>

[ Upstream commit c5226b96c08a010ebef5fdf4c90572bcd89e4299 ]

When ntfs_read_run_nb_ra() is invoked with run == NULL the code later assumes run is valid and may call run_get_entry(NULL, ...), and also uses clen/idx without initializing them. Smatch reported uninitialized variable warnings and this can lead to undefined behaviour. This patch fixes it.

---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a thorough analysis.

## Analysis

### 1. Commit Message Analysis

The commit clearly describes a bug fix: when ntfs_read_run_nb() (renamed to ntfs_read_run_nb_ra() in the commit being analyzed) is invoked with run == NULL, the code can later call run_get_entry(NULL, ...) and use uninitialized variables clen and idx. This was reported by the kernel test robot and Dan Carpenter (a well-known static analysis expert using Smatch).

### 2. Code Change Analysis

**The bug mechanism:**

At fs/ntfs3/fsntfs.c:1186-1207, when run == NULL, the function uses the absolute boot MFT location:
- lbo and len are set from boot info (lines 1194-1195)
- **But clen, idx, and vcn are NOT initialized** — they are only set via run_lookup_entry() on the run != NULL path (line 1196)

The function then enters a for(;;) loop (line 1215) containing an inner do { } while (len32) loop. If the requested bytes exceeds the initial len (i.e., the read spans more than one record), the inner loop completes, and execution falls through to line 1255 where:

1. vcn_next = vcn + clen; — **uses uninitialized clen** (undefined behavior)
2. run_get_entry(run, ++idx, ...) — **dereferences NULL run** (crash at run->count in run.c:608)
3. ++idx — **uses uninitialized idx** (undefined behavior)

**What run_get_entry() does with NULL:**
Looking at fs/ntfs3/run.c:608, the very first thing it does is if (index >= run->count), which immediately dereferences the NULL pointer → **kernel oops/panic**.

**The fix:** Adds a simple if (!run) check before reaching the run_get_entry() call, returning -EINVAL and going to error cleanup. This is exactly 4 lines of code and is obviously correct — if we entered the loop via the run == NULL path and need another fragment, we can't get one, so returning an error is the right behavior.

### 3. Classification

This is a **bug fix** that prevents:
- NULL pointer dereference (crash/oops)
- Use of uninitialized variables (undefined behavior, potential data corruption)

### 4. Scope and Risk

- **Lines changed:** 4 lines of actual code added (NULL check + goto)
- **Files touched:** 1 (fs/ntfs3/fsntfs.c)
- **Risk:** Extremely low — adds a defensive check that can only trigger on an error path, returning -EINVAL which callers already handle
- **No behavioral change** for the normal case where run != NULL

### 5. User Impact

NTFS3 is used by anyone mounting NTFS filesystems on Linux (common for dual-boot systems, external drives). While the run == NULL path is specific to early MFT reading during mount, the uninitialized variable use means the code is technically invoking undefined behavior, which compilers can exploit in unexpected ways.

### 6. Stability Indicators

- Reported by kernel test robot and Dan Carpenter (Smatch static analysis) — two highly reputable sources
- The fix is authored by the NTFS3 maintainer (Konstantin Komarov)
- Extremely small and contained change

### 7. Dependency Check

The fix is self-contained — it just adds a NULL check. It applies to the existing ntfs_read_run_nb() function which has been in the kernel since NTFS3 was merged in v5.15.

## Verification

- **Read ntfs_read_run_nb() at fsntfs.c:1171-1282**: Confirmed clen, idx are only initialized via run_lookup_entry() on line 1196, which is skipped when run == NULL
- **Read run_get_entry() at run.c:603-623**: Confirmed line 608 immediately dereferences run->count, which would crash if run == NULL
- **Searched callers of ntfs_read_run_nb()**: Found 12 call sites; the run == NULL path is designed for early MFT reading (per comment at line 1187)
- **Checked oa->run1 initialization in fslog.c**: All paths through fake_attr (line 4749) and normal flow (line 4801) set oa->run1, so the fslog caller is unlikely to pass NULL — but the function's design explicitly handles run == NULL at its entry
- **Confirmed ntfs3 present since v5.15**: The filesystem was merged in Linux 5.15, present in all active stable trees
- **git log confirmed recent ntfs3 activity**: Active maintenance by the NTFS3 maintainer

This is a textbook stable backport candidate: small, surgical fix for a NULL pointer dereference and uninitialized variable use, authored by the subsystem maintainer, reported by trusted automated tools.

**YES**

 fs/ntfs3/fsntfs.c | 6 ++++++
 1 file changed, 6 insertions(+)

index 5f138f7158357..ac99c5613284a 100644
@@ -1252,6 +1252,12 @@ int ntfs_read_run_nb(struct ntfs_sb_info *sbi, const struct runs_tree *run,
 
 		} while (len32);
 
+		if (!run) {
+			err = -EINVAL;
+			goto out;
+		}
+
+		/* Get next fragment to read. */
 		vcn_next = vcn + clen;
 		if (!run_get_entry(run, ++idx, &vcn, &lcn, &clen) ||
 		    vcn != vcn_next) {

2.51.0

From: ethanwu <[email protected]>

[ Upstream commit 305ff6b3a03c230d3c07b61457e961406d979693 ]

The ceph_uninline_data function was missing proper snapshot context handling for its OSD write operations. Both CEPH_OSD_OP_CREATE and CEPH_OSD_OP_WRITE requests were passing NULL instead of the appropriate snapshot context, which could lead to unnecessary object clone.

Reproducer:
../src/vstart.sh --new -x --localhost --bluestore
// turn on cephfs inline data
./bin/ceph fs set a inline_data true --yes-i-really-really-mean-it
// allow fs_a client to take snapshot
./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a' // mount cephfs with fuse, since kernel cephfs doesn't support inline write
ceph-fuse --id fs_a -m 127.0.0.1:40318 --conf ceph.conf -d /mnt/mycephfs/
// bump snapshot seq
mkdir /mnt/mycephfs/.snap/snap1
echo "foo" > /mnt/mycephfs/test
// umount and mount it again using kernel cephfs client
umount /mnt/mycephfs
mount -t ceph [email protected]=/ /mnt/mycephfs/ -o conf=./ceph.conf
echo "bar" >> /mnt/mycephfs/test
./bin/rados listsnaps -p cephfs.a.data $(printf "%x\n" $(stat -c %i /mnt/mycephfs/test)).00000000

will see this object does unnecessary clone
1000000000a.00000000 (seq:2):

cloneid snaps   size    overlap
2       2       4       []
head    -       8

but it's expected to see
10000000000.00000000 (seq:2):
cloneid snaps size overlap
head - 8

since there's no snapshot between these 2 writes

clone happened because the first osd request CEPH_OSD_OP_CREATE doesn't pass snap context so object is created with snap seq 0, but later data writeback is equipped with snapshot context.
snap.seq(1) > object snap seq(0), so osd does object clone.

This fix properly acquiring the snapshot context before performing write operations.

---

LLM Generated explanations, may be completely bogus:

Now I have a comprehensive understanding. Let me also check the __ceph_mark_dirty_caps function which is where i_head_snapc normally gets populated:

The pattern at caps.c:1813-1817 shows the standard way i_head_snapc gets populated:

```c
if (!ci->i_head_snapc) {
    WARN_ON_ONCE(!rwsem_is_locked(&mdsc->snap_rwsem));
    ci->i_head_snapc = ceph_get_snap_context(
        ci->i_snap_realm->cached_context);
}
```

The fix in ceph_uninline_data() uses the same pattern, which confirms it's correct.

Now let me assess the overall analysis:

## Analysis

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly explains:
- **What**: ceph_uninline_data() passes NULL instead of proper snapshot context to OSD write operations
- **Why**: This causes unnecessary RADOS object clones when inline data is uninlined in the presence of snapshots
- **Reproducer**: A detailed step-by-step reproducer is provided
- **Impact**: Unnecessary object clones (storage waste, incorrect snapshot state)

The commit is reviewed and tested by Viacheslav Dubeyko (IBM) and signed off by Ilya Dryomov (CephFS maintainer).

### 2. CODE CHANGE ANALYSIS

The fix:
1. Adds snapshot context acquisition before OSD write operations (following the established pattern from __ceph_mark_dirty_caps and ceph_write_begin)
2. Passes snapc instead of NULL to both CEPH_OSD_OP_CREATE and CEPH_OSD_OP_WRITE requests
3. Properly releases the snapshot context reference with ceph_put_snap_context(snapc) in the cleanup path

The pattern of snapshot context acquisition is identical to what's used in other CephFS write paths (caps.c:1813-1817, caps.c:2779-2783).

### 3. CLASSIFICATION

This is a **bug fix** - it fixes incorrect behavior where OSD objects are created with snap_seq=0 instead of the proper snapshot sequence number, causing unnecessary clones.

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: ~20 lines added (very small)
- **Files touched**: 1 (fs/ceph/addr.c)
- **Pattern**: Well-established, used identically in multiple other write paths
- **Risk**: Low - the snap context acquisition pattern is battle-tested in the CephFS codebase
- **Self-contained**: Yes, no dependencies on other patches

### 5. USER IMPACT

- Affects CephFS users with inline data enabled and snapshots
- The bug causes unnecessary RADOS object clones, leading to:
- Wasted storage space
- Incorrect/unexpected snapshot state
- Could confuse backup/recovery tools that rely on snapshot state

### 6. STABILITY INDICATORS

- Reviewed-by and Tested-by from Viacheslav Dubeyko (IBM)
- Signed-off by CephFS maintainer Ilya Dryomov
- Detailed reproducer provided and verified

### 7. HISTORICAL CONTEXT

The bug was introduced in 2016 by commit 34b759b4a22b0 ("ceph: kill ceph_empty_snapc") which replaced ceph_empty_snapc with NULL, claiming equivalence. While this was true for message sizing, it meant the snap_seq sent to OSD became 0 instead of the proper value, causing the clone issue.

### Concerns

- The bug requires a specific (but documented) configuration: CephFS inline data + snapshots
- Inline data is a deprecated feature in CephFS, but still supported and used
- The unnecessary clones are a data correctness issue (wrong snapshot state) rather than a crash/security issue
- The fix is small, well-tested, and follows established patterns

### Verification

- Verified that commit 305ff6b3a03c2 exists and modifies only fs/ceph/addr.c
- Verified the snap context acquisition pattern matches caps.c:1813-1817 and caps.c:2779-2783 (identical pattern)
- Verified that NULL snapc causes snap_seq=0 to be encoded in OSD requests (osd_client.c:2198-2199)
- Verified that ceph_uninline_data() is called from ceph_open() when opening a file with inline data for writing (file.c:242-243)
- Verified the historical context: commit 7b06a826e7c52 (2015) changed to ceph_empty_snapc, then commit 34b759b4a22b0 (2016) changed to NULL, introducing the bug
- Verified the commit is reviewed by Viacheslav Dubeyko and signed off by Ilya Dryomov (CephFS maintainer)
- Verified the fix follows the standard lock ordering: snap_rwsem (read) → i_ceph_lock (spin)
- Could NOT verify whether inline_data feature is commonly used in production stable kernel environments (unverified)

### Decision

This commit fixes a real bug in CephFS snapshot handling that causes incorrect RADOS object clones (data correctness issue). The fix is small (~20 lines), self-contained, follows well-established patterns used throughout the CephFS codebase, and has been reviewed and tested. The bug has existed since 2016 and affects all stable kernels. While the trigger requires inline data + snapshots (a somewhat niche configuration), the fix is low-risk and addresses incorrect behavior.

**YES**

 fs/ceph/addr.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

index 63b75d2142102..faecd9025ee9c 100644
@@ -2199,6 +2199,7 @@ int ceph_uninline_data(struct file *file)
 	struct ceph_osd_request *req = NULL;
 	struct ceph_cap_flush *prealloc_cf = NULL;
 	struct folio *folio = NULL;
+	struct ceph_snap_context *snapc = NULL;
 	u64 inline_version = CEPH_INLINE_NONE;
 	struct page *pages[1];
 	int err = 0;

@@ -2226,6 +2227,24 @@ int ceph_uninline_data(struct file *file)
 	if (inline_version == 1) /* initial version, no data */
 		goto out_uninline;
 
+	down_read(&fsc->mdsc->snap_rwsem);
+	spin_lock(&ci->i_ceph_lock);
+	if (__ceph_have_pending_cap_snap(ci)) {
+		struct ceph_cap_snap *capsnap =
+				list_last_entry(&ci->i_cap_snaps,
+						struct ceph_cap_snap,
+						ci_item);
+		snapc = ceph_get_snap_context(capsnap->context);
+	} else {
+		if (!ci->i_head_snapc) {
+			ci->i_head_snapc = ceph_get_snap_context(
+				ci->i_snap_realm->cached_context);
+		}
+		snapc = ceph_get_snap_context(ci->i_head_snapc);
+	}
+	spin_unlock(&ci->i_ceph_lock);
+	up_read(&fsc->mdsc->snap_rwsem);
+
 	folio = read_mapping_folio(inode->i_mapping, 0, file);
 	if (IS_ERR(folio)) {
 		err = PTR_ERR(folio);

@@ -2241,7 +2260,7 @@ int ceph_uninline_data(struct file *file)
 	req = ceph_osdc_new_request(&fsc->client->osdc, &ci->i_layout,
 				    ceph_vino(inode), 0, &len, 0, 1,
 				    CEPH_OSD_OP_CREATE, CEPH_OSD_FLAG_WRITE,
-				    NULL, 0, 0, false);
+				    snapc, 0, 0, false);
 	if (IS_ERR(req)) {
 		err = PTR_ERR(req);
 		goto out_unlock;

@@ -2257,7 +2276,7 @@ int ceph_uninline_data(struct file *file)
 	req = ceph_osdc_new_request(&fsc->client->osdc, &ci->i_layout,
 				    ceph_vino(inode), 0, &len, 1, 3,
 				    CEPH_OSD_OP_WRITE, CEPH_OSD_FLAG_WRITE,
-				    NULL, ci->i_truncate_seq,
+				    snapc, ci->i_truncate_seq,
 				    ci->i_truncate_size, false);
 	if (IS_ERR(req)) {
 		err = PTR_ERR(req);

@@ -2320,6 +2339,7 @@ int ceph_uninline_data(struct file *file)
 		folio_put(folio);
 	}
 out:
+	ceph_put_snap_context(snapc);
 	ceph_free_cap_flush(prealloc_cf);
 	doutc(cl, "%llx.%llx inline_version %llu = %d\n",
 	      ceph_vinop(inode), inline_version, err);

2.51.0

From: Konstantin Komarov <[email protected]>

[ Upstream commit 576248a34b927e93b2fd3fff7df735ba73ad7d01 ]

If attr_set_size() fails while truncating down, the error is silently ignored and the inode may be left in an inconsistent state.

---

LLM Generated explanations, may be completely bogus:

Now I have a clear picture of the bug. Let me analyze it:

## Analysis

### 1. COMMIT MESSAGE ANALYSIS

The commit message is clear: "handle attr_set_size() errors when truncating files." It states that if attr_set_size() fails while truncating down, the error is silently ignored and the inode may be left in an inconsistent state. The author is Konstantin Komarov, the NTFS3 maintainer.

### 2. CODE CHANGE ANALYSIS

**The bug:** In the original ntfs_truncate() function (line 504-554 of fs/ntfs3/file.c), attr_set_size() is called at line 531-533 and its return value is stored in err. However, after ni_unlock(ni), the code does **not** check err — it proceeds to modify the inode metadata (setting FILE_ATTRIBUTE_ARCHIVE, updating timestamps) and then either:
- Sets dirty = 1 and later calls mark_inode_dirty(), OR
- Calls ntfs_sync_inode() which **overwrites** err (line 545-546)

In both paths, the original error from attr_set_size() is lost. The function returns 0 (line 554) even when the underlying attribute size change failed.

**The fix adds** (after line 539, after ni_unlock(ni)):

```c
if (unlikely(err))
    return err;
```

This ensures that if attr_set_size() failed, the error is propagated to the caller immediately, before marking the inode dirty with potentially inconsistent metadata.

**Additional cleanup:** The dirty variable is removed and mark_inode_dirty() is called directly in the !IS_DIRSYNC branch, which is a trivial simplification.

### 3. IMPACT ASSESSMENT

**The caller** (ntfs_setattr at line 851) checks the return value of ntfs_truncate():

```c
err = ntfs_truncate(inode, newsize);
...
if (err)
    goto out;
```

So if attr_set_size() fails (e.g., due to disk I/O error, out of space, corrupted MFT records), the old code would:
1. Silently ignore the failure
2. Proceed to update inode metadata as if truncation succeeded
3. Return success to the VFS layer

This means the in-memory inode state (already updated by truncate_setsize()) could diverge from the on-disk NTFS attribute state, leading to **filesystem inconsistency**. The inode would think the file is the new size while the NTFS data attribute still has the old size.

This is a **data corruption** bug. On an NTFS filesystem, this could lead to:
- Stale data being visible after truncation
- Incorrect file sizes reported
- Further I/O errors when accessing the inconsistent inode

### 4. SCOPE AND RISK

- **2 lines of actual logic change** (the if (unlikely(err)) return err; check), plus trivial cleanup of the dirty variable
- Affects only the NTFS3 truncate path
- Very low risk of regression — it only changes behavior when attr_set_size() already failed
- The code has existed since the initial NTFS3 commit 4342306f0f0d5f (v5.15, 2021-08-13), so this bug affects all stable trees containing NTFS3

### 5. STABLE CRITERIA

- **Obviously correct**: The fix simply checks an already-captured error return value that was being silently ignored
- **Fixes a real bug**: Silently ignoring errors from attr_set_size() can lead to filesystem inconsistency
- **Important issue**: Filesystem data corruption/inconsistency
- **Small and contained**: ~5 lines changed, single file, single function
- **No new features**: Pure error handling fix

### Verification

- git blame confirmed the buggy code (missing error check after attr_set_size()) has been present since commit 4342306f0f0d5f (Konstantin Komarov, 2021-08-13), which is the initial NTFS3 import in v5.15
- Verified the caller ntfs_setattr at line 851 checks ntfs_truncate() return value — so propagating the error has meaningful effect
- Verified that line 554 (return 0) means the error is unconditionally discarded in the original code — confirmed by reading lines 539-554
- Verified attr_set_size() can return errors (e.g., -ENOENT at line 430, propagated errors from attr_set_size_res at line 437)
- Verified the dirty variable removal is safe — mark_inode_dirty() is now called directly in the !IS_DIRSYNC branch, which is functionally identical
- Could NOT verify whether this specific patch has been discussed on lore.kernel.org (not checked via WebFetch), but the author is the NTFS3 maintainer which provides confidence

This is a clear, small, obviously-correct error handling fix for a filesystem data consistency bug that has existed since NTFS3 was first introduced. It meets all stable kernel criteria.

**YES**

 fs/ntfs3/file.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

index 2e7b2e566ebe1..362396968ab69 100644
@@ -505,8 +505,8 @@ static int ntfs_truncate(struct inode *inode, loff_t new_size)
 {
 	struct super_block *sb = inode->i_sb;
 	struct ntfs_inode *ni = ntfs_i(inode);
-	int err, dirty = 0;
 	u64 new_valid;
+	int err;
 
 	if (!S_ISREG(inode->i_mode))
 		return 0;

@@ -522,7 +522,6 @@ static int ntfs_truncate(struct inode *inode, loff_t new_size)
 	}
 
 	new_valid = ntfs_up_block(sb, min_t(u64, ni->i_valid, new_size));
-
 	truncate_setsize(inode, new_size);
 
 	ni_lock(ni);

@@ -536,20 +535,19 @@ static int ntfs_truncate(struct inode *inode, loff_t new_size)
 		ni->i_valid = new_valid;
 
 	ni_unlock(ni);
+	if (unlikely(err))
+		return err;
 
 	ni->std_fa |= FILE_ATTRIBUTE_ARCHIVE;
 	inode_set_mtime_to_ts(inode, inode_set_ctime_current(inode));
 	if (!IS_DIRSYNC(inode)) {
-		dirty = 1;
+		mark_inode_dirty(inode);
 	} else {
 		err = ntfs_sync_inode(inode);
 		if (err)
 			return err;
 	}
 
-	if (dirty)
-		mark_inode_dirty(inode);
-
 	return 0;
 }
 

2.51.0

From: Szymon Wilczek <[email protected]>

[ Upstream commit 08ce2fee1b869ecbfbd94e0eb2630e52203a2e03 ]

Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock.

The deadlock scenario:
1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock.
2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone().

This creates an AB-BA deadlock.

Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock.

---

LLM Generated explanations, may be completely bogus:

The background task completed but I already have all the information I need from my analysis. My verdict stands as given above.

**YES**

 fs/ntfs3/run.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

index 395b204925258..dc59cad4fa376 100644
@@ -1131,11 +1131,14 @@ int run_unpack_ex(struct runs_tree *run, struct ntfs_sb_info *sbi, CLST ino,
 			struct rw_semaphore *lock =
 				is_mounted(sbi) ? &sbi->mft.ni->file.run_lock :
 						  NULL;
-			if (lock)
-				down_read(lock);
-			ntfs_refresh_zone(sbi);
-			if (lock)
-				up_read(lock);
+			if (lock) {
+				if (down_read_trylock(lock)) {
+					ntfs_refresh_zone(sbi);
+					up_read(lock);
+				}
+			} else {
+				ntfs_refresh_zone(sbi);
+			}
 		}
 		up_write(&wnd->rw_lock);
 		if (err)

2.51.0

From: Konstantin Komarov <[email protected]>

[ Upstream commit 3a6aba7f3cf2b46816e08548c254d98de9c74eba ]

Do not keep preallocated clusters for sparsed and compressed files. Preserving preallocation in these cases causes fsx failures when running with sparse files and preallocation enabled.

---

LLM Generated explanations, may be completely bogus:

Now I have a comprehensive understanding of the patch. Let me finalize my analysis.

## Analysis

### 1. Commit Message Analysis

The commit message is straightforward: "Do not keep preallocated clusters for sparsed and compressed files. Preserving preallocation in these cases causes fsx failures when running with sparse files and preallocation enabled."

The author is Konstantin Komarov, the ntfs3 maintainer. The commit explicitly mentions **fsx failures**, which are data correctness test failures from the filesystem exerciser tool in xfstests. fsx is one of the most important tools for detecting filesystem data corruption bugs.

### 2. Code Change Analysis

The change is minimal — adding one line (keep_prealloc = false;) inside an existing if (is_ext) block, and adding braces to accommodate the new statement:

```c
// Before:
if (is_ext)
    align <<= attr_b->nres.c_unit;

// After:
if (is_ext) {
    align <<= attr_b->nres.c_unit;
    keep_prealloc = false;
}
```

When keep_prealloc = true and new_size < old_size (truncation), the code at line 464-468 takes a shortcut: it only updates data_size without actually deallocating clusters. For sparse/compressed files, this behavior is incorrect because:
- Sparse files use implicit zero-filled ranges; keeping preallocated clusters creates an inconsistency between the on-disk layout and the NTFS sparse representation
- Compressed files have compression units that require precise cluster accounting
- The truncation path at line 694 ((new_alloc != old_alloc && !keep_prealloc)) also relies on keep_prealloc to decide whether to actually free clusters

### 3. Historical Context

This commit effectively partially reverts ce46ae0c3e31 ("fs/ntfs3:
Keep prealloc for all types of files", Oct 2021), which removed keep_prealloc = false for sparse/ext files to fix xfstest generic/274. However, keeping preallocation for these file types turned out to cause **fsx failures** — meaning data corruption or incorrect behavior detectable under stress testing. The current commit is a correction:
sparse/compressed files fundamentally should NOT keep preallocated space when truncating.

Note that the extension path (line 529-531) already has pre_alloc = 0 for is_ext files — so the codebase already disables preallocation for growth of sparse/compressed files. This commit makes the shrink path consistent with the growth path.

### 4. Scope and Risk Assessment

- **Lines changed**: 3 lines (adding braces + one line of logic)
- **Files changed**: 1 (fs/ntfs3/attrib.c)
- **Risk**: Very low — only affects sparse/compressed NTFS files being truncated with prealloc enabled
- **Regression potential**: Minimal. This restores behavior closer to the original design for sparse/compressed files

### 5. User Impact

- Affects users of ntfs3 filesystem with sparse or compressed files
- fsx failures indicate real data corruption/inconsistency that users could encounter
- While ntfs3 may not be as widely used as ext4/xfs, filesystem data corruption is a critical severity issue

### 6. Stable Kernel Criteria Assessment

- **Obviously correct**: Yes — one-line fix, consistent with existing behavior in the growth path
- **Fixes a real bug**: Yes — fsx failures indicate data corruption
- **Small and contained**: Yes — 3 lines in one file
- **No new features**: Correct — this only changes behavior of existing preallocation logic
- **Low risk**: Yes — only affects a specific NTFS file type combination

### Verification

- Read the current state of fs/ntfs3/attrib.c lines 449-468 — confirmed the code matches the diff context (pre-patch state)
- Verified commit ce46ae0c3e31 removed keep_prealloc = false for sparse/ext files in Oct 2021 — this commit re-adds it
- Verified the growth path at line 529-531 already has pre_alloc = 0 for is_ext — confirming sparse/compressed files already don't preallocate on extension
- Verified is_attr_ext() checks for ATTR_FLAG_SPARSED | ATTR_FLAG_COMPRESSED flags
- Checked lore.kernel.org — found the patch submission (Dec 26, 2025) with no NAK or negative reviewer feedback
- Confirmed the author is Konstantin Komarov, the ntfs3 maintainer
- Verified keep_prealloc logic at line 464-468: when true and shrinking, only updates data_size without deallocating — this is the problematic behavior for sparse/compressed files
- Could NOT verify exact fsx test case that fails (unverified, but fsx failures generally indicate real data corruption)

### Conclusion

This is a small, well-contained filesystem data correctness fix by the ntfs3 maintainer. It fixes fsx test failures (data corruption/inconsistency) for sparse and compressed files. The change is one line of logic, affects only ntfs3 sparse/compressed file truncation, and is consistent with existing preallocation behavior in the growth path. The risk is very low and the benefit is real — preventing data corruption in a filesystem.

**YES**

 fs/ntfs3/attrib.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

index c45880ab23912..0cd15a0983fee 100644
@@ -448,8 +448,10 @@ int attr_set_size(struct ntfs_inode *ni, enum ATTR_TYPE type,
 
 	is_ext = is_attr_ext(attr_b);
 	align = sbi->cluster_size;
-	if (is_ext)
+	if (is_ext) {
 		align <<= attr_b->nres.c_unit;
+		keep_prealloc = false;
+	}
 
 	old_valid = le64_to_cpu(attr_b->nres.valid_size);
 	old_size = le64_to_cpu(attr_b->nres.data_size);

2.51.0

From: Jaehun Gou <[email protected]>

[ Upstream commit 4b90f16e4bb5607fb35e7802eb67874038da4640 ]

We found an infinite loop bug in the ntfs3 file system that can lead to a Denial-of-Service (DoS) condition.

A malformed NTFS image can cause an infinite loop when an attribute header indicates an empty run list, while directory entries reference it as containing actual data. In NTFS, setting evcn=-1 with svcn=0 is a valid way to represent an empty run list, and run_unpack() correctly handles this by checking if evcn + 1 equals svcn and returning early without parsing any run data. However, this creates a problem when there is metadata inconsistency, where the attribute header claims to be empty (evcn=-1) but the caller expects to read actual data. When run_unpack() immediately returns success upon seeing this condition, it leaves the runs_tree uninitialized with run->runs as a NULL. The calling function attr_load_runs_range() assumes that a successful return means that the runs were loaded and sets clen to 0, expecting the next run_lookup_entry() call to succeed. Because runs_tree remains uninitialized, run_lookup_entry() continues to fail, and the loop increments vcn by zero (vcn += 0), leading to an infinite loop.

This patch adds a retry counter to detect when run_lookup_entry() fails consecutively after attr_load_runs_vcn(). If the run is still not found on the second attempt, it indicates corrupted metadata and returns -EINVAL, preventing the Denial-of-Service (DoS) vulnerability.

---

LLM Generated explanations, may be completely bogus:

This confirms the key detail: run_unpack() (called via run_unpack_ex()) at line 940-941 returns 0 (success) when evcn + 1 == svcn — the "empty run" condition. This means attr_load_runs_vcn() returns success even when no runs are actually loaded into the runs_tree.

Let me now verify the infinite loop mechanism more carefully:

1. attr_load_runs_range() enters the loop, run_lookup_entry() fails (returns false) because run->runs is NULL
2. attr_load_runs_vcn() is called, which calls run_unpack_ex() → run_unpack(), which returns 0 (success) for the empty run case without adding any entries
3. clen is set to 0
4. Loop iterates: vcn += clen → vcn += 0 — no progress
5. run_lookup_entry() fails again → infinite loop

The fix adds a retry counter. If run_lookup_entry() fails after attr_load_runs_vcn() has already been called once for the same VCN, it returns -EINVAL instead of looping forever.

## Analysis

### 1. COMMIT MESSAGE ANALYSIS
- **Subject**: Clearly states "fix infinite loop" — this is a bug fix
- **Body**: Excellent description of the root cause, trigger mechanism, and DoS impact
- **Impact**: Denial-of-Service via crafted NTFS image — security relevant
- **Tags**: Multiple Co-developed-by/Signed-off-by, signed by ntfs3 maintainer (Konstantin Komarov)

### 2. CODE CHANGE ANALYSIS
The patch is small and surgical (~20 lines changed in a single function):
- Adds a retry counter initialized to 0
- After attr_load_runs_vcn() succeeds but run_lookup_entry() still fails on the next iteration, returns -EINVAL
- Resets retry to 0 on successful lookup
- Changes return err to break for consistency with the new error path
- All changes are self-contained within attr_load_runs_range()

### 3. BUG CLASSIFICATION
- **Type**: Infinite loop / DoS from inconsistent metadata on malformed NTFS image
- **Trigger**: Mounting/reading a crafted NTFS image where attribute header claims empty run list (evcn=-1, svcn=0) but directory entries reference it as containing data
- **Severity**: HIGH — causes complete system hang (infinite loop in kernel)
- **Security**: This is a DoS vulnerability triggerable by mounting a malicious filesystem image (e.g., USB stick)

### 4. SCOPE AND RISK
- **Lines changed**: ~20, single function, single file
- **Risk**: Very low — only adds early termination for a detected inconsistency condition
- **Side effects**: None — the retry counter only triggers when metadata is already corrupt
- **Regression risk**: Minimal — legitimate NTFS images won't trigger the retry mechanism because run_lookup_entry() will succeed after loading runs

### 5. USER IMPACT
- Affects anyone who mounts NTFS volumes (very common: USB drives, dual- boot, data exchange)
- A malicious NTFS image on a USB drive could hang the kernel
- Multiple callers of attr_load_runs_range() are affected: xattr, index, frecord, WOF operations

### 6. STABLE CRITERIA
- **Obviously correct**: Yes — if loading runs succeeded but lookup still fails, metadata is corrupt
- **Fixes a real bug**: Yes — infinite loop / DoS
- **Small and contained**: Yes — ~20 lines in one function
- **No new features**: Correct — only adds error detection
- **Tested**: Signed by ntfs3 maintainer, merged to mainline

### Verification

- **Verified** the run_unpack() early return at line 940-941: if (evcn + 1 == svcn) return 0; — this is the empty run case that returns success without populating runs_tree
- **Verified** run_lookup_entry() at line 201: if (!run->runs) return false; — confirms it returns false when runs_tree is uninitialized
- **Verified** the infinite loop mechanism: vcn += clen with clen = 0 causes no progress, leading to infinite re-entry into the same lookup failure path
- **Verified** callers via grep: attr_load_runs_range is called from xattr.c:127, xattr.c:498, index.c:1080, frecord.c:2529, and attrib.c:1463 — multiple code paths are affected
- **Verified** the fix is self-contained: only changes attr_load_runs_range() in attrib.c, no dependencies on other commits
- **Verified** via git log that this code has been present in ntfs3 since its inclusion (the function structure is unchanged), meaning all stable trees with ntfs3 are affected
- **Could not verify** specific CVE assignment (none mentioned in commit), but the DoS nature makes it security-relevant regardless

This is a textbook stable backport candidate: a small, surgical fix for a DoS-triggering infinite loop in a filesystem driver, caused by inconsistent metadata on crafted images. The fix is obviously correct, contained, low-risk, and signed off by the subsystem maintainer.

**YES**

 fs/ntfs3/attrib.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

index 980ae9157248d..c45880ab23912 100644
@@ -1354,19 +1354,28 @@ int attr_load_runs_range(struct ntfs_inode *ni, enum ATTR_TYPE type,
 	CLST vcn;
 	CLST vcn_last = (to - 1) >> cluster_bits;
 	CLST lcn, clen;
-	int err;
+	int err = 0;
+	int retry = 0;
 
 	for (vcn = from >> cluster_bits; vcn <= vcn_last; vcn += clen) {
 		if (!run_lookup_entry(run, vcn, &lcn, &clen, NULL)) {
+			if (retry != 0) { /* Next run_lookup_entry(vcn) also failed. */
+				err = -EINVAL;
+				break;
+			}
 			err = attr_load_runs_vcn(ni, type, name, name_len, run,
 						 vcn);
 			if (err)
-				return err;
+				break;
+
 			clen = 0; /* Next run_lookup_entry(vcn) must be success. */
+			retry++;
 		}
+		else
+			retry = 0;
 	}
 
-	return 0;
+	return err;
 }
 
 #ifdef CONFIG_NTFS3_LZX_XPRESS

2.51.0