* [PATCH AUTOSEL 6.19-5.15] fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
@ 2026-02-20 12:37 ` Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.6] thermal: int340x: Fix sysfs group leak on DLVR registration failure Sasha Levin
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:37 UTC (permalink / raw)
To: patches, stable
Cc: Jaehun Gou, Seunghun Han, Jihoon Kwon, Konstantin Komarov,
Sasha Levin, ntfs3, linux-kernel
From: Jaehun Gou <p22gone@gmail.com>
[ 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.
Co-developed-by: Seunghun Han <kkamagui@gmail.com>
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
Co-developed-by: Jihoon Kwon <kjh010315@gmail.com>
Signed-off-by: Jihoon Kwon <kjh010315@gmail.com>
Signed-off-by: Jaehun Gou <p22gone@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
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(+)
diff --git a/fs/ntfs3/attrlist.c b/fs/ntfs3/attrlist.c
index a4d74bed74fab..098bd7e8c3d64 100644
--- a/fs/ntfs3/attrlist.c
+++ b/fs/ntfs3/attrlist.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH AUTOSEL 6.19-6.6] thermal: int340x: Fix sysfs group leak on DLVR registration failure
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-5.15] fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST Sasha Levin
@ 2026-02-20 12:37 ` Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-5.15] fs: ntfs3: check return value of indx_find to avoid infinite loop Sasha Levin
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:37 UTC (permalink / raw)
To: patches, stable
Cc: Kaushlendra Kumar, Srinivas Pandruvada, Rafael J. Wysocki,
Sasha Levin, rafael, daniel.lezcano, linux-pm, linux-kernel
From: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
[ 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.
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://patch.msgid.link/LV3PR11MB876881B77D32A2854AD2908EF563A@LV3PR11MB8768.namprd11.prod.outlook.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
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(-)
diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c b/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c
index 589a3a71f0c4c..ba88d878c998d 100644
--- a/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c
+++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_rfim.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH AUTOSEL 6.19-5.15] fs: ntfs3: check return value of indx_find to avoid infinite loop
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-5.15] fs: ntfs3: fix infinite loop triggered by zero-sized ATTR_LIST Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.6] thermal: int340x: Fix sysfs group leak on DLVR registration failure Sasha Levin
@ 2026-02-20 12:37 ` Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.12] ACPI: x86: Force enabling of PWM2 on the Yogabook YB1-X90 Sasha Levin
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:37 UTC (permalink / raw)
To: patches, stable
Cc: Jaehun Gou, Seunghun Han, Jihoon Kwon, Konstantin Komarov,
Sasha Levin, ntfs3, linux-kernel
From: Jaehun Gou <p22gone@gmail.com>
[ 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.
Co-developed-by: Seunghun Han <kkamagui@gmail.com>
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
Co-developed-by: Jihoon Kwon <kjh010315@gmail.com>
Signed-off-by: Jihoon Kwon <kjh010315@gmail.com>
Signed-off-by: Jaehun Gou <p22gone@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
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(-)
diff --git a/fs/ntfs3/index.c b/fs/ntfs3/index.c
index 7157cfd70fdcb..75b94beac1613 100644
--- a/fs/ntfs3/index.c
+++ b/fs/ntfs3/index.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH AUTOSEL 6.19-6.12] ACPI: x86: Force enabling of PWM2 on the Yogabook YB1-X90
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
` (2 preceding siblings ...)
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-5.15] fs: ntfs3: check return value of indx_find to avoid infinite loop Sasha Levin
@ 2026-02-20 12:37 ` Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-5.15] fs/ntfs3: avoid calling run_get_entry() when run == NULL in ntfs_read_run_nb_ra() Sasha Levin
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:37 UTC (permalink / raw)
To: patches, stable
Cc: Yauhen Kharuzhy, Rafael J. Wysocki, Sasha Levin, rafael,
linux-acpi, linux-kernel
From: Yauhen Kharuzhy <jekhor@gmail.com>
[ 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.
Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
Link: https://patch.msgid.link/20260211222242.4101162-1-jekhor@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
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(+)
diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c
index 4ee30c2897a2b..418951639f511 100644
--- a/drivers/acpi/x86/utils.c
+++ b/drivers/acpi/x86/utils.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH AUTOSEL 6.19-5.15] fs/ntfs3: avoid calling run_get_entry() when run == NULL in ntfs_read_run_nb_ra()
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
` (3 preceding siblings ...)
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.12] ACPI: x86: Force enabling of PWM2 on the Yogabook YB1-X90 Sasha Levin
@ 2026-02-20 12:37 ` Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.1] ceph: supply snapshot context in ceph_uninline_data() Sasha Levin
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:37 UTC (permalink / raw)
To: patches, stable
Cc: Konstantin Komarov, kernel test robot, Dan Carpenter, Sasha Levin,
ntfs3, linux-kernel
From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
[ 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.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202512230646.v5hrYXL0-lkp@intel.com/
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
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(+)
diff --git a/fs/ntfs3/fsntfs.c b/fs/ntfs3/fsntfs.c
index 5f138f7158357..ac99c5613284a 100644
--- a/fs/ntfs3/fsntfs.c
+++ b/fs/ntfs3/fsntfs.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH AUTOSEL 6.19-6.1] ceph: supply snapshot context in ceph_uninline_data()
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
` (4 preceding siblings ...)
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-5.15] fs/ntfs3: avoid calling run_get_entry() when run == NULL in ntfs_read_run_nb_ra() Sasha Levin
@ 2026-02-20 12:37 ` Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19] fs/ntfs3: handle attr_set_size() errors when truncating files Sasha Levin
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:37 UTC (permalink / raw)
To: patches, stable
Cc: ethanwu, Viacheslav Dubeyko, Ilya Dryomov, Sasha Levin, amarkuze,
slava, ceph-devel, linux-kernel
From: ethanwu <ethanwu@synology.com>
[ 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 fs_a@.a=/ /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.
Signed-off-by: ethanwu <ethanwu@synology.com>
Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
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(-)
diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index 63b75d2142102..faecd9025ee9c 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH AUTOSEL 6.19] fs/ntfs3: handle attr_set_size() errors when truncating files
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
` (5 preceding siblings ...)
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.1] ceph: supply snapshot context in ceph_uninline_data() Sasha Levin
@ 2026-02-20 12:37 ` Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.18] ntfs3: fix circular locking dependency in run_unpack_ex Sasha Levin
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:37 UTC (permalink / raw)
To: patches, stable; +Cc: Konstantin Komarov, Sasha Levin, ntfs3, linux-kernel
From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
[ 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.
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
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(-)
diff --git a/fs/ntfs3/file.c b/fs/ntfs3/file.c
index 2e7b2e566ebe1..362396968ab69 100644
--- a/fs/ntfs3/file.c
+++ b/fs/ntfs3/file.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH AUTOSEL 6.19-6.18] ntfs3: fix circular locking dependency in run_unpack_ex
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
` (6 preceding siblings ...)
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19] fs/ntfs3: handle attr_set_size() errors when truncating files Sasha Levin
@ 2026-02-20 12:37 ` Sasha Levin
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.1] fs/ntfs3: drop preallocated clusters for sparse and compressed files Sasha Levin
2026-02-20 12:38 ` [PATCH AUTOSEL 6.19-5.15] fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata Sasha Levin
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:37 UTC (permalink / raw)
To: patches, stable
Cc: Szymon Wilczek, syzbot+d27edf9f96ae85939222, Konstantin Komarov,
Sasha Levin, ntfs3, linux-kernel
From: Szymon Wilczek <swilczek.lx@gmail.com>
[ 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.
Reported-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com
Tested-by: syzbot+d27edf9f96ae85939222@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=d27edf9f96ae85939222
Signed-off-by: Szymon Wilczek <swilczek.lx@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
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(-)
diff --git a/fs/ntfs3/run.c b/fs/ntfs3/run.c
index 395b204925258..dc59cad4fa376 100644
--- a/fs/ntfs3/run.c
+++ b/fs/ntfs3/run.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH AUTOSEL 6.19-6.1] fs/ntfs3: drop preallocated clusters for sparse and compressed files
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
` (7 preceding siblings ...)
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.18] ntfs3: fix circular locking dependency in run_unpack_ex Sasha Levin
@ 2026-02-20 12:37 ` Sasha Levin
2026-02-20 12:38 ` [PATCH AUTOSEL 6.19-5.15] fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata Sasha Levin
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:37 UTC (permalink / raw)
To: patches, stable; +Cc: Konstantin Komarov, Sasha Levin, ntfs3, linux-kernel
From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
[ 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.
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
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(-)
diff --git a/fs/ntfs3/attrib.c b/fs/ntfs3/attrib.c
index c45880ab23912..0cd15a0983fee 100644
--- a/fs/ntfs3/attrib.c
+++ b/fs/ntfs3/attrib.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH AUTOSEL 6.19-5.15] fs: ntfs3: fix infinite loop in attr_load_runs_range on inconsistent metadata
2026-02-20 12:37 [PATCH AUTOSEL 6.19-5.15] libceph: define and enforce CEPH_MAX_KEY_LEN Sasha Levin
` (8 preceding siblings ...)
2026-02-20 12:37 ` [PATCH AUTOSEL 6.19-6.1] fs/ntfs3: drop preallocated clusters for sparse and compressed files Sasha Levin
@ 2026-02-20 12:38 ` Sasha Levin
9 siblings, 0 replies; 11+ messages in thread
From: Sasha Levin @ 2026-02-20 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Jaehun Gou, Seunghun Han, Jihoon Kwon, Konstantin Komarov,
Sasha Levin, ntfs3, linux-kernel
From: Jaehun Gou <p22gone@gmail.com>
[ 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.
Co-developed-by: Seunghun Han <kkamagui@gmail.com>
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
Co-developed-by: Jihoon Kwon <kjh010315@gmail.com>
Signed-off-by: Jihoon Kwon <kjh010315@gmail.com>
Signed-off-by: Jaehun Gou <p22gone@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
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(-)
diff --git a/fs/ntfs3/attrib.c b/fs/ntfs3/attrib.c
index 980ae9157248d..c45880ab23912 100644
--- a/fs/ntfs3/attrib.c
+++ b/fs/ntfs3/attrib.c
@@ -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
^ permalink raw reply related [flat|nested] 11+ messages in thread