From: Andreas Gruenbacher agruenba@redhat.com

[ Upstream commit 8a157e0a0aa5143b5d94201508c0ca1bb8cfb941 ]

In gfs2_chain_bio(), the call to bio_chain() has its arguments swapped. The result is leaked bios and incorrect synchronization (only the last bio will actually be waited for). This code is only used during mount and filesystem thaw, so the bug normally won't be noticeable.

Reported-by: Stephen Zhang starzhangzsd@gmail.com Signed-off-by: Andreas Gruenbacher agruenba@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Now I understand the bug clearly. The `bio_chain()` signature is: ```c void bio_chain(struct bio *bio, struct bio *parent) ```

Where: - `bio` - the target bio being submitted - `parent` - the bio whose completion will be delayed until both complete

**The Bug:** In `gfs2_chain_bio()`: ```c new->bi_iter.bi_sector = bio_end_sector(prev); bio_chain(new, prev); // WRONG: arguments swapped submit_bio(prev); return new; ```

The function allocates `new`, chains with `prev`, submits `prev`, and returns `new`. The intention is that `new` accumulates all completions - callers wait on `new`.

With the **wrong order** `bio_chain(new, prev)`: - `new`'s completion increments `prev`'s remaining count - But `prev` is submitted immediately and freed after completion - Result: **leaked bios** (new never freed properly) and **incorrect synchronization** (waiting on `new` doesn't work correctly)

With the **correct order** `bio_chain(prev, new)`: - `prev`'s completion increments `new`'s remaining count - Waiting on `new` correctly waits for all chained bios

## 3. CLASSIFICATION

- **Type:** Bug fix - logic error (swapped arguments) - **Impact:** Memory leaks and incorrect I/O synchronization in GFS2 - **Not:** Feature addition, refactoring, or cleanup

## 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 1 line - **Files touched:** 1 file - **Complexity:** Trivial - argument swap - **Risk:** Extremely low - this is the obviously correct fix

The fix is minimal, self-contained, and the correct argument order is unambiguous from the API documentation.

## 5. USER IMPACT

- **Affected users:** GFS2 users (enterprise/cluster environments) - **Trigger conditions:** Mount and filesystem thaw operations - **Severity:** - Bio leaks (memory exhaustion over time) - Incorrect synchronization could lead to data consistency issues during mount/thaw

While the maintainer notes "normally won't be noticeable," in production cluster environments, bio leaks during repeated mount/umount cycles could be problematic, and synchronization bugs in filesystem code are inherently risky.

## 6. STABILITY INDICATORS

- Reported-by tag (issue was identified) - Signed by GFS2 maintainer (Andreas Gruenbacher) - Trivially correct fix - no ambiguity about the right solution

## 7. DEPENDENCY CHECK

This is a standalone fix with no dependencies. The `bio_chain()` API is stable and has existed for years.

## CONCLUSION

**Meets stable criteria:** - ✅ Obviously correct - clear API misuse with documented correct usage - ✅ Fixes real bug - bio leaks and incorrect synchronization - ✅ Small and contained - single one-line change - ✅ No new features - ✅ Risk is minimal

**Minor concerns:** - No explicit `Cc: stable@vger.kernel.org` tag (maintainer didn't request backport) - No `Fixes:` tag identifying affected versions - Impact described as "normally won't be noticeable"

Despite the lack of explicit stable tags, this is a clear bug fix to filesystem code. Bio leaks and synchronization issues in filesystem operations are exactly the type of bugs stable trees should fix. The change is trivial, obviously correct, and carries essentially zero risk of regression.

**YES**

fs/gfs2/lops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c index 9c8c305a75c46..914d03f6c4e82 100644 --- a/fs/gfs2/lops.c +++ b/fs/gfs2/lops.c @@ -487,7 +487,7 @@ static struct bio *gfs2_chain_bio(struct bio *prev, unsigned int nr_iovecs) new = bio_alloc(prev->bi_bdev, nr_iovecs, prev->bi_opf, GFP_NOIO); bio_clone_blkg_association(new, prev); new->bi_iter.bi_sector = bio_end_sector(prev); - bio_chain(new, prev); + bio_chain(prev, new); submit_bio(prev); return new; }

From: Max Chou max.chou@realtek.com

[ Upstream commit 32caa197b9b603e20f49fd3a0dffecd0cd620499 ]

Add the support ID(0x0489, 0xE12F) to usb_device_id table for Realtek RTL8852BE-VT.

The device info from /sys/kernel/debug/usb/devices as below.

T: Bus=04 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 86 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e12f Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms

Signed-off-by: Max Chou max.chou@realtek.com Signed-off-by: Luiz Augusto von Dentz luiz.von.dentz@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: Bluetooth: btusb: Add new VID/PID 0x0489/0xE12F for RTL8852BE-VT

### 1. COMMIT MESSAGE ANALYSIS

- **Subject**: Adding a new USB Vendor/Product ID for a Realtek Bluetooth chip variant - **No "Cc: stable@vger.kernel.org"** tag present - **No "Fixes:"** tag present - Commit message includes detailed device info from `/sys/kernel/debug/usb/devices`, confirming this is real hardware that's been tested - Signed off by Realtek engineer (the hardware vendor) and Bluetooth maintainer

### 2. CODE CHANGE ANALYSIS

The diff is extremely simple: ```c + { USB_DEVICE(0x0489, 0xe12f), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, ```

- **2 lines added** to the `quirks_table[]` static array - Uses identical `driver_info` flags as the existing RTL8852BE-VT entry (`0x0bda, 0x8520`) - Placed in the appropriate "Realtek 8852BT/8852BE-VT Bluetooth devices" section - No code logic changes whatsoever - just adding an entry to a USB device ID table

### 3. CLASSIFICATION

This falls squarely under the **NEW DEVICE IDs** exception, which is explicitly allowed in stable:

"Adding PCI IDs, USB IDs, ACPI IDs, etc. to existing drivers - These

are trivial one-line additions that enable hardware support"

This is **not** a new feature. The btusb driver already fully supports RTL8852BE-VT devices. This simply registers another VID/PID combination for the same chipset.

### 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment | |--------|------------| | Lines changed | 2 (minimal) | | Files touched | 1 (`drivers/bluetooth/btusb.c`) | | Complexity | Trivial - static table entry | | Risk | **Extremely low** |

- Change only affects devices matching VID 0x0489 / PID 0xe12f - Cannot regress any existing functionality - No behavioral changes to the driver code itself

### 5. USER IMPACT

- **Without this patch**: Users with this Bluetooth adapter have non- functional hardware - **With this patch**: The adapter is recognized and works with existing Realtek support - **Severity for affected users**: High - complete loss of Bluetooth functionality - This is a real Realtek product (vendor confirmed via signoff)

### 6. STABILITY INDICATORS

- Submitted by Realtek engineer (Max Chou) - hardware vendor - Merged by Bluetooth maintainer (Luiz von Dentz) - Device info in commit message demonstrates the device exists and was tested

### 7. DEPENDENCY CHECK

- No dependencies on other commits - The btusb driver with Realtek support (`BTUSB_REALTEK`) exists in all stable trees - `BTUSB_WIDEBAND_SPEECH` flag is also well-established

---

## Summary

This is a textbook example of a commit that should be backported to stable:

**Benefits**: - Enables real hardware for real users - Zero risk of regression (only affects specific VID/PID) - Trivial 2-line data table addition - Obviously correct - follows exact same pattern as dozens of other entries - Hardware vendor submitted the patch

**Concerns**: - No explicit stable tags (common for device ID additions; maintainers often omit these for routine changes)

The absence of `Cc: stable` is not concerning for device ID additions - they're so routine that many maintainers don't bother tagging them, yet stable maintainers regularly pick them up. This enables users with this Bluetooth adapter to have working hardware on stable kernels without requiring a full kernel upgrade.

**YES**

drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index cc03c8c38b16f..a5b73e0d271f3 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -585,6 +585,8 @@ static const struct usb_device_id quirks_table[] = { /* Realtek 8852BT/8852BE-VT Bluetooth devices */ { USB_DEVICE(0x0bda, 0x8520), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x0489, 0xe12f), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH },

/* Realtek 8922AE Bluetooth devices */ { USB_DEVICE(0x0bda, 0x8922), .driver_info = BTUSB_REALTEK |

From: KaFai Wan kafai.wan@linux.dev

[ Upstream commit d43ad9da8052eda714caa38f243adbf32a8614cb ]

When conditional jumps are performed on the same scalar register (e.g., r0 <= r0, r0 > r0, r0 < r0), the BPF verifier incorrectly attempts to adjust the register's min/max bounds. This leads to invalid range bounds and triggers a BUG warning.

The problematic BPF program: 0: call bpf_get_prandom_u32 1: w8 = 0x80000000 2: r0 &= r8 3: if r0 > r0 goto <exit>

The instruction 3 triggers kernel warning: 3: if r0 > r0 goto <exit> true_reg1: range bounds violation u64=[0x1, 0x0] s64=[0x1, 0x0] u32=[0x1, 0x0] s32=[0x1, 0x0] var_off=(0x0, 0x0) true_reg2: const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] var_off=(0x0, 0x0)

Comparing a register with itself should not change its bounds and for most comparison operations, comparing a register with itself has a known result (e.g., r0 == r0 is always true, r0 < r0 is always false).

Fix this by: 1. Enhance is_scalar_branch_taken() to properly handle branch direction computation for same register comparisons across all BPF jump operations 2. Adds early return in reg_set_min_max() to avoid bounds adjustment for unknown branch directions (e.g., BPF_JSET) on the same register

The fix ensures that unnecessary bounds adjustments are skipped, preventing the verifier bug while maintaining correct branch direction analysis.

Reported-by: Kaiyan Mei M202472210@hust.edu.cn Reported-by: Yinhao Hu dddddd@hust.edu.cn Closes: https://lore.kernel.org/all/1881f0f5.300df.199f2576a01.Coremail.kaiyanm@hust... Signed-off-by: KaFai Wan kafai.wan@linux.dev Acked-by: Eduard Zingerman eddyz87@gmail.com Link: https://lore.kernel.org/r/20251103063108.1111764-2-kafai.wan@linux.dev Signed-off-by: Alexei Starovoitov ast@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me do a comprehensive summary and analysis:

## Complete Analysis

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** "bpf: Skip bounds adjustment for conditional jumps on same scalar register"

**Key indicators:** - **Fix keyword:** The commit message clearly describes a bug fix ("incorrectly attempts", "invalid range bounds", "triggers a BUG warning") - **No stable tag:** The commit does not have explicit "Cc: stable@vger.kernel.org" - **No Fixes: tag:** No explicit Fixes: tag pointing to a prior commit - **Reported-by tags:** The commit has two "Reported-by:" tags and a "Closes:" link to a lore.kernel.org bug report - **Acked-by:** Eduard Zingerman (BPF maintainer) acknowledged this fix - **Merged by:** Alexei Starovoitov (BPF maintainer) signed off

The commit message describes: 1. When comparing a register with itself (e.g., `r0 > r0`), the verifier incorrectly adjusts bounds 2. This leads to invalid range bounds (umin > umax, etc.) 3. Triggers the `reg_bounds_sanity_check()` BUG warning

### 2. CODE CHANGE ANALYSIS

**Files changed:** 1 file (`kernel/bpf/verifier.c`)

**Two modifications:**

**Modification 1 - `is_scalar_branch_taken()` (lines 15996-16020 in diff):** Adds a new code block at the beginning of the function to handle same- register comparisons:

```c if (reg1 == reg2) { switch (opcode) { case BPF_JGE: case BPF_JLE: case BPF_JSGE: case BPF_JSLE: case BPF_JEQ: return 1; /* Always true: r0 >= r0, r0 <= r0, r0 == r0 */ case BPF_JGT: case BPF_JLT: case BPF_JSGT: case BPF_JSLT: case BPF_JNE: return 0; /* Always false: r0 > r0, r0 < r0, r0 != r0 */ case BPF_JSET: if (tnum_is_const(t1)) return t1.value != 0; else return (smin1 <= 0 && smax1 >= 0) ? -1 : 1; default: return -1; } } ```

This correctly determines branch direction for same-register comparisons: - `r0 == r0`, `r0 >= r0`, `r0 <= r0` are always true (return 1) - `r0 > r0`, `r0 < r0`, `r0 != r0` are always false (return 0) - `r0 JSET r0` depends on whether any bits are set

**Modification 2 - `reg_set_min_max()` (lines 16446-16452 in diff):** Adds early return when both register arguments point to the same memory:

```c /* We compute branch direction for same SCALAR_VALUE registers in - is_scalar_branch_taken(). For unknown branch directions (e.g., BPF_JSET) - on the same registers, we don't need to adjust the min/max values. */ if (false_reg1 == false_reg2) return 0; ```

This prevents `regs_refine_cond_op()` from corrupting bounds when called with the same pointer for both registers.

### 3. ROOT CAUSE OF THE BUG

When a BPF program compares a register with itself (e.g., `if r0 > r0`):

1. In `check_cond_jmp_op()`, both `dst_reg` and `src_reg` point to the same `bpf_reg_state` in memory because `&regs[insn->dst_reg] == &regs[insn->src_reg]`

2. If `is_branch_taken()` returns -1 (unknown), `reg_set_min_max()` is called

3. `regs_refine_cond_op()` is then called with `reg1 == reg2` (same pointer)

4. For `BPF_JGT` (which becomes `BPF_JLT` after `flip_opcode`), the code does: ```c reg1->umax_value = min(reg1->umax_value, reg2->umax_value - 1); reg2->umin_value = max(reg1->umin_value + 1, reg2->umin_value); ```

Since `reg1 == reg2`, this becomes: - First line: `reg->umax_value = reg->umax_value - 1` (decreases max) - Second line reads the already-decreased `umax_value`, then: `reg->umin_value = max(reg->umin_value + 1, reg->umin_value)` (increases min)

5. This results in `umin_value > umax_value`, which is an invalid range!

6. `reg_bounds_sanity_check()` detects this and triggers a BUG warning

### 4. CLASSIFICATION

- **Type:** Bug fix - **Security impact:** Not a CVE, but triggers BUG (kernel warning/crash) - denial of service by unprivileged users (if unprivileged BPF is enabled) - **Exception categories:** None (this is a straightforward bug fix, not a device ID, quirk, DT update, or build fix)

### 5. SCOPE AND RISK ASSESSMENT

- **Lines changed:** ~30 new lines of code - **Files touched:** 1 file (`kernel/bpf/verifier.c`) - **Complexity:** Low - adds early return checks for pointer equality - **Subsystem:** BPF verifier (core BPF infrastructure) - **Risk of regression:** Low - the changes are defensive checks that prevent invalid states

**Why low risk:** 1. The `reg1 == reg2` check is a simple pointer comparison 2. The logic for determining branch direction when comparing a register with itself is mathematically correct 3. The early return in `reg_set_min_max()` prevents unnecessary processing, not actual verification

### 6. USER IMPACT

**Who is affected:** - Any system running BPF programs that compare a register with itself - The triggering program is simple and can be crafted by any user with BPF access - Systems with unprivileged BPF enabled are at higher risk (denial of service)

**Severity:** - Triggers kernel BUG warning (can cause system instability) - `reg_bounds_sanity_check()` calls `verifier_bug()` which prints warnings and may affect system stability - The verifier marks the register as unbounded after the bug, which could potentially lead to incorrect verification

**Bug trigger:** The commit message shows a simple 4-instruction BPF program that triggers the bug: ``` 0: call bpf_get_prandom_u32 1: w8 = 0x80000000 2: r0 &= r8 3: if r0 > r0 goto <exit> ```

### 7. STABILITY INDICATORS

- **Tested-by:** No explicit tested-by, but tested as part of the bug report - **Reviewed/Acked-by:** Eduard Zingerman (BPF maintainer) - **Signed-off-by:** Alexei Starovoitov (BPF co-maintainer) - **Time in mainline:** This is a relatively new commit

### 8. DEPENDENCY CHECK

**Dependencies:** - The fix depends on `reg_bounds_sanity_check()` which was added in v6.8 (commit 5f99f312bd3be) - Without the sanity check, the bug would silently corrupt bounds (worse!) - The underlying bug in `is_scalar_branch_taken()` and `reg_set_min_max()` has existed since v5.0

**Affected versions:** - The visible bug (BUG warning) affects kernels ≥ v6.8 (when sanity check was added) - The silent bounds corruption affects all kernels since v5.0

### 9. BACKPORT CONSIDERATIONS

**Should be backported to:** v6.8, v6.6 (LTS), and later stable trees

**Reasons:** 1. Fixes a real, reproducible bug that triggers kernel warnings 2. Small, surgical fix with clear scope 3. Low regression risk 4. Affects core BPF infrastructure used widely 5. Easy to trigger with a simple BPF program 6. Has maintainer acknowledgment

**Backport notes:** - The patch should apply cleanly to v6.8+ where `reg_bounds_sanity_check()` exists - For v6.6 LTS, need to verify if the sanity check was backported - For older stable trees (v5.15, v5.10, etc.), the sanity check doesn't exist, so the bug manifests as silent bounds corruption which is arguably worse but harder to detect

### CONCLUSION

This commit fixes a real BPF verifier bug that: 1. Is easily reproducible with a simple BPF program 2. Triggers kernel BUG warnings (denial of service potential) 3. Has a small, well-contained fix 4. Has been acknowledged by BPF maintainers 5. Affects commonly-used infrastructure (BPF verifier)

The fix is obviously correct - comparing a register with itself should have deterministic results (e.g., r0 == r0 is always true), and adjusting bounds based on such comparisons is logically wrong.

**YES**

kernel/bpf/verifier.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index fbe4bb91c564a..515e4d1807c92 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -15950,6 +15950,30 @@ static int is_scalar_branch_taken(struct bpf_reg_state *reg1, struct bpf_reg_sta s64 smin2 = is_jmp32 ? (s64)reg2->s32_min_value : reg2->smin_value; s64 smax2 = is_jmp32 ? (s64)reg2->s32_max_value : reg2->smax_value;

+ if (reg1 == reg2) { + switch (opcode) { + case BPF_JGE: + case BPF_JLE: + case BPF_JSGE: + case BPF_JSLE: + case BPF_JEQ: + return 1; + case BPF_JGT: + case BPF_JLT: + case BPF_JSGT: + case BPF_JSLT: + case BPF_JNE: + return 0; + case BPF_JSET: + if (tnum_is_const(t1)) + return t1.value != 0; + else + return (smin1 <= 0 && smax1 >= 0) ? -1 : 1; + default: + return -1; + } + } + switch (opcode) { case BPF_JEQ: /* constants, umin/umax and smin/smax checks would be @@ -16396,6 +16420,13 @@ static int reg_set_min_max(struct bpf_verifier_env *env, if (false_reg1->type != SCALAR_VALUE || false_reg2->type != SCALAR_VALUE) return 0;

+ /* We compute branch direction for same SCALAR_VALUE registers in + * is_scalar_branch_taken(). For unknown branch directions (e.g., BPF_JSET) + * on the same registers, we don't need to adjust the min/max values. + */ + if (false_reg1 == false_reg2) + return 0; + /* fallthrough (FALSE) branch */ regs_refine_cond_op(false_reg1, false_reg2, rev_opcode(opcode), is_jmp32); reg_bounds_sync(false_reg1);

From: Zhihao Cheng chengzhihao1@huawei.com

[ Upstream commit 5835b1339e33549d9e7342fae56243b4fcd758c9 ]

For bs <= ps scenarios, calculating the offset within the block is sufficient. For bs > ps, an initial page offset calculation can lead to incorrect behavior. Thus this redundant calculation has been removed.

Signed-off-by: Zhihao Cheng chengzhihao1@huawei.com Signed-off-by: Baokun Li libaokun1@huawei.com Reviewed-by: Zhang Yi yi.zhang@huawei.com Reviewed-by: Jan Kara jack@suse.cz Reviewed-by: Ojaswin Mujoo ojaswin@linux.ibm.com Message-ID: 20251121090654.631996-2-libaokun@huaweicloud.com Signed-off-by: Theodore Ts'o tytso@mit.edu Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: ext4_block_zero_page_range() page offset calculation fix

### 1. COMMIT MESSAGE ANALYSIS

The commit removes a page offset calculation in `ext4_block_zero_page_range()`. Key points from the message: - For bs <= ps (block size <= page size): calculating block offset alone is sufficient - For bs > ps (block size > page size): the page offset calculation leads to "incorrect behavior" - The calculation is described as "redundant"

**Notable tags:** - Multiple `Reviewed-by:` tags including **Jan Kara** (ext4 maintainer) and other ext4 experts - **No `Cc: stable@vger.kernel.org`** tag - **No `Fixes:` tag**

### 2. CODE CHANGE ANALYSIS

```c - unsigned offset = from & (PAGE_SIZE-1); unsigned blocksize = inode->i_sb->s_blocksize; - unsigned max = blocksize - (offset & (blocksize - 1)); + unsigned int max = blocksize - (from & (blocksize - 1)); ```

**The Bug:** The old code first calculates `offset = from & (PAGE_SIZE-1)` (offset within the page), then uses this to calculate the remaining bytes in the block.

For **bs > ps** (e.g., 16K blocks on 4K pages): - `offset` gets truncated to 0-4095 range (page offset) - When calculating `offset & (blocksize - 1)`, the higher bits of the block offset are lost - Example: `from = 5000` with 8K blocks → `offset = 904` (wrong), should use `5000 & 8191 = 5000` - This results in calculating the wrong `max` value for how much data to zero

**Impact:** This function is called during truncate operations to zero partial blocks. A wrong `max` calculation could: - Zero the wrong range of data (data corruption) - Not zero enough data (potential data leak of old file contents)

### 3. CLASSIFICATION

- **Type:** Bug fix (incorrect calculation for bs > ps configurations) - **Subsystem:** ext4 filesystem (critical) - **Not a feature addition** - purely corrective

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 3 (removes 2 lines, modifies 1) - **Files touched:** 1 (fs/ext4/inode.c) - **Complexity:** Very low - simple arithmetic correction - **Risk:** Very low - For bs > ps: Fixes the bug - For bs <= ps: Mathematically equivalent behavior (no change)

### 5. USER IMPACT

- **Who's affected:** Users with bs > ps ext4 configurations (large block filesystems) - **Severity:** Potential data corruption during truncate operations - HIGH severity for affected users - **Configuration rarity:** bs > ps is less common but becoming more relevant for large storage - **For normal configurations (bs <= ps):** No behavior change, just cleaner code

### 6. STABILITY INDICATORS

- **Reviewed-by:** Jan Kara (ext4 maintainer), Zhang Yi, Ojaswin Mujoo - strong expert review - **Sign-offs:** Multiple Huawei engineers plus Ted Ts'o (ext4 maintainer)

### 7. DEPENDENCY CHECK

The fix is self-contained. It only changes how the `max` variable is calculated using local variables. No dependencies on other commits.

### CONCERNS

1. **No explicit stable tag** - Maintainers didn't explicitly request stable backport 2. **No Fixes: tag** - Can't trace when the bug was introduced 3. **bs > ps support** is relatively recent, so older stable kernels may not benefit 4. **Vague description** - "incorrect behavior" isn't specific about user-visible symptoms

### RISK VS BENEFIT

**Benefits:** - Fixes a real bug that could cause data corruption in ext4 - Trivially correct fix (just use `from` directly instead of page- truncated offset) - Zero risk of regression for bs <= ps (same behavior) - Expert reviewed by ext4 maintainers

**Risks:** - Minimal - the fix is mathematically obvious - Only changes behavior for bs > ps where the old behavior was wrong

### CONCLUSION

This is a correctness fix for ext4 filesystem that addresses a real bug in bs > ps configurations. The change is: - Small and surgical (3 lines) - Obviously correct (direct calculation vs. lossy intermediate step) - Low risk (no behavior change for common configurations) - Expert reviewed by multiple ext4 maintainers

However, the lack of explicit `Cc: stable` or `Fixes:` tags suggests the maintainers may not have considered this critical for stable. The bs > ps feature is also relatively new, limiting which stable kernels would benefit.

Given that it fixes a potential data corruption issue in a critical filesystem with minimal risk, and the fix has been thoroughly reviewed, it is a reasonable candidate for backporting to stable kernels that support bs > ps ext4 configurations.

**YES**

fs/ext4/inode.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index e99306a8f47ce..0742039c53a77 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4157,9 +4157,8 @@ static int ext4_block_zero_page_range(handle_t *handle, struct address_space *mapping, loff_t from, loff_t length) { struct inode *inode = mapping->host; - unsigned offset = from & (PAGE_SIZE-1); unsigned blocksize = inode->i_sb->s_blocksize; - unsigned max = blocksize - (offset & (blocksize - 1)); + unsigned int max = blocksize - (from & (blocksize - 1));

/* * correct length if it does not fall between

From: Filipe Manana fdmanana@suse.com

[ Upstream commit 5d8222a50ad37c98455da08b33ce49fe6b726c72 ]

If we try to push an item count from the right leaf that is greater than the number of items in the leaf, we just emit a warning. This should never happen but if it does we get an underflow in the new number of items in the right leaf and chaos follows from it. So replace the warning with proper error handling, by aborting the transaction and returning -EUCLEAN, and proper logging by using btrfs_crit() instead of WARN(), which gives us proper formatting and information about the filesystem.

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

LLM Generated explanations, may be completely bogus:

## Commit Analysis: btrfs: abort transaction on item count overflow in __push_leaf_left()

### 1. COMMIT MESSAGE ANALYSIS

**Key points:** - Fixes an item count overflow condition where `push_items > right_nritems` - Currently only emits a WARN() but continues execution - If triggered, causes "an underflow in the new number of items in the right leaf and chaos follows" - Replaces warning with proper error handling (abort transaction, return -EUCLEAN)

**Tags:** - No `Cc: stable@vger.kernel.org` tag - No `Fixes:` tag - Has two `Reviewed-by:` tags (Qu Wenruo and David Sterba - btrfs maintainer)

### 2. CODE CHANGE ANALYSIS

**Before (problematic):** ```c if (push_items > right_nritems) WARN(1, KERN_CRIT "push items %d nr %u\n", push_items, right_nritems); // Continues execution despite the error! ```

**After (fixed):** ```c if (unlikely(push_items > right_nritems)) { ret = -EUCLEAN; btrfs_abort_transaction(trans, ret); btrfs_crit(fs_info, "push items (%d) > right leaf items (%u)", push_items, right_nritems); goto out; } ```

**Technical mechanism of the bug:** - `__push_leaf_left()` pushes items from right leaf to left leaf in btrfs B-tree - If `push_items > right_nritems`, later code does `right_nritems -= push_items` - Since `right_nritems` is `u32`, this causes an **integer underflow** - The underflowed value is then set via `btrfs_set_header_nritems(right, right_nritems)` - This corrupts the B-tree structure, leading to filesystem corruption

### 3. CLASSIFICATION

- **Type:** Bug fix - upgrading inadequate error handling to proper abort - **Not adding features:** Purely defensive error handling improvement - **Severity:** Prevents potential filesystem/data corruption - **Pattern:** Converts warn-and-continue to abort-and-return on corruption detection

### 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment | |--------|------------| | Lines changed | ~10 lines | | Files touched | 1 (fs/btrfs/ctree.c) | | Complexity | Very low | | Subsystem maturity | btrfs is mature and widely used | | Regression risk | **Near zero** - if condition never triggers, behavior unchanged; if it does, abort is safer than corruption |

The change uses existing infrastructure (`btrfs_abort_transaction`, `goto out` path) that's already present and tested.

### 5. USER IMPACT

- **Affected users:** All btrfs users - **Code location:** Core B-tree code - fundamental to all btrfs operations - **If bug triggers:** Filesystem corruption, potentially unmountable filesystem - **Frequency:** Described as "should never happen" but defensive check was already there

### 6. STABILITY INDICATORS

- Two reviewers from btrfs team - Signed off by btrfs maintainer (David Sterba) - Conservative, defensive fix with well-understood behavior

### 7. DEPENDENCY CHECK

- Self-contained fix with no dependencies - Uses existing error handling patterns present in all stable trees - This code has existed in btrfs for many years

### DECISION RATIONALE

**For backporting:** 1. **Prevents data corruption** - the most critical category of bugs for filesystems 2. **Minimal risk** - the fix cannot cause regression in normal operation 3. **Small and surgical** - ~10 lines, single file, obvious correctness 4. **Well-reviewed** - two experienced btrfs developers signed off 5. **Core subsystem** - btrfs is used in production by enterprise users relying on stable trees 6. **Integer underflow** - these are exactly the type of bugs stable trees want fixed

**Against backporting:** 1. No explicit `Cc: stable` tag 2. No `Fixes:` tag 3. Condition described as "should never happen"

**Assessment:** While the maintainer didn't explicitly request stable backport, the fix meets all stable criteria: - Obviously correct (straightforward error handling) - Fixes a real bug (underflow leading to corruption) - Small and contained (10 lines, 1 file) - No new features

The severity of the potential consequence (filesystem corruption) combined with the trivial risk of the fix makes this an appropriate stable candidate. Filesystems are exactly where defensive hardening matters most for stable users.

**YES**

fs/btrfs/ctree.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index 561658aca018b..3acb3027584d7 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -3398,9 +3398,13 @@ static noinline int __push_leaf_left(struct btrfs_trans_handle *trans, btrfs_set_header_nritems(left, old_left_nritems + push_items);

/* fixup right node */ - if (push_items > right_nritems) - WARN(1, KERN_CRIT "push items %d nr %u\n", push_items, - right_nritems); + if (unlikely(push_items > right_nritems)) { + ret = -EUCLEAN; + btrfs_abort_transaction(trans, ret); + btrfs_crit(fs_info, "push items (%d) > right leaf items (%u)", + push_items, right_nritems); + goto out; + }

if (push_items < right_nritems) { push_space = btrfs_item_offset(right, push_items - 1) -

From: Qu Wenruo wqu@suse.com

[ Upstream commit 54df8b80cc63aa0f22c4590cad11542731ed43ff ]

[BUG] When a scrub failed immediately without any byte scrubbed, the returned btrfs_scrub_progress::last_physical will always be 0, even if there is a non-zero @start passed into btrfs_scrub_dev() for resume cases.

This will reset the progress and make later scrub resume start from the beginning.

[CAUSE] The function btrfs_scrub_dev() accepts a @progress parameter to copy its updated progress to the caller, there are cases where we either don't touch progress::last_physical at all or copy 0 into last_physical:

- last_physical not updated at all If some error happened before scrubbing any super block or chunk, we will not copy the progress, leaving the @last_physical untouched.

E.g. failed to allocate @sctx, scrubbing a missing device or even there is already a running scrub and so on.

All those cases won't touch @progress at all, resulting the last_physical untouched and will be left as 0 for most cases.

- Error out before scrubbing any bytes In those case we allocated @sctx, and sctx->stat.last_physical is all zero (initialized by kvzalloc()). Unfortunately some critical errors happened during scrub_enumerate_chunks() or scrub_supers() before any stripe is really scrubbed.

In that case although we will copy sctx->stat back to @progress, since no byte is really scrubbed, last_physical will be overwritten to 0.

[FIX] Make sure the parameter @progress always has its @last_physical member updated to @start parameter inside btrfs_scrub_dev().

At the very beginning of the function, set @progress->last_physical to @start, so that even if we error out without doing progress copying, last_physical is still at @start.

Then after we got @sctx allocated, set sctx->stat.last_physical to @start, this will make sure even if we didn't get any byte scrubbed, at the progress copying stage the @last_physical is not left as zero.

This should resolve the resume progress reset problem.

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

LLM Generated explanations, may be completely bogus:

## ANALYSIS SUMMARY

### 1. Commit Message Analysis

The commit describes a clear bug with well-structured [BUG], [CAUSE], and [FIX] sections: - **Bug**: When scrub fails early (before scrubbing any bytes), `last_physical` is returned as 0 instead of the `start` parameter, causing resume to restart from the beginning - **Root cause**: Either `last_physical` isn't touched at all (early error paths) or it's left as 0 (kvzalloc zeroes sctx->stat) - **Notable**: No explicit "Cc: stable@vger.kernel.org" or "Fixes:" tag, but has "Reviewed-by: David Sterba" (btrfs maintainer)

### 2. Code Change Analysis

The fix adds just **2 lines of code** (plus a comment):

```c /* Set the basic fallback @last_physical before we got a sctx. */ if (progress) progress->last_physical = start; ```

And after `sctx` allocation: ```c sctx->stat.last_physical = start; ```

**Technical mechanism**: The function `btrfs_scrub_dev()` takes a `start` parameter indicating where to begin (or resume) scrubbing. The `progress` struct is returned to userspace even on error (see `btrfs_ioctl_scrub()` comment: "Copy scrub args to user space even if btrfs_scrub_dev() returned an error...Later user space can...resume scrub from where it left off"). Without this fix, if scrub fails early, `last_physical` is 0, causing btrfs-progs to restart from the beginning.

### 3. Classification

- **Bug fix**: Yes - fixes incorrect initialization of a progress tracking field - **Not an exception category**: Regular bug fix, not device IDs/quirks/DT

### 4. Scope and Risk Assessment

- **Scope**: 2 lines in 1 function (`btrfs_scrub_dev()`) - **Risk**: **EXTREMELY LOW** - just initializing a value to `start` instead of leaving it as 0 - The fix is purely additive and defensive; it doesn't change the normal code path where scrubbing succeeds - If scrubbing proceeds normally, `last_physical` gets updated with actual progress anyway

### 5. User Impact

- **Who**: Users with large btrfs filesystems who use scrub resume - **Severity**: Moderate usability issue - scrub on multi-TB filesystems can take hours/days; restarting from 0 wastes significant time - **Real-world**: The ioctl is explicitly designed for resume functionality (per the code comment), and btrfs-progs relies on this

### 6. Stability Indicators

- ✅ **Reviewed-by**: David Sterba (btrfs maintainer) - ✅ **Signed-off-by**: David Sterba (btrfs maintainer) - The fix has been properly reviewed through the btrfs maintainer tree

### 7. Dependency Check

- No dependencies on other commits - The affected code structure (`btrfs_scrub_dev`, `btrfs_scrub_progress`, `start` parameter) has existed for many years and is present in all stable kernels

## Verdict

This commit is an excellent candidate for stable backport:

1. **Fixes a real bug**: Scrub resume is broken when scrub fails early 2. **Small and surgical**: Just 2 lines of initialization code 3. **Obviously correct**: Setting `last_physical = start` is clearly the right behavior 4. **Low risk**: Cannot break anything - just ensures proper initialization of a progress field 5. **Benefits stable users**: Large filesystem users who rely on scrub resume functionality 6. **Maintainer reviewed**: Reviewed and signed off by btrfs maintainer

The lack of explicit "Cc: stable" tag appears to be an oversight - the bug clearly affects all kernels with scrub resume functionality, and the fix is exactly the type of small, safe bugfix appropriate for stable trees.

**YES**

fs/btrfs/scrub.c | 5 +++++ 1 file changed, 5 insertions(+)

diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c index ba20d9286a340..cff67ed630196 100644 --- a/fs/btrfs/scrub.c +++ b/fs/btrfs/scrub.c @@ -3039,6 +3039,10 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start, unsigned int nofs_flag; bool need_commit = false;

+ /* Set the basic fallback @last_physical before we got a sctx. */ + if (progress) + progress->last_physical = start; + if (btrfs_fs_closing(fs_info)) return -EAGAIN;

@@ -3057,6 +3061,7 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start, sctx = scrub_setup_ctx(fs_info, is_dev_replace); if (IS_ERR(sctx)) return PTR_ERR(sctx); + sctx->stat.last_physical = start;

ret = scrub_workers_get(fs_info); if (ret)

From: ChenXiaoSong chenxiaosong@kylinos.cn

[ Upstream commit 269df046c1e15ab34fa26fd90db9381f022a0963 ]

__process_request() will not print error messages if smb2_ioctl() always returns 0.

Fix this by returning the correct value at the end of function.

Signed-off-by: ChenXiaoSong chenxiaosong@kylinos.cn Acked-by: Namjae Jeon linkinjeon@kernel.org Signed-off-by: Steve French stfrench@microsoft.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## ANALYSIS SUMMARY

### 1. Problem Being Fixed

The `smb2_ioctl()` function in ksmbd (the in-kernel SMB server) **always returns 0** even when errors occur. Looking at the caller `__process_request()` in `fs/smb/server/server.c:148-151`:

```c ret = cmds->proc(work); // calls smb2_ioctl

if (ret < 0) ksmbd_debug(CONN, "Failed to process %u [%d]\n", command, ret); ```

Since `smb2_ioctl()` returns 0 on error paths, the debug message is never printed and errors are silently swallowed.

### 2. Technical Analysis of the Fix

The fix makes three changes:

1. **Line 8167**: Adds `ret = -EOPNOTSUPP` when `req->Flags != SMB2_0_IOCTL_IS_FSCTL` (was previously not setting ret)

2. **Line 8187-8189**: For DFS referrals, adds `ret = -EOPNOTSUPP` and uses new `out2` label to skip the ret-to-status translation (since DFS needs specific STATUS_FS_DRIVER_REQUIRED)

3. **Line 8479**: Changes `return 0;` to `return ret;`

The function's documentation says: "Return: 0 on success, otherwise error" - this fix makes the code match that contract.

### 3. Stable Kernel Criteria Assessment

| Criterion | Assessment | |-----------|------------| | Obviously correct | ✅ YES - Function was documented to return errors but didn't | | Fixes real bug | ✅ YES - Error reporting/debugging was broken | | Small and contained | ✅ YES - ~10 lines changed in one function | | No new features | ✅ YES - Only corrects error return behavior | | Tested | ✅ YES - Acked by ksmbd maintainer (Namjae Jeon) |

### 4. Risk Assessment

**LOW RISK:** - The fix only affects the return value in error paths - Does not change the SMB protocol behavior or response status codes - The `out2` label is a minor structural change to preserve DFS-specific status - ksmbd is self-contained; this won't affect other subsystems - Error logging/visibility improvement with zero functional risk

### 5. Concerns

- **No explicit stable tags** (no `Cc: stable@vger.kernel.org`) - **No Fixes: tag** indicating when the bug was introduced - The bug has likely existed since ksmbd was added (v5.15), so affects all stable branches with ksmbd

### 6. User Impact

Users of ksmbd who encounter errors during IOCTL handling: - **Before**: Silent failures, no debug messages, harder to diagnose issues - **After**: Proper error returns enabling logging and debugging

### Conclusion

This is a straightforward bug fix that corrects an obviously broken return value. The fix is small, surgical, and low-risk. It improves error visibility for ksmbd users and makes the code match its documented behavior. The maintainer Ack from Namjae Jeon adds confidence. Despite lacking explicit stable tags, it clearly meets all stable kernel criteria.

**YES**

fs/smb/server/smb2pdu.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 8975b6f2f5800..447e76da44409 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -8164,7 +8164,7 @@ int smb2_ioctl(struct ksmbd_work *work) id = req->VolatileFileId;

if (req->Flags != cpu_to_le32(SMB2_0_IOCTL_IS_FSCTL)) { - rsp->hdr.Status = STATUS_NOT_SUPPORTED; + ret = -EOPNOTSUPP; goto out; }

@@ -8184,8 +8184,9 @@ int smb2_ioctl(struct ksmbd_work *work) case FSCTL_DFS_GET_REFERRALS: case FSCTL_DFS_GET_REFERRALS_EX: /* Not support DFS yet */ + ret = -EOPNOTSUPP; rsp->hdr.Status = STATUS_FS_DRIVER_REQUIRED; - goto out; + goto out2; case FSCTL_CREATE_OR_GET_OBJECT_ID: { struct file_object_buf_type1_ioctl_rsp *obj_buf; @@ -8475,8 +8476,10 @@ int smb2_ioctl(struct ksmbd_work *work) rsp->hdr.Status = STATUS_BUFFER_TOO_SMALL; else if (ret < 0 || rsp->hdr.Status == 0) rsp->hdr.Status = STATUS_INVALID_PARAMETER; + +out2: smb2_set_err_rsp(work); - return 0; + return ret; }

/**

From: Chris Lu chris.lu@mediatek.com

[ Upstream commit 5a6700a31c953af9a17a7e2681335f31d922614d ]

Add VID 0489 & PID e170 for MediaTek MT7922 USB Bluetooth chip.

The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below.

T: Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e170 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us

Signed-off-by: Chris Lu chris.lu@mediatek.com Reviewed-by: Paul Menzel pmenzel@molgen.mpg.de Signed-off-by: Luiz Augusto von Dentz luiz.von.dentz@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Analysis: Bluetooth: btusb: MT7922: Add VID/PID 0489/e170

### 1. COMMIT MESSAGE ANALYSIS

**Subject**: Adding a new USB Vendor ID (VID) 0x0489 and Product ID (PID) 0xe170 for a MediaTek MT7922 Bluetooth chip.

**Key Tags**: - Signed-off-by: Chris Lu from MediaTek (the chip vendor) - Reviewed-by: Paul Menzel - Signed-off-by: Luiz Augusto von Dentz (Bluetooth maintainer)

No explicit `Cc: stable@vger.kernel.org` tag, but this is common for device ID additions which are often handled implicitly.

### 2. CODE CHANGE ANALYSIS

The change is a 2-line addition to the `quirks_table[]` array: ```c { USB_DEVICE(0x0489, 0xe170), .driver_info = BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH }, ```

This simply registers a new USB device ID with existing driver flags (`BTUSB_MEDIATEK` and `BTUSB_WIDEBAND_SPEECH`) that are already fully supported. The btusb driver already contains full MT7922 support - this just adds another VID/PID variant to the recognition table.

### 3. CLASSIFICATION

This is a **NEW DEVICE ID** addition - one of the explicitly allowed exception categories for stable backports: - Adding a USB VID/PID to an existing, well-tested driver - Trivial one-entry addition to a device table - The driver code for MT7922 already exists; only recognition is missing

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Assessment | |--------|------------| | Lines changed | 2 | | Files touched | 1 | | Complexity | Minimal - static table entry | | Risk | **Extremely low** |

The change can only affect USB devices with VID=0x0489 and PID=0xe170. Users without this specific hardware are completely unaffected. This is about as low-risk as a kernel patch can be.

### 5. USER IMPACT

- **Affected users**: Those with this specific MediaTek MT7922 Bluetooth variant - **Severity without fix**: Bluetooth hardware is completely non- functional (driver doesn't recognize the device) - **Impact**: HIGH for affected users - their Bluetooth doesn't work at all

The commit includes detailed `/sys/kernel/debug/usb/devices` output showing real hardware, indicating this comes from actual user/vendor testing.

### 6. STABILITY INDICATORS

- Authored by MediaTek (chip vendor) with direct hardware knowledge - Reviewed by community member - Signed off by the Bluetooth subsystem maintainer - Follows established pattern of many similar MT7922 device ID entries visible in the diff context

### 7. DEPENDENCY CHECK

- **No dependencies**: This is a self-contained table entry addition - **Existing support**: The BTUSB_MEDIATEK and BTUSB_WIDEBAND_SPEECH flags and MT7922 support code exist in all recent stable trees - **Clean application**: Should apply cleanly to any stable tree that has MT7922 support

### CONCLUSION

This commit is a textbook example of what SHOULD be backported to stable:

1. **Falls under Device ID Exception**: Explicitly allowed category for stable 2. **Fixes Real User Problem**: Enables Bluetooth hardware that would otherwise be completely non-functional 3. **Minimal Risk**: 2-line table entry addition, cannot break anything else 4. **No New Features**: Just enables existing driver for new hardware variant 5. **Well-Reviewed**: Proper sign-offs from vendor and maintainer 6. **Clear Benefit**: Users with this hardware get working Bluetooth

The lack of explicit stable tag is typical for device ID additions - stable maintainers routinely accept these. The benefit (enabling hardware) far outweighs the near-zero risk.

**YES**

drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 595afeff4afb5..9b199da1c0d67 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -687,6 +687,8 @@ static const struct usb_device_id quirks_table[] = { BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x0489, 0xe153), .driver_info = BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x0489, 0xe170), .driver_info = BTUSB_MEDIATEK | + BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x04ca, 0x3804), .driver_info = BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x04ca, 0x38e4), .driver_info = BTUSB_MEDIATEK |

From: Qianchang Zhao pioooooooooip@gmail.com

[ Upstream commit 991f8a79db99b14c48d20d2052c82d65b9186cad ]

ksmbd maintains delete-on-close and pending-delete state in ksmbd_inode->m_flags. In vfs_cache.c this field is accessed under inconsistent locking: some paths read and modify m_flags under ci->m_lock while others do so without taking the lock at all.

Examples:

- ksmbd_query_inode_status() and __ksmbd_inode_close() use ci->m_lock when checking or updating m_flags. - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close() used to read and modify m_flags without ci->m_lock.

This creates a potential data race on m_flags when multiple threads open, close and delete the same file concurrently. In the worst case delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use).

Fix it by:

- Making ksmbd_query_inode_status() look at m_flags under ci->m_lock after dropping inode_hash_lock. - Adding ci->m_lock protection to all helpers that read or modify m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()). - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(), and moving the actual unlink/xattr removal outside the lock.

This unifies the locking around m_flags and removes the data race while preserving the existing delete-on-close behaviour.

Reported-by: Qianchang Zhao pioooooooooip@gmail.com Reported-by: Zhitong Liu liuzhitong1993@gmail.com Signed-off-by: Qianchang Zhao pioooooooooip@gmail.com Acked-by: Namjae Jeon linkinjeon@kernel.org Signed-off-by: Steve French stfrench@microsoft.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Analysis: ksmbd: vfs: fix race on m_flags in vfs_cache

### 1. Commit Message Analysis

**Bug Description**: The commit fixes a data race on `m_flags` field in ksmbd's VFS cache. Multiple functions access/modify this field with inconsistent locking - some use `ci->m_lock`, others don't.

**Keywords**: "race", "data race", "fix" - clear bug fix language

**Impact described**: "Delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use)"

**Tags present**: - Two `Reported-by:` tags (Qianchang Zhao, Zhitong Liu) - indicates real users hit this bug - `Acked-by:` from Namjae Jeon (ksmbd maintainer) - `Signed-off-by:` from Steve French (SMB maintainer)

**Tags missing**: No `Cc: stable@vger.kernel.org`, no `Fixes:` tag

### 2. Code Change Analysis

The fix is straightforward and mechanical - it adds proper locking around all `m_flags` accesses:

| Function | Change | |----------|--------| | `ksmbd_query_inode_status()` | Moved m_flags check outside inode_hash_lock, added `down_read(&ci->m_lock)` | | `ksmbd_inode_pending_delete()` | Added read lock around flag check | | `ksmbd_set_inode_pending_delete()` | Added write lock around flag modification | | `ksmbd_clear_inode_pending_delete()` | Added write lock around flag modification | | `ksmbd_fd_set_delete_on_close()` | Added write lock around flag modification | | `__ksmbd_inode_close()` | Restructured to hold lock only during flag check/modify, moves I/O (unlink, xattr removal) outside the lock |

The pattern is consistent: acquire lock → read/modify flags → release lock → perform any I/O operations outside lock.

### 3. Classification

**Bug type**: Concurrency bug (data race) - NOT a feature addition - NOT adding new APIs - NOT a cleanup or optimization - This is a correctness fix for a real race condition

### 4. Scope and Risk Assessment

**Scope**: - Single file changed: `fs/smb/server/vfs_cache.c` - ~60 lines of changes - All changes are adding locking around existing operations

**Risk**: LOW - Uses existing `ci->m_lock` rwsem that's already in the structure - No new locking primitives introduced - The restructuring in `__ksmbd_inode_close()` to move I/O outside the lock is actually safer (avoids holding lock during I/O) - Pattern is well-understood: protect shared data with locks

### 5. User Impact

**Who is affected**: Users running ksmbd (in-kernel SMB3 server) with concurrent file access/deletion

**Severity**: MEDIUM-HIGH - File deletion semantics are broken (files may not be deleted when they should be, or disappear unexpectedly) - This affects data integrity expectations - Any ksmbd deployment with multiple concurrent clients could hit this

### 6. Stability Indicators

- Maintainer acks from both ksmbd maintainer (Namjae Jeon) and SMB maintainer (Steve French) - Two independent reporters suggest this is a known/reproducible issue

### 7. Dependencies Check

The fix is self-contained: - Uses existing `ci->m_lock` (already present in `ksmbd_inode` structure) - Uses standard kernel locking APIs (`down_read/up_read`, `down_write/up_write`) - No dependency on other patches

### 8. Stable Tree Applicability

ksmbd was added in Linux 5.15, so this applies to 5.15.y, 6.1.y, 6.6.y, and later stable trees. The code structure appears stable enough that this should apply cleanly.

---

## Summary

**Should this be backported?**

**YES** - This commit should be backported because:

1. **Fixes a real bug**: Data race causing incorrect file deletion behavior that users can actually hit 2. **User-visible impact**: Files not deleted when they should be (delete-on-close failing) or files disappearing unexpectedly 3. **Has real bug reports**: Two Reported-by tags indicate real users encountered this 4. **Small and contained**: Single file, straightforward addition of missing locking 5. **Low regression risk**: Adds locking around existing operations using existing infrastructure 6. **Maintainer approved**: Acked by ksmbd maintainer, signed off by SMB maintainer 7. **Correct fix**: The approach (unify locking around m_flags) is obviously correct

The lack of explicit `Cc: stable` tag is not disqualifying - the nature of the bug (concurrency issue with data integrity implications) and the quality of the fix (mechanical addition of proper locking) make this appropriate stable material.

**YES**

fs/smb/server/vfs_cache.c | 88 +++++++++++++++++++++++++++------------ 1 file changed, 62 insertions(+), 26 deletions(-)

diff --git a/fs/smb/server/vfs_cache.c b/fs/smb/server/vfs_cache.c index dfed6fce89049..6ef116585af64 100644 --- a/fs/smb/server/vfs_cache.c +++ b/fs/smb/server/vfs_cache.c @@ -112,40 +112,62 @@ int ksmbd_query_inode_status(struct dentry *dentry)

read_lock(&inode_hash_lock); ci = __ksmbd_inode_lookup(dentry); - if (ci) { - ret = KSMBD_INODE_STATUS_OK; - if (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)) - ret = KSMBD_INODE_STATUS_PENDING_DELETE; - atomic_dec(&ci->m_count); - } read_unlock(&inode_hash_lock); + if (!ci) + return ret; + + down_read(&ci->m_lock); + if (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)) + ret = KSMBD_INODE_STATUS_PENDING_DELETE; + else + ret = KSMBD_INODE_STATUS_OK; + up_read(&ci->m_lock); + + atomic_dec(&ci->m_count); return ret; }

bool ksmbd_inode_pending_delete(struct ksmbd_file *fp) { - return (fp->f_ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)); + struct ksmbd_inode *ci = fp->f_ci; + int ret; + + down_read(&ci->m_lock); + ret = (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)); + up_read(&ci->m_lock); + + return ret; }

void ksmbd_set_inode_pending_delete(struct ksmbd_file *fp) { - fp->f_ci->m_flags |= S_DEL_PENDING; + struct ksmbd_inode *ci = fp->f_ci; + + down_write(&ci->m_lock); + ci->m_flags |= S_DEL_PENDING; + up_write(&ci->m_lock); }

void ksmbd_clear_inode_pending_delete(struct ksmbd_file *fp) { - fp->f_ci->m_flags &= ~S_DEL_PENDING; + struct ksmbd_inode *ci = fp->f_ci; + + down_write(&ci->m_lock); + ci->m_flags &= ~S_DEL_PENDING; + up_write(&ci->m_lock); }

void ksmbd_fd_set_delete_on_close(struct ksmbd_file *fp, int file_info) { - if (ksmbd_stream_fd(fp)) { - fp->f_ci->m_flags |= S_DEL_ON_CLS_STREAM; - return; - } + struct ksmbd_inode *ci = fp->f_ci;

- fp->f_ci->m_flags |= S_DEL_ON_CLS; + down_write(&ci->m_lock); + if (ksmbd_stream_fd(fp)) + ci->m_flags |= S_DEL_ON_CLS_STREAM; + else + ci->m_flags |= S_DEL_ON_CLS; + up_write(&ci->m_lock); }

static void ksmbd_inode_hash(struct ksmbd_inode *ci) @@ -257,27 +279,41 @@ static void __ksmbd_inode_close(struct ksmbd_file *fp) struct file *filp;

filp = fp->filp; - if (ksmbd_stream_fd(fp) && (ci->m_flags & S_DEL_ON_CLS_STREAM)) { - ci->m_flags &= ~S_DEL_ON_CLS_STREAM; - err = ksmbd_vfs_remove_xattr(file_mnt_idmap(filp), - &filp->f_path, - fp->stream.name, - true); - if (err) - pr_err("remove xattr failed : %s\n", - fp->stream.name); + + if (ksmbd_stream_fd(fp)) { + bool remove_stream_xattr = false; + + down_write(&ci->m_lock); + if (ci->m_flags & S_DEL_ON_CLS_STREAM) { + ci->m_flags &= ~S_DEL_ON_CLS_STREAM; + remove_stream_xattr = true; + } + up_write(&ci->m_lock); + + if (remove_stream_xattr) { + err = ksmbd_vfs_remove_xattr(file_mnt_idmap(filp), + &filp->f_path, + fp->stream.name, + true); + if (err) + pr_err("remove xattr failed : %s\n", + fp->stream.name); + } }

if (atomic_dec_and_test(&ci->m_count)) { + bool do_unlink = false; + down_write(&ci->m_lock); if (ci->m_flags & (S_DEL_ON_CLS | S_DEL_PENDING)) { ci->m_flags &= ~(S_DEL_ON_CLS | S_DEL_PENDING); - up_write(&ci->m_lock); - ksmbd_vfs_unlink(filp); - down_write(&ci->m_lock); + do_unlink = true; } up_write(&ci->m_lock);

+ if (do_unlink) + ksmbd_vfs_unlink(filp); + ksmbd_inode_free(ci); } }

From: Pedro Demarchi Gomes pedrodemargomes@gmail.com

[ Upstream commit d1693a7d5a38acf6424235a6070bcf5b186a360d ]

When mounting, sb->s_blocksize is used to read the boot_block without being defined or validated. Set a dummy blocksize before attempting to read the boot_block.

The issue can be triggered with the following syz reproducer:

mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0) r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0) ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &(0x7f0000000980)=0x4000) mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\x00', &(0x7f0000000000)='ntfs3\x00', 0x2208004, 0x0) syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0)

Here, the ioctl sets the bdev block size to 16384. During mount, get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)), but since block_size(bdev) > PAGE_SIZE, sb_set_blocksize() leaves sb->s_blocksize at zero.

Later, ntfs_init_from_boot() attempts to read the boot_block while sb->s_blocksize is still zero, which triggers the bug.

Reported-by: syzbot+f4f84b57a01d6b8364ad@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f4f84b57a01d6b8364ad Signed-off-by: Pedro Demarchi Gomes pedrodemargomes@gmail.com [almaz.alexandrovich@paragon-software.com: changed comment style, added return value handling] 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 complete picture of the issue. Let me summarize my analysis:

## Summary of Analysis

### The Bug

The commit fixes a bug in ntfs3's `ntfs_init_from_boot()` function where `ntfs_bread()` is called to read the boot block **before** `sb->s_blocksize` is properly set.

### Root Cause Analysis

1. **Mount Flow**: When mounting an ntfs3 filesystem: - `get_tree_bdev()` calls `setup_bdev_super()` which calls `sb_set_blocksize(sb, block_size(bdev))` - If `block_size(bdev) > PAGE_SIZE` (which can happen via ioctl `FS_IOC_SETFLAGS` setting bdev block size to 16384 as shown in the reproducer), and the filesystem doesn't have `FS_LBS` flag, `sb_set_blocksize()` returns 0 and leaves `sb->s_blocksize = 0`

2. **The Crash Path**: In `ntfs_init_from_boot()`: ```c sbi->volume.blocks = dev_size >> PAGE_SHIFT; // sb->s_blocksize is 0 here! bh = ntfs_bread(sb, boot_block); // Uses sb->s_blocksize = 0 ```

3. **Cascade to Infinite Loop**: - `ntfs_bread()` → `sb_bread_unmovable()` → `__bread_gfp()` with size=0 - `bdev_getblk()` → `__getblk_slow()` → `grow_buffers()` → `grow_dev_folio()` → `folio_alloc_buffers()` - In `folio_alloc_buffers()`: `while ((offset -= size) >= 0)` with size=0 causes infinite loop

### The Fix

The fix adds a call to `sb_min_blocksize(sb, PAGE_SIZE)` before attempting to read the boot block:

```c /* Set dummy blocksize to read boot_block. */ if (!sb_min_blocksize(sb, PAGE_SIZE)) { return -EINVAL; } ```

This ensures: 1. `sb->s_blocksize` is set to at least the device's logical block size, capped at PAGE_SIZE 2. If this fails, mount fails gracefully with `-EINVAL` instead of hanging

### Backport Assessment

**STRONG YES signals:** 1. ✅ **Fixes a real crash/hang** - System hangs due to infinite loop in `folio_alloc_buffers()` 2. ✅ **Syzbot reported** - Has syzkaller reproducer (`f4f84b57a01d6b8364ad`) 3. ✅ **Small, surgical fix** - Only 4 lines added 4. ✅ **Clear, obvious fix** - Sets blocksize before using it for reads 5. ✅ **Uses well-established API** - `sb_min_blocksize()` is a standard helper used by many filesystems 6. ✅ **Affects production users** - ntfs3 is widely used (included since 5.15) 7. ✅ **Denial of Service potential** - A local user can trigger the hang

**Risk Assessment:** - **Very Low Risk**: The fix adds a safety check before an I/O operation - **No behavioral change** for normal cases - the blocksize would have been set to PAGE_SIZE anyway after successful boot read - **Graceful failure** if `sb_min_blocksize()` fails (which would be very rare in practice)

**Stable Trees Affected:** - All stable trees with ntfs3: 5.15.y, 6.1.y, 6.6.y, 6.10.y, 6.11.y, etc. - The bug has existed since ntfs3 was introduced in v5.15 - The recent `FS_LBS` change (March 2025) made it easier to trigger but the underlying issue predates it

**Dependencies:** - The fix is standalone and uses existing kernel APIs - No other patches required for backport - `sb_min_blocksize()` has been available since at least 2.6.x

**YES**

fs/ntfs3/super.c | 5 +++++ 1 file changed, 5 insertions(+)

diff --git a/fs/ntfs3/super.c b/fs/ntfs3/super.c index ddff94c091b8c..e6c0908e27c29 100644 --- a/fs/ntfs3/super.c +++ b/fs/ntfs3/super.c @@ -933,6 +933,11 @@ static int ntfs_init_from_boot(struct super_block *sb, u32 sector_size,

sbi->volume.blocks = dev_size >> PAGE_SHIFT;

+ /* Set dummy blocksize to read boot_block. */ + if (!sb_min_blocksize(sb, PAGE_SIZE)) { + return -EINVAL; + } + read_boot: bh = ntfs_bread(sb, boot_block); if (!bh)

From: Konstantin Komarov almaz.alexandrovich@paragon-software.com

[ Upstream commit 5180138604323895b5c291eca6aa7c20be494ade ]

Before it used an unsigned 64-bit type, which prevented proper handling of timestamps earlier than 1970-01-01. Switch to a signed 64-bit type to support pre-epoch timestamps. The issue was caught by xfstests.

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 complete understanding. Let me write the detailed analysis:

## Detailed Analysis

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** `fs/ntfs3: Support timestamps prior to epoch`

**Commit Body:** - The commit explains that before this fix, the code used an **unsigned 64-bit type** (`u64`), which prevented proper handling of timestamps earlier than 1970-01-01 (the Unix epoch). - The fix switches to a **signed 64-bit type** (`s64`) to support pre- epoch timestamps. - The issue was caught by **xfstests test 258**, which specifically tests for timestamps prior to the epoch.

**Tags:** - **No `Cc: stable@vger.kernel.org` tag** is present. - **No `Fixes:` tag** is present.

### 2. CODE CHANGE ANALYSIS

#### The Bug:

In the current code (before the patch):

```980:987:fs/ntfs3/ntfs_fs.h static inline void nt2kernel(const __le64 tm, struct timespec64 *ts) { u64 t = le64_to_cpu(tm) - _100ns2seconds * SecondsToStartOf1970;

// WARNING: do_div changes its first argument(!) ts->tv_nsec = do_div(t, _100ns2seconds) * 100; ts->tv_sec = t; } ```

The variable `t` is declared as `u64` (unsigned 64-bit integer). NTFS timestamps are stored as the number of 100-nanosecond intervals since January 1, 1601. After subtracting `SecondsToStartOf1970` (0x00000002B6109100), which represents the number of seconds between 1601 and 1970, `t` represents a Unix timestamp.

**Problem:** When the NTFS timestamp represents a date before January 1, 1970, the subtraction produces a **negative** result. But since `t` is unsigned (`u64`), the negative value wraps around to a very large positive value, resulting in a wrong (future) timestamp.

**The `do_div` macro** operates on unsigned integers and uses unsigned division, which doesn't handle negative values correctly.

#### The Fix:

The patch changes: 1. `u64 t` → `s64 t` (signed 64-bit integer) 2. `do_div(t, _100ns2seconds)` → `div_s64_rem(t, _100ns2seconds, &t32)` (signed division) 3. Introduces `s32 t32` to hold the remainder

The new code: ```c static inline void nt2kernel(const __le64 tm, struct timespec64 *ts) { s32 t32; /* use signed 64 bit to support timestamps prior to epoch. xfstest 258. */ s64 t = le64_to_cpu(tm) - _100ns2seconds * SecondsToStartOf1970;

ts->tv_sec = div_s64_rem(t, _100ns2seconds, &t32); ts->tv_nsec = t32 * 100; } ```

`div_s64_rem()` is designed for signed 64-bit division with a 32-bit divisor, properly handling negative values and returning the remainder through a pointer.

**Root Cause:** Using unsigned arithmetic for a value that can be negative (pre-epoch timestamps).

### 3. CLASSIFICATION

- **Bug fix:** YES - This is fixing incorrect behavior with timestamps before 1970. - **New feature:** NO - It doesn't add new functionality, only fixes existing functionality. - **Security fix:** NO - No security implications. - **Exception category:** NO - Not a device ID, quirk, DT update, build fix, or documentation fix.

### 4. SCOPE AND RISK ASSESSMENT

**Lines Changed:** Very minimal - changes ~8 lines of code within a single inline function.

**Files Touched:** 1 file (`fs/ntfs3/ntfs_fs.h`)

**Subsystem Complexity:** - NTFS3 is a relatively new filesystem (added in 5.15) - The change is in a core time conversion function `nt2kernel()` that is called whenever reading timestamps from disk - All file timestamps (creation, modification, access times) use this function

**Risk Assessment:** - **LOW RISK** - The change is small, surgical, and uses a well- established kernel API (`div_s64_rem`) - The new code is mathematically equivalent to the old code for timestamps after 1970 - For timestamps before 1970, the new code produces correct results (negative `tv_sec` values) - The `timespec64` structure's `tv_sec` field is `time64_t` which is signed (`__s64`), so it can properly represent negative timestamps

### 5. USER IMPACT

**Who is affected?** - Users of NTFS3 filesystem - Users with NTFS volumes containing files with pre-1970 timestamps

**How severe?** - The bug causes **data corruption** (incorrect timestamp display/storage) for pre-epoch files - Without this fix, timestamps like January 1, 1960 would appear as some date far in the future - This breaks file management tools and any software relying on correct timestamps

**Test Coverage:** - The fix was identified by **xfstests generic/258**, a standard filesystem test that specifically validates pre-epoch timestamp handling - This is a well-known and commonly run test suite

### 6. STABILITY INDICATORS

- **No `Tested-by:` tag** - However, xfstests is mentioned, implying the fix was tested against this test suite - **No `Reviewed-by:` tag** - The commit is from the ntfs3 maintainer (Konstantin Komarov from Paragon Software)

### 7. DEPENDENCY CHECK

- **No dependencies** - This is a standalone fix - Uses existing kernel APIs (`div_s64_rem`, `s64`, `s32`) that have been available for a long time - The affected code (`nt2kernel` function) has existed since ntfs3 was introduced in kernel 5.15

### Summary

**YES signals:** 1. ✅ Fixes a **real bug** (incorrect timestamps for pre-epoch dates) 2. ✅ **Small and surgical** change - only 8 lines changed in one function 3. ✅ **Obviously correct** - uses proper signed arithmetic for values that can be negative 4. ✅ No new features, no new APIs 5. ✅ Caught by **xfstests**, a standard fs test suite (test 258) 6. ✅ Applies to all stable kernels that have ntfs3 (5.15+) 7. ✅ Zero risk of regression for post-epoch timestamps (mathematically equivalent) 8. ✅ Fixes **data integrity issue** (timestamp corruption)

**NO signals:** 1. ⚠️ No explicit `Cc: stable@vger.kernel.org` tag 2. ⚠️ No `Fixes:` tag 3. ⚠️ No `Tested-by:` or `Reviewed-by:` tags

**Verdict:**

This is a clear bug fix that addresses a real issue (incorrect pre-epoch timestamp handling) that affects NTFS3 users. The fix is small, surgical, uses well-tested kernel APIs, and is mathematically correct. While the commit lacks stable tags, the nature of the fix - correcting data integrity issues with timestamps - makes it appropriate for backporting. The bug has existed since ntfs3 was introduced (5.15), so all stable trees with ntfs3 would benefit from this fix.

The lack of `Cc: stable` tag is likely an oversight since the fix clearly meets stable kernel criteria: it's a bug fix, small in scope, obviously correct, and fixes a real user-visible issue (incorrect file timestamps).

**YES**

fs/ntfs3/ntfs_fs.h | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/ntfs3/ntfs_fs.h b/fs/ntfs3/ntfs_fs.h index 630128716ea73..2649fbe16669d 100644 --- a/fs/ntfs3/ntfs_fs.h +++ b/fs/ntfs3/ntfs_fs.h @@ -979,11 +979,12 @@ static inline __le64 kernel2nt(const struct timespec64 *ts) */ static inline void nt2kernel(const __le64 tm, struct timespec64 *ts) { - u64 t = le64_to_cpu(tm) - _100ns2seconds * SecondsToStartOf1970; + s32 t32; + /* use signed 64 bit to support timestamps prior to epoch. xfstest 258. */ + s64 t = le64_to_cpu(tm) - _100ns2seconds * SecondsToStartOf1970;

- // WARNING: do_div changes its first argument(!) - ts->tv_nsec = do_div(t, _100ns2seconds) * 100; - ts->tv_sec = t; + ts->tv_sec = div_s64_rem(t, _100ns2seconds, &t32); + ts->tv_nsec = t32 * 100; }

static inline struct ntfs_sb_info *ntfs_sb(struct super_block *sb)

From: ChenXiaoSong chenxiaosong@kylinos.cn

[ Upstream commit dafe22bc676d4fcb1ccb193c8cc3dda57942509d ]

__process_request() will not print error messages if smb2_query_dir() always returns 0.

Fix this by returning the correct value at the end of function.

Signed-off-by: ChenXiaoSong chenxiaosong@kylinos.cn Acked-by: Namjae Jeon linkinjeon@kernel.org Signed-off-by: Steve French stfrench@microsoft.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Analysis of smb/server: fix return value of smb2_query_dir()

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly states: - `__process_request()` will not print error messages if `smb2_query_dir()` always returns 0 - The fix returns the correct error value `rc` instead of 0

**Notable absences:** - No `Cc: stable@vger.kernel.org` tag - No `Fixes:` tag identifying when the bug was introduced

**Positive signals:** - Acked by Namjae Jeon (ksmbd maintainer) - Signed off by Steve French (SMB maintainer)

### 2. CODE CHANGE ANALYSIS

The change is a single-line fix in the error handling path:

```c - return 0; + return rc; ```

**Technical mechanism of the bug:** Looking at the context, this is in an error handling block where: 1. `rc` contains an error code (-EINVAL, -EACCES, -ENOENT, -EBADF, -ENOMEM, -EFAULT, or -EIO) 2. The appropriate SMB status is set in `rsp->hdr.Status` 3. Error response is prepared with `smb2_set_err_rsp(work)` 4. Cleanup is done with `ksmbd_fd_put()` and `ksmbd_revert_fsids()` 5. **BUG**: The function returns 0 (success) instead of `rc` (the actual error)

**Root cause:** The caller `__process_request()` uses the return value to determine if an error occurred. Returning 0 masks all errors, preventing proper error logging and handling.

### 3. CLASSIFICATION

This is a **bug fix** - incorrect error return value handling. The function was silently discarding error information that callers need.

### 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment | |--------|------------| | Lines changed | 1 | | Files touched | 1 | | Complexity | Trivial | | Subsystem | ksmbd (kernel SMB server) | | Risk level | **Very Low** |

The fix is surgical and obviously correct - the `rc` variable already contains the appropriate error code, it just wasn't being returned.

### 5. USER IMPACT

- **Affected users:** ksmbd server users - **Severity:** Medium - error conditions in directory queries are not properly reported - **Consequences of the bug:** - Error messages not printed when they should be - Callers may not handle error conditions properly - Debugging ksmbd issues becomes harder

### 6. STABILITY INDICATORS

- Acked by ksmbd maintainer - Signed off by SMB maintainer - Simple, self-contained change

### 7. DEPENDENCY CHECK

- No dependencies on other commits - ksmbd has been in the kernel since 5.15 - The fix applies to existing code paths

### STABLE KERNEL CRITERIA EVALUATION

| Criterion | Met? | Notes | |-----------|------|-------| | Obviously correct | ✅ | Trivially correct - return error code instead of 0 | | Fixes real bug | ✅ | Error propagation was broken | | Small and contained | ✅ | Single line change | | No new features | ✅ | Pure bug fix | | Tested | ⚠️ | No Tested-by tag, but very low risk |

### RISK VS BENEFIT

**Benefits:** - Fixes broken error propagation in ksmbd directory queries - Enables proper error logging for debugging - Very low risk due to trivial nature of fix

**Risks:** - Minimal - the change is from "always return 0" to "return actual error code" - Behavior change only affects error paths

### CONCLUSION

This is a straightforward, obviously correct bug fix. The function was incorrectly returning 0 (success) in all error cases, causing error information to be lost. The fix is a single line change that returns the actual error code that was already being computed.

While the commit lacks explicit stable tags, it meets all stable criteria: obviously correct, fixes a real bug affecting error handling, trivially small scope, and no new features. The risk is minimal and the fix improves error handling in ksmbd.

**YES**

fs/smb/server/smb2pdu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index f901ae18e68ad..8975b6f2f5800 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -4560,7 +4560,7 @@ int smb2_query_dir(struct ksmbd_work *work) smb2_set_err_rsp(work); ksmbd_fd_put(work, dir_fp); ksmbd_revert_fsids(work); - return 0; + return rc; }

/**

From: Chingbin Li liqb365@163.com

[ Upstream commit 8dbbb5423c0802ec21266765de80fd491868fab1 ]

Add VID 2b89 & PID 6275 for Realtek RTL8761BUV USB Bluetooth chip.

The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below.

T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2b89 ProdID=6275 Rev= 2.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00E04C239987 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms

Signed-off-by: Chingbin Li liqb365@163.com Signed-off-by: Luiz Augusto von Dentz luiz.von.dentz@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: Bluetooth: btusb: Add new VID/PID 2b89/6275 for RTL8761BUV

### 1. COMMIT MESSAGE ANALYSIS

- **Subject:** Adding a USB VID (0x2b89) / PID (0x6275) for a Realtek RTL8761BUV Bluetooth chip - **No "Fixes:" tag** - This is not fixing a code bug - **No "Cc: stable@vger.kernel.org"** - Not explicitly tagged for stable - **Evidence of real hardware:** The commit includes detailed USB device information from `/sys/kernel/debug/usb/devices`, showing the contributor has physical access to the device

### 2. CODE CHANGE ANALYSIS

The change is minimal - just 2 lines added to `drivers/bluetooth/btusb.c`:

```c { USB_DEVICE(0x2b89, 0x6275), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, ```

This entry: - Is added to the `quirks_table[]` array in the "Additional Realtek 8761BUV Bluetooth devices" section - Uses the exact same pattern and flags as other RTL8761BUV entries - The same vendor ID (0x2b89) already exists with a different product ID (0x8761)

### 3. CLASSIFICATION

This is a **NEW DEVICE ID** addition - one of the explicitly allowed exceptions for stable trees: - Adds a USB ID to an existing, mature driver (btusb) - The btusb driver already fully supports RTL8761BUV chips - Only the device ID is new, not any driver functionality

### 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment | |--------|------------| | Lines changed | 2 | | Files touched | 1 | | Complexity | Trivial - mechanical ID table addition | | Risk of regression | Essentially zero | | Pattern precedent | Exact same pattern used by dozens of other entries |

The risk is **extremely low** because: - The new entry cannot affect any existing devices - It only matches the specific VID/PID combination - All the handling code (BTUSB_REALTEK, BTUSB_WIDEBAND_SPEECH) is already tested with similar hardware

### 5. USER IMPACT

- **Affected users:** Anyone with a Bluetooth USB adapter using VID 0x2b89 and PID 0x6275 - **Without the patch:** The device is not recognized, Bluetooth does not work at all - **With the patch:** Full Bluetooth functionality via the mature btusb driver

This is a complete enablement fix for affected hardware.

### 6. STABILITY INDICATORS

- Signed-off-by from the Bluetooth subsystem maintainer (Luiz Augusto von Dentz) - Follows established patterns exactly - USB device info in commit shows real-world testing on actual hardware

### 7. DEPENDENCY CHECK

- **No dependencies** on other commits - The required flags (BTUSB_REALTEK, BTUSB_WIDEBAND_SPEECH) have existed for years - Will apply cleanly to all stable trees with btusb support

---

## Summary

This commit is a textbook example of a stable-appropriate device ID addition:

**Pros:** - Trivial 2-line change adding a USB VID/PID - Zero risk of regression - only affects the specific new device - Enables real hardware for users who otherwise have no Bluetooth - Follows exact pattern used by many other stable-backported device ID additions - Already merged by subsystem maintainer

**Cons:** - No explicit stable tag (but not required for device ID additions) - No Fixes: tag (appropriate - this isn't fixing broken code)

**Risk vs Benefit:** Near-zero risk with clear benefit for hardware owners.

Per the stable kernel rules, device ID additions to existing drivers are explicitly appropriate for backporting. They are small, obviously correct, fix a real user problem (hardware not working), and cannot introduce regressions.

**YES**

drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 9b199da1c0d67..cc03c8c38b16f 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -785,6 +785,8 @@ static const struct usb_device_id quirks_table[] = { BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x2b89, 0x8761), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x2b89, 0x6275), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH },

/* Additional Realtek 8821AE Bluetooth devices */ { USB_DEVICE(0x0b05, 0x17dc), .driver_info = BTUSB_REALTEK },

From: Viacheslav Dubeyko slava@dubeyko.com

[ Upstream commit ed490f36f439b877393c12a2113601e4145a5a56 ]

The xfstests' test-case generic/070 leaves HFS+ volume in corrupted state:

sudo ./check generic/070 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.17.0-rc1+ #4 SMP PREEMPT_DYNAMIC Wed Oct 1 15:02:44 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/070 _check_generic_filesystem: filesystem on /dev/loop50 is inconsistent (see xfstests-dev/results//generic/070.full for details)

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

sudo fsck.hfsplus -d /dev/loop50 ** /dev/loop50 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. Executing fsck_hfs (version 540.1-Linux). ** Checking non-journaled HFS Plus Volume. The volume name is test ** Checking extents overflow file. Unused node is not erased (node = 1) ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0004 CBTStat = 0x0000 CatStat = 0x00000000 ** Repairing volume. ** Rechecking volume. ** Checking non-journaled HFS Plus Volume. The volume name is test ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume test was repaired successfully.

It is possible to see that fsck.hfsplus detected not erased and unused node for the case of extents overflow file. The HFS+ logic has special method that defines if the node should be erased:

bool hfs_bnode_need_zeroout(struct hfs_btree *tree) { struct super_block *sb = tree->inode->i_sb; struct hfsplus_sb_info *sbi = HFSPLUS_SB(sb); const u32 volume_attr = be32_to_cpu(sbi->s_vhdr->attributes);

return tree->cnid == HFSPLUS_CAT_CNID && volume_attr & HFSPLUS_VOL_UNUSED_NODE_FIX; }

However, it is possible to see that this method works only for the case of catalog file. But debugging of the issue has shown that HFSPLUS_VOL_UNUSED_NODE_FIX attribute has been requested for the extents overflow file too:

catalog file kernel: hfsplus: node 4, num_recs 0, flags 0x10 kernel: hfsplus: tree->cnid 4, volume_attr 0x80000800

extents overflow file kernel: hfsplus: node 1, num_recs 0, flags 0x10 kernel: hfsplus: tree->cnid 3, volume_attr 0x80000800

This patch modifies the hfs_bnode_need_zeroout() by checking only volume_attr but not the b-tree ID because node zeroing can be requested for all HFS+ b-tree types.

sudo ./check generic/070 FSTYP -- hfsplus PLATFORM -- Linux/x86_64 hfsplus-testing-0001 6.18.0-rc3+ #79 SMP PREEMPT_DYNAMIC Fri Oct 31 16:07:42 PDT 2025 MKFS_OPTIONS -- /dev/loop51 MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/070 33s ... 34s Ran: generic/070 Passed all 1 tests

Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com cc: John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de cc: Yangtao Li frank.li@vivo.com cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/20251101001229.247432-1-slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Final Assessment

### Summary of Findings

**Bug Type**: Filesystem corruption (data integrity issue)

**Technical Root Cause**: The `hfs_bnode_need_zeroout()` function incorrectly restricts unused node zeroing to only the catalog B-tree (HFSPLUS_CAT_CNID). However, when the volume attribute `HFSPLUS_VOL_UNUSED_NODE_FIX` is set, it applies to ALL HFS+ B-tree types including the extents overflow file. This causes fsck.hfsplus to detect corruption: "Unused node is not erased (node = 1)".

**The Fix**: Removes the catalog-only check, allowing node zeroing for all B-tree types when the volume attribute is set.

### Stable Kernel Criteria Evaluation

| Criterion | Status | |-----------|--------| | Fixes real bug | ✅ Filesystem corruption verified by fsck | | Obviously correct | ✅ Simple condition removal, matches Apple spec | | Small and contained | ✅ 1 line change, single file | | No new features | ✅ No new functionality added | | Tested | ✅ xfstests generic/070 passes | | Exists in stable | ✅ Function introduced in kernel 3.16 (2014) |

### Risk vs Benefit

**Risk**: Very LOW - The change makes code more conservative (zeros more nodes, not fewer) - Only two call sites, both appropriately handle the result - No new code paths, just relaxing an incorrect restriction

**Benefit**: HIGH - Fixes filesystem corruption that users can actually hit - Reproducible with standard xfstests suite - Prevents data integrity issues on HFS+ volumes

### Concerns

1. **No explicit stable tags**: Missing "Cc: stable" and "Fixes:" tags. However, filesystem corruption fixes are exactly what stable is for.

2. **Stale comment**: The comment still says "if this is the catalog tree" but this is documentation debt, not a functional issue.

3. **Limited user base**: HFS+ is less commonly used on Linux than other filesystems, but users who do use it deserve working support.

### Conclusion

This commit fixes a real, reproducible filesystem corruption issue with an extremely small, safe change. The fix is obviously correct - it aligns behavior with the HFS+ specification where `HFSPLUS_VOL_UNUSED_NODE_FIX` applies to all B-trees, not just the catalog. The change is conservative (does more work, not less) minimizing regression risk. The affected code has existed since kernel 3.16, making it applicable to all active stable trees.

Despite the missing explicit stable tags, this is clearly appropriate stable material - a surgical fix for data corruption that meets all the technical criteria.

**YES**

fs/hfsplus/bnode.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/hfsplus/bnode.c b/fs/hfsplus/bnode.c index 63768cf0cb1ba..482a6c5faa197 100644 --- a/fs/hfsplus/bnode.c +++ b/fs/hfsplus/bnode.c @@ -705,6 +705,5 @@ bool hfs_bnode_need_zeroout(struct hfs_btree *tree) struct hfsplus_sb_info *sbi = HFSPLUS_SB(sb); const u32 volume_attr = be32_to_cpu(sbi->s_vhdr->attributes);

- return tree->cnid == HFSPLUS_CAT_CNID && - volume_attr & HFSPLUS_VOL_UNUSED_NODE_FIX; + return volume_attr & HFSPLUS_VOL_UNUSED_NODE_FIX; }

From: Yang Chenzhi yang.chenzhi@vivo.com

[ Upstream commit 152af114287851583cf7e0abc10129941f19466a ]

When sync() and link() are called concurrently, both threads may enter hfs_bnode_find() without finding the node in the hash table and proceed to create it.

Thread A: hfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)

Thread B: hfsplus_create_cat() -> hfs_brec_insert() -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)

In this case, thread A creates the bnode, sets refcnt=1, and hashes it. Thread B also tries to create the same bnode, notices it has already been inserted, drops its own instance, and uses the hashed one without getting the node.

```

node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- Thread A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node; tree->node_hash_cnt++; } else { <- Thread B spin_unlock(&tree->hash_lock); kfree(node); wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags)); return node2; } ```

However, hfs_bnode_find() requires each call to take a reference. Here both threads end up setting refcnt=1. When they later put the node, this triggers:

BUG_ON(!atomic_read(&node->refcnt))

In this scenario, Thread B in fact finds the node in the hash table rather than creating a new one, and thus must take a reference.

Fix this by calling hfs_bnode_get() when reusing a bnode newly created by another thread to ensure the refcount is updated correctly.

A similar bug was fixed in HFS long ago in commit a9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create") but the same issue remained in HFS+ until now.

Reported-by: syzbot+005d2a9ecd9fbf525f6a@syzkaller.appspotmail.com Signed-off-by: Yang Chenzhi yang.chenzhi@vivo.com Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Link: https://lore.kernel.org/r/20250829093912.611853-1-yang.chenzhi@vivo.com Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Analysis Summary

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** "hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create"

**Key signals:** - Clear "fix" keyword indicating bug fix - Reported-by syzbot - reproducible crash bug - Detailed race condition explanation with call stacks - References identical HFS fix from 2022 (commit a9dc087fd3c4) - No explicit `Cc: stable` tag, but no `Fixes:` tag either since the bug exists from the file's creation

### 2. CODE CHANGE ANALYSIS

**The Bug:** When `sync()` and `link()` are called concurrently, both threads may race into `__hfs_bnode_create()`: - Thread A creates a bnode with `refcnt=1` and inserts it into the hash table - Thread B finds the hash table entry, but returns the node **without incrementing refcnt** - Both threads believe they own a reference, but only one reference exists - When both call `hfs_bnode_put()`, the second call triggers: `BUG_ON(!atomic_read(&node->refcnt))`

**The Fix:** Single line addition at `fs/hfsplus/bnode.c:484`: ```c } else { + hfs_bnode_get(node2); // <-- Missing refcount increment added spin_unlock(&tree->hash_lock); kfree(node); ```

**Why it's correct:** `hfs_bnode_get()` simply does `atomic_inc(&node->refcnt)` (line 658), ensuring correct reference counting when reusing a shared bnode.

### 3. CLASSIFICATION

- **Bug fix:** YES - fixes a crash (BUG_ON kernel panic) - **Feature addition:** NO - **Security consideration:** Crash can be triggered by normal operations - potential DoS vector

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Value | |--------|-------| | Lines changed | 1 | | Files touched | 1 | | Complexity | Very low | | Subsystem | HFS+ filesystem | | Regression risk | Very low |

The fix is a **single function call** that mirrors a proven fix from HFS (commit a9dc087fd3c4) that has been stable since December 2022.

### 5. USER IMPACT

- **Affected users:** Anyone using HFS+ filesystems (common for Mac disk compatibility, external drives, dual-boot systems) - **Trigger condition:** Concurrent sync() and link() operations - can occur in normal workloads - **Severity:** **KERNEL CRASH** (BUG_ON triggers panic)

### 6. STABILITY INDICATORS

- **syzbot reported:** Bug is reproducible - **Maintainer signed:** Yes (Viacheslav Dubeyko, HFS+ maintainer) - **LKML link:** Present - **Precedent:** Identical fix applied to HFS in 2022 with no regressions

### 7. DEPENDENCY CHECK

- **Dependencies:** None - completely self-contained - **Applies to stable:** The affected code pattern has existed unchanged for many years in stable trees

## Final Assessment

**This commit should be backported to stable kernels.**

**Rationale:** 1. **Fixes a real crash** - BUG_ON triggers kernel panic in a reproducible race condition 2. **Minimal and surgical** - Single line change adding one function call 3. **Obviously correct** - Adds missing reference count increment, matching HFS pattern 4. **Proven safe** - Identical fix in HFS has been stable for 2+ years 5. **No dependencies** - Will apply cleanly to all stable kernels 6. **Real user impact** - HFS+ is commonly used for Mac disk compatibility

The lack of explicit `Cc: stable` tag does not preclude backporting when all other stable criteria are clearly met. This is a textbook case of a small, obviously correct fix for a real crash bug.

**YES**

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

diff --git a/fs/hfsplus/bnode.c b/fs/hfsplus/bnode.c index 63e652ad1e0de..63768cf0cb1ba 100644 --- a/fs/hfsplus/bnode.c +++ b/fs/hfsplus/bnode.c @@ -481,6 +481,7 @@ static struct hfs_bnode *__hfs_bnode_create(struct hfs_btree *tree, u32 cnid) tree->node_hash[hash] = node; tree->node_hash_cnt++; } else { + hfs_bnode_get(node2); spin_unlock(&tree->hash_lock); kfree(node); wait_event(node2->lock_wq,

From: Mikhail Malyshev mike.malyshev@gmail.com

[ Upstream commit af61da281f52aba0c5b090bafb3a31c5739850ff ]

When building out-of-tree modules with CONFIG_MODULE_SIG_FORCE=y, module signing fails because the private key path uses $(srctree) while the public key path uses $(objtree). Since signing keys are generated in the build directory during kernel compilation, both paths should use $(objtree) for consistency.

This causes SSL errors like: SSL error:02001002:system library:fopen:No such file or directory sign-file: /kernel-src/certs/signing_key.pem

The issue occurs because: - sig-key uses: $(srctree)/certs/signing_key.pem (source tree) - cmd_sign uses: $(objtree)/certs/signing_key.x509 (build tree)

But both keys are generated in $(objtree) during the build.

This complements commit 25ff08aa43e37 ("kbuild: Fix signing issue for external modules") which fixed the scripts path and public key path, but missed the private key path inconsistency.

Fixes out-of-tree module signing for configurations with separate source and build directories (e.g., O=/kernel-out).

Signed-off-by: Mikhail Malyshev mike.malyshev@gmail.com Reviewed-by: Nathan Chancellor nathan@kernel.org Tested-by: Nicolas Schier nsc@kernel.org Link: https://patch.msgid.link/20251015163452.3754286-1-mike.malyshev@gmail.com Signed-off-by: Nicolas Schier nsc@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Now I have the complete picture. All stable trees that contain commit 13b25489b6f8 (v6.13+) have the incomplete fix and need this patch. Let me finalize my analysis:

## Complete Analysis

### 1. COMMIT MESSAGE ANALYSIS

The commit message is clear and well-documented: - **Subject**: "kbuild: Use objtree for module signing key path" - clearly states what it does - **Body**: Explains the problem with detailed error messages and root cause analysis - **References**: Explicitly mentions commit 25ff08aa43e37 as the incomplete fix it complements - **No Cc: stable@vger.kernel.org tag** - the maintainer did not explicitly request stable backport - **No Fixes: tag** - However, logically this fixes the same issue as 25ff08aa43e37, which has `Fixes: 13b25489b6f8` - **Has Reviewed-by and Tested-by tags** from Nicolas Schier and Nathan Chancellor

### 2. CODE CHANGE ANALYSIS

The change is a **single character change** (literally changing one word):

```makefile # Before: sig-key := $(if $(wildcard $(CONFIG_MODULE_SIG_KEY)),,$(srctree)/)$(CONFIG_MODULE_SIG_KEY)

# After: sig-key := $(if $(wildcard $(CONFIG_MODULE_SIG_KEY)),,$(objtree)/)$(CONFIG_MODULE_SIG_KEY) ```

**Technical mechanism of the bug:** 1. When building out-of-tree modules with `CONFIG_MODULE_SIG_FORCE=y` and separate source/build directories (e.g., `O=/kernel-out`): - `$(srctree)` points to the source tree (e.g., `/kernel-src`) - `$(objtree)` points to the build tree (e.g., `/kernel-out`)

2. Module signing keys are **generated during kernel compilation** and stored in `$(objtree)/certs/`: - Private key: `$(objtree)/certs/signing_key.pem` - Public key: `$(objtree)/certs/signing_key.x509`

3. After commit 25ff08aa43e37, `cmd_sign` correctly uses `$(objtree)/certs/signing_key.x509` for the public key, but `sig-key` still uses `$(srctree)/certs/signing_key.pem` for the private key.

4. This creates an **inconsistency**: The `sign-file` tool is called with: - Private key: `/kernel-src/certs/signing_key.pem` (WRONG - file doesn't exist there) - Public key: `/kernel-out/certs/signing_key.x509` (CORRECT)

5. Result: `fopen()` fails with "No such file or directory" when trying to open the private key.

**Why the fix is correct:** - Both signing keys are generated in `$(objtree)`, so both paths should reference `$(objtree)` - The fix is logically consistent with what commit 25ff08aa43e37 did for the other paths - The conditional `$(if $(wildcard $(CONFIG_MODULE_SIG_KEY)),,$(objtree)/)` only adds the prefix if the key path is not absolute, which is correct behavior

### 3. CLASSIFICATION

- **Type**: Bug fix (not a feature) - **Category**: Build system fix - **Severity**: Causes complete failure of out-of-tree module signing with CONFIG_MODULE_SIG_FORCE=y - **Security relevance**: Low (doesn't fix a security vulnerability per se, but affects security feature - module signing) - **Exception category**: Build fix - these are explicitly allowed in stable

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: 1 line (trivial) - **Files touched**: 1 file (`scripts/Makefile.modinst`) - **Complexity**: Extremely simple - just changing `srctree` to `objtree` - **Subsystem**: kbuild (build system) - **Risk level**: **VERY LOW** - Only affects out-of-tree module signing with separate source/build directories - Only affects configurations with `CONFIG_MODULE_SIG_FORCE=y` or `CONFIG_MODULE_SIG_ALL=y` - The change is logically correct and consistent with the rest of the code - Cannot break anything that was working before

### 5. USER IMPACT

- **Who is affected**: - Users building out-of-tree modules (e.g., NVIDIA drivers, VirtualBox, ZFS) - With separate source and build directories (`O=/path/to/build`) - With module signature enforcement enabled - **Severity**: HIGH for affected users - module signing completely fails - **User reports**: The commit message shows this was reported as a real user problem with specific error messages - **Prevalence**: Common scenario for distribution builders and enterprise environments

### 6. STABILITY INDICATORS

- **Tested-by: Nicolas Schier** - the kbuild maintainer tested it - **Reviewed-by: Nathan Chancellor** - well-known kernel developer reviewed it - **Link to patch discussion**: Shows proper review process - **Age in mainline**: This appears to be a recent commit (October 2025 in the patch date)

### 7. DEPENDENCY CHECK

**Critical finding**: This commit has a dependency: - It requires commit **25ff08aa43e37** ("kbuild: Fix signing issue for external modules") to be present first - 25ff08aa43e37 requires commit **13b25489b6f8** ("kbuild: change working directory to external module directory with M=")

**Affected stable versions**: - v6.13.x: Has 13b25489b6f8 (the bug) and backported 25ff08aa43e37 (partial fix) → **NEEDS this patch** - v6.14.x: Has both 13b25489b6f8 and 25ff08aa43e37 → **NEEDS this patch** - v6.15.x: Has both → **NEEDS this patch** - v6.16.x: Has both → **NEEDS this patch** - v6.17.x: Has both → **NEEDS this patch** - v6.6.x and older: Does NOT have 13b25489b6f8 → **Does NOT need this patch** (and would break if applied)

**Backport note**: This commit should ONLY be backported to stable trees that already have: 1. Commit 13b25489b6f8 (the original behavior change) 2. Commit 25ff08aa43e37 (the partial fix)

This means v6.13+ stable trees only.

### SUMMARY

This commit is an **excellent candidate for stable backport** to kernel versions v6.13+:

**Positive factors:** 1. ✅ Fixes a real bug that causes complete failure of module signing 2. ✅ Extremely small change (1 line, 1 word) 3. ✅ Zero risk of regression (only fixes broken behavior) 4. ✅ Properly reviewed and tested by kbuild maintainers 5. ✅ Complements an existing fix that was already backported to stable 6. ✅ Build fix category - explicitly allowed in stable rules 7. ✅ Clear, well-documented commit message 8. ✅ Affects users who follow best practices (separate build directory)

**Concerns:** 1. ⚠️ No explicit `Cc: stable@vger.kernel.org` tag (but the first fix also didn't have one and was still backported) 2. ⚠️ No explicit `Fixes:` tag (but logically fixes the same issue as 25ff08aa43e37) 3. ⚠️ Must only be applied to v6.13+ stable trees (where 13b25489b6f8 exists)

The commit passes all stable kernel criteria: it's obviously correct, fixes a real user-visible bug, is small and surgical, has no new features, and has been tested. The incomplete fix in stable trees is currently causing module signing to fail for users with separate source/build directories.

**YES**

scripts/Makefile.modinst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst index 1628198f3e830..9ba45e5b32b18 100644 --- a/scripts/Makefile.modinst +++ b/scripts/Makefile.modinst @@ -100,7 +100,7 @@ endif # Don't stop modules_install even if we can't sign external modules. # ifeq ($(filter pkcs11:%, $(CONFIG_MODULE_SIG_KEY)),) -sig-key := $(if $(wildcard $(CONFIG_MODULE_SIG_KEY)),,$(srctree)/)$(CONFIG_MODULE_SIG_KEY) +sig-key := $(if $(wildcard $(CONFIG_MODULE_SIG_KEY)),,$(objtree)/)$(CONFIG_MODULE_SIG_KEY) else sig-key := $(CONFIG_MODULE_SIG_KEY) endif

From: Alan Maguire alan.maguire@oracle.com

[ Upstream commit 380d19db6e6c089c7d2902e02a85fd2bde3e519b ]

drivers/net/ethernet/chelsio/cxgb4/sched.h declares a sched_class struct which has a type name clash with struct sched_class in kernel/sched/sched.h (a type used in a field in task_struct).

When cxgb4 is a builtin we end up with both sched_class types, and as a result of this we wind up with DWARF (and derived from that BTF) with a duplicate incorrect task_struct representation. When cxgb4 is built-in this type clash can cause kernel builds to fail as resolve_btfids will fail when confused which task_struct to use. See [1] for more details.

As such, renaming sched_class to ch_sched_class (in line with other structs like ch_sched_flowc) makes sense.

[1] https://lore.kernel.org/bpf/2412725b-916c-47bd-91c3-c2d57e3e6c7b@acm.org/

Reported-by: Bart Van Assche bvanassche@acm.org Reviewed-by: Bart Van Assche bvanassche@acm.org Signed-off-by: Alan Maguire alan.maguire@oracle.com Acked-by: Potnuri Bharat Teja bharat@chelsio.com Link: https://patch.msgid.link/20251121181231.64337-1-alan.maguire@oracle.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: cxgb4 sched_class rename

### 1. COMMIT MESSAGE ANALYSIS

The commit addresses a **type name clash** between: - `struct sched_class` in `drivers/net/ethernet/chelsio/cxgb4/sched.h` (cxgb4 driver's scheduling class) - `struct sched_class` in `kernel/sched/sched.h` (core scheduler's scheduling class used in task_struct)

**Problem:** When cxgb4 is built-in (CONFIG_CHELSIO_T4=y), both types exist in the same compilation unit. This causes: 1. Duplicate DWARF/BTF type representations 2. **Build failures** because `resolve_btfids` tool cannot determine which `task_struct` to use

**Signals:** - **Reported-by:** Bart Van Assche (real user hit this issue) - **Reviewed-by/Acked-by:** Present from both reporter and driver maintainer - **Link:** References actual bug report on lore.kernel.org - **No Cc: stable** tag - **No Fixes:** tag

### 2. CODE CHANGE ANALYSIS

The fix is purely mechanical - a simple rename: - `struct sched_class` → `struct ch_sched_class` (following existing naming convention like `ch_sched_flowc`)

Changes across 5 files are all straightforward variable type name replacements. The diff shows ~20 locations where the type name is changed, with absolutely no logic modifications.

### 3. CLASSIFICATION

This is a **BUILD FIX** - one of the explicitly allowed categories for stable backporting. The build fails when: - cxgb4 driver is built-in - BTF debugging is enabled (CONFIG_DEBUG_INFO_BTF=y)

The `resolve_btfids` tool fails, preventing successful kernel compilation.

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Assessment | |--------|------------| | Lines changed | ~40 (all renames) | | Files touched | 5 (all within cxgb4 driver) | | Logic changes | **ZERO** | | External API changes | **NONE** | | Runtime risk | **NONE** - purely compile-time symbol naming |

**Risk Level: EXTREMELY LOW** - This cannot cause any runtime regression as it's purely a symbol rename with no behavioral changes whatsoever.

### 5. USER IMPACT

**Affected users:** - Those building kernels with cxgb4 built-in AND BTF enabled - This is a realistic configuration for users doing BPF/tracing work with Chelsio network hardware

**Severity:** BUILD FAILURE - Complete inability to compile the kernel for affected configurations.

### 6. STABILITY INDICATORS

- Has Reviewed-by and Acked-by tags - Change is mechanical and obviously correct - Merged through proper netdev maintainer path - The naming follows existing driver conventions (`ch_sched_*`)

### 7. DEPENDENCY CHECK

The change is self-contained within the cxgb4 driver. No external dependencies. The cxgb4 scheduler code has existed in stable trees for years, so this fix should apply cleanly.

### Decision Analysis

**FOR backporting:** 1. **Build fix** - explicitly allowed in stable rules 2. **Zero runtime risk** - purely a type rename, no logic changes 3. **Fixes real bug** - reported by actual user, blocks compilation 4. **Small and contained** - all changes within one driver 5. **Obviously correct** - mechanical rename following existing conventions

**AGAINST backporting:** 1. No `Cc: stable` tag from maintainer 2. Affected configuration (built-in cxgb4 + BTF) is somewhat niche 3. Issue may only manifest with newer toolchains

### Conclusion

While the maintainer didn't add `Cc: stable`, this is a **legitimate build fix** that prevents kernel compilation for users with specific (but valid) configurations. Build fixes are explicitly listed as acceptable stable material in the kernel's stable rules. The change is mechanical, trivial, and carries effectively zero risk of any regression. Users who update their build toolchain on stable kernels could encounter this failure.

The risk/benefit ratio strongly favors backporting: **zero risk** vs **fixing build failures**.

**YES**

.../net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 +- .../chelsio/cxgb4/cxgb4_tc_matchall.c | 4 +- .../ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c | 2 +- drivers/net/ethernet/chelsio/cxgb4/sched.c | 44 +++++++++---------- drivers/net/ethernet/chelsio/cxgb4/sched.h | 12 ++--- 5 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c index 392723ef14e51..ac0c7fe5743bd 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c @@ -3485,7 +3485,7 @@ static int cxgb_set_tx_maxrate(struct net_device *dev, int index, u32 rate) struct adapter *adap = pi->adapter; struct ch_sched_queue qe = { 0 }; struct ch_sched_params p = { 0 }; - struct sched_class *e; + struct ch_sched_class *e; u32 req_rate; int err = 0;

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c index 1672d3afe5bef..f8dcf0b4abcdc 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_matchall.c @@ -56,7 +56,7 @@ static int cxgb4_matchall_egress_validate(struct net_device *dev, struct port_info *pi = netdev2pinfo(dev); struct flow_action_entry *entry; struct ch_sched_queue qe; - struct sched_class *e; + struct ch_sched_class *e; u64 max_link_rate; u32 i, speed; int ret; @@ -180,7 +180,7 @@ static int cxgb4_matchall_alloc_tc(struct net_device *dev, struct port_info *pi = netdev2pinfo(dev); struct adapter *adap = netdev2adap(dev); struct flow_action_entry *entry; - struct sched_class *e; + struct ch_sched_class *e; int ret; u32 i;

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c index 338b04f339b3d..a2dcd2e242631 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_mqprio.c @@ -330,7 +330,7 @@ static int cxgb4_mqprio_alloc_tc(struct net_device *dev, struct cxgb4_tc_port_mqprio *tc_port_mqprio; struct port_info *pi = netdev2pinfo(dev); struct adapter *adap = netdev2adap(dev); - struct sched_class *e; + struct ch_sched_class *e; int ret; u8 i;

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.c b/drivers/net/ethernet/chelsio/cxgb4/sched.c index a1b14468d1fff..38a30aeee1220 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/sched.c +++ b/drivers/net/ethernet/chelsio/cxgb4/sched.c @@ -44,7 +44,7 @@ static int t4_sched_class_fw_cmd(struct port_info *pi, { struct adapter *adap = pi->adapter; struct sched_table *s = pi->sched_tbl; - struct sched_class *e; + struct ch_sched_class *e; int err = 0;

e = &s->tab[p->u.params.class]; @@ -122,7 +122,7 @@ static void *t4_sched_entry_lookup(struct port_info *pi, const u32 val) { struct sched_table *s = pi->sched_tbl; - struct sched_class *e, *end; + struct ch_sched_class *e, *end; void *found = NULL;

/* Look for an entry with matching @val */ @@ -166,8 +166,8 @@ static void *t4_sched_entry_lookup(struct port_info *pi, return found; }

-struct sched_class *cxgb4_sched_queue_lookup(struct net_device *dev, - struct ch_sched_queue *p) +struct ch_sched_class *cxgb4_sched_queue_lookup(struct net_device *dev, + struct ch_sched_queue *p) { struct port_info *pi = netdev2pinfo(dev); struct sched_queue_entry *qe = NULL; @@ -187,7 +187,7 @@ static int t4_sched_queue_unbind(struct port_info *pi, struct ch_sched_queue *p) struct sched_queue_entry *qe = NULL; struct adapter *adap = pi->adapter; struct sge_eth_txq *txq; - struct sched_class *e; + struct ch_sched_class *e; int err = 0;

if (p->queue < 0 || p->queue >= pi->nqsets) @@ -218,7 +218,7 @@ static int t4_sched_queue_bind(struct port_info *pi, struct ch_sched_queue *p) struct sched_queue_entry *qe = NULL; struct adapter *adap = pi->adapter; struct sge_eth_txq *txq; - struct sched_class *e; + struct ch_sched_class *e; unsigned int qid; int err = 0;

@@ -260,7 +260,7 @@ static int t4_sched_flowc_unbind(struct port_info *pi, struct ch_sched_flowc *p) { struct sched_flowc_entry *fe = NULL; struct adapter *adap = pi->adapter; - struct sched_class *e; + struct ch_sched_class *e; int err = 0;

if (p->tid < 0 || p->tid >= adap->tids.neotids) @@ -288,7 +288,7 @@ static int t4_sched_flowc_bind(struct port_info *pi, struct ch_sched_flowc *p) struct sched_table *s = pi->sched_tbl; struct sched_flowc_entry *fe = NULL; struct adapter *adap = pi->adapter; - struct sched_class *e; + struct ch_sched_class *e; int err = 0;

if (p->tid < 0 || p->tid >= adap->tids.neotids) @@ -322,7 +322,7 @@ static int t4_sched_flowc_bind(struct port_info *pi, struct ch_sched_flowc *p) }

static void t4_sched_class_unbind_all(struct port_info *pi, - struct sched_class *e, + struct ch_sched_class *e, enum sched_bind_type type) { if (!e) @@ -476,12 +476,12 @@ int cxgb4_sched_class_unbind(struct net_device *dev, void *arg, }

/* If @p is NULL, fetch any available unused class */ -static struct sched_class *t4_sched_class_lookup(struct port_info *pi, - const struct ch_sched_params *p) +static struct ch_sched_class *t4_sched_class_lookup(struct port_info *pi, + const struct ch_sched_params *p) { struct sched_table *s = pi->sched_tbl; - struct sched_class *found = NULL; - struct sched_class *e, *end; + struct ch_sched_class *found = NULL; + struct ch_sched_class *e, *end;

if (!p) { /* Get any available unused class */ @@ -522,10 +522,10 @@ static struct sched_class *t4_sched_class_lookup(struct port_info *pi, return found; }

-static struct sched_class *t4_sched_class_alloc(struct port_info *pi, - struct ch_sched_params *p) +static struct ch_sched_class *t4_sched_class_alloc(struct port_info *pi, + struct ch_sched_params *p) { - struct sched_class *e = NULL; + struct ch_sched_class *e = NULL; u8 class_id; int err;

@@ -579,8 +579,8 @@ static struct sched_class *t4_sched_class_alloc(struct port_info *pi, * scheduling class with matching @p is found, then the matching class is * returned. */ -struct sched_class *cxgb4_sched_class_alloc(struct net_device *dev, - struct ch_sched_params *p) +struct ch_sched_class *cxgb4_sched_class_alloc(struct net_device *dev, + struct ch_sched_params *p) { struct port_info *pi = netdev2pinfo(dev); u8 class_id; @@ -607,7 +607,7 @@ void cxgb4_sched_class_free(struct net_device *dev, u8 classid) struct port_info *pi = netdev2pinfo(dev); struct sched_table *s = pi->sched_tbl; struct ch_sched_params p; - struct sched_class *e; + struct ch_sched_class *e; u32 speed; int ret;

@@ -640,7 +640,7 @@ void cxgb4_sched_class_free(struct net_device *dev, u8 classid) } }

-static void t4_sched_class_free(struct net_device *dev, struct sched_class *e) +static void t4_sched_class_free(struct net_device *dev, struct ch_sched_class *e) { struct port_info *pi = netdev2pinfo(dev);

@@ -660,7 +660,7 @@ struct sched_table *t4_init_sched(unsigned int sched_size) s->sched_size = sched_size;

for (i = 0; i < s->sched_size; i++) { - memset(&s->tab[i], 0, sizeof(struct sched_class)); + memset(&s->tab[i], 0, sizeof(struct ch_sched_class)); s->tab[i].idx = i; s->tab[i].state = SCHED_STATE_UNUSED; INIT_LIST_HEAD(&s->tab[i].entry_list); @@ -682,7 +682,7 @@ void t4_cleanup_sched(struct adapter *adap) continue;

for (i = 0; i < s->sched_size; i++) { - struct sched_class *e; + struct ch_sched_class *e;

e = &s->tab[i]; if (e->state == SCHED_STATE_ACTIVE) diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.h b/drivers/net/ethernet/chelsio/cxgb4/sched.h index 6b3c778815f09..4d3b5a7575366 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/sched.h +++ b/drivers/net/ethernet/chelsio/cxgb4/sched.h @@ -71,7 +71,7 @@ struct sched_flowc_entry { struct ch_sched_flowc param; };

-struct sched_class { +struct ch_sched_class { u8 state; u8 idx; struct ch_sched_params info; @@ -82,7 +82,7 @@ struct sched_class {

struct sched_table { /* per port scheduling table */ u8 sched_size; - struct sched_class tab[] __counted_by(sched_size); + struct ch_sched_class tab[] __counted_by(sched_size); };

static inline bool can_sched(struct net_device *dev) @@ -103,15 +103,15 @@ static inline bool valid_class_id(struct net_device *dev, u8 class_id) return true; }

-struct sched_class *cxgb4_sched_queue_lookup(struct net_device *dev, - struct ch_sched_queue *p); +struct ch_sched_class *cxgb4_sched_queue_lookup(struct net_device *dev, + struct ch_sched_queue *p); int cxgb4_sched_class_bind(struct net_device *dev, void *arg, enum sched_bind_type type); int cxgb4_sched_class_unbind(struct net_device *dev, void *arg, enum sched_bind_type type);

-struct sched_class *cxgb4_sched_class_alloc(struct net_device *dev, - struct ch_sched_params *p); +struct ch_sched_class *cxgb4_sched_class_alloc(struct net_device *dev, + struct ch_sched_params *p); void cxgb4_sched_class_free(struct net_device *dev, u8 classid);

struct sched_table *t4_init_sched(unsigned int size);

From: Aditya Garg gargaditya@linux.microsoft.com

[ Upstream commit 45120304e84171fd215c1b57b15b285446d15106 ]

Drop TX packets when posting the work request fails and ensure DMA mappings are always cleaned up.

Signed-off-by: Aditya Garg gargaditya@linux.microsoft.com Reviewed-by: Haiyang Zhang haiyangz@microsoft.com Link: https://patch.msgid.link/1763464269-10431-3-git-send-email-gargaditya@linux.... Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Looking at this commit, I need to analyze it for stable backporting suitability.

## Commit Analysis

### What the commit does:

1. **In `mana_en.c`**: When `mana_gd_post_work_request()` fails during TX: - Previously: returned `NETDEV_TX_BUSY` without cleaning up DMA mappings - Now: calls `mana_unmap_skb()` to clean up DMA mappings, then drops the packet properly

2. **In `gdma_main.c`**: Removes a noisy `dev_err` message for flow control failure

3. **In `mana.h`**: Exports `mana_unmap_skb()` function for use across files

### Bug Being Fixed

Looking at the original error path: ```c if (err) { (void)skb_dequeue_tail(&txq->pending_skbs); netdev_warn(ndev, "Failed to post TX OOB: %d\n", err); err = NETDEV_TX_BUSY; goto tx_busy; // DMA mappings NOT unmapped! } ```

The original code has **two bugs**: 1. **DMA resource leak**: When `mana_gd_post_work_request()` fails, the DMA mappings set up earlier (via `mana_map_skb()`) are never freed 2. **Improper error handling**: Returns `NETDEV_TX_BUSY` which tells the network stack to retry, but the skb was already dequeued from `pending_skbs`, leading to inconsistent state

### Code Change Assessment

The fix is straightforward and surgical: ```c if (err) { (void)skb_dequeue_tail(&txq->pending_skbs); mana_unmap_skb(skb, apc); // NEW: Clean up DMA mappings netdev_warn(ndev, "Failed to post TX OOB: %d\n", err); goto free_sgl_ptr; // Drop packet properly } ```

### Stable Criteria Evaluation

| Criterion | Assessment | |-----------|------------| | Fixes real bug | ✅ Yes - DMA resource leak and improper error handling | | Obviously correct | ✅ Yes - unmapping DMA on error is clearly correct | | Small and contained | ✅ Yes - only affects error path in MANA driver | | No new features | ✅ Yes - pure bug fix | | User impact | ✅ Medium-high - affects Azure VM users; leaks can cause long-term instability |

### Risk Assessment

- **Low risk**: Changes only affect the TX error path - **Self-contained**: The `mana_unmap_skb()` function already exists, just made non-static - **No dependencies**: This commit is standalone - **Well-tested**: Has "Reviewed-by" tag from Microsoft maintainer

### Missing Signals

- No `Cc: stable@vger.kernel.org` tag - No `Fixes:` tag

However, this is clearly fixing a resource leak bug that has existed since the error path was written. Resource leaks in network drivers are exactly the kind of bugs stable trees should fix.

### User Impact

The MANA driver is used in Microsoft Azure VMs. DMA mapping leaks: - Cause memory pressure over time - Can lead to allocation failures under sustained TX errors - May cause VM instability in production cloud environments

This is a production-relevant bug affecting real cloud users.

### Conclusion

This commit fixes a genuine resource leak bug in the MANA network driver. The fix is: - Small (adds one function call + declaration) - Surgical (only affects error path) - Obviously correct (unmapping DMA on error is mandatory) - Low risk (doesn't touch normal TX path) - Important for production Azure VM users

The lack of stable/Fixes tags is unfortunate but doesn't diminish the clear bug-fix nature of this change.

**YES**

drivers/net/ethernet/microsoft/mana/gdma_main.c | 6 +----- drivers/net/ethernet/microsoft/mana/mana_en.c | 7 +++---- include/net/mana/mana.h | 1 + 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c index 43f034e180c41..7d232ac250958 100644 --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c @@ -1299,7 +1299,6 @@ int mana_gd_post_work_request(struct gdma_queue *wq, struct gdma_posted_wqe_info *wqe_info) { u32 client_oob_size = wqe_req->inline_oob_size; - struct gdma_context *gc; u32 sgl_data_size; u32 max_wqe_size; u32 wqe_size; @@ -1329,11 +1328,8 @@ int mana_gd_post_work_request(struct gdma_queue *wq, if (wqe_size > max_wqe_size) return -EINVAL;

- if (wq->monitor_avl_buf && wqe_size > mana_gd_wq_avail_space(wq)) { - gc = wq->gdma_dev->gdma_context; - dev_err(gc->dev, "unsuccessful flow control!\n"); + if (wq->monitor_avl_buf && wqe_size > mana_gd_wq_avail_space(wq)) return -ENOSPC; - }

if (wqe_info) wqe_info->wqe_size_in_bu = wqe_size / GDMA_WQE_BU_SIZE; diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index 0142fd98392c2..6d37f39930453 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -438,9 +438,9 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)

if (err) { (void)skb_dequeue_tail(&txq->pending_skbs); + mana_unmap_skb(skb, apc); netdev_warn(ndev, "Failed to post TX OOB: %d\n", err); - err = NETDEV_TX_BUSY; - goto tx_busy; + goto free_sgl_ptr; }

err = NETDEV_TX_OK; @@ -460,7 +460,6 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev) tx_stats->bytes += len + ((num_gso_seg - 1) * gso_hs); u64_stats_update_end(&tx_stats->syncp);

-tx_busy: if (netif_tx_queue_stopped(net_txq) && mana_can_tx(gdma_sq)) { netif_tx_wake_queue(net_txq); apc->eth_stats.wake_queue++; @@ -1606,7 +1605,7 @@ static int mana_move_wq_tail(struct gdma_queue *wq, u32 num_units) return 0; }

-static void mana_unmap_skb(struct sk_buff *skb, struct mana_port_context *apc) +void mana_unmap_skb(struct sk_buff *skb, struct mana_port_context *apc) { struct mana_skb_head *ash = (struct mana_skb_head *)skb->head; struct gdma_context *gc = apc->ac->gdma_dev->gdma_context; diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h index 0921485565c05..330e1bb088bb9 100644 --- a/include/net/mana/mana.h +++ b/include/net/mana/mana.h @@ -580,6 +580,7 @@ int mana_set_bw_clamp(struct mana_port_context *apc, u32 speed, void mana_query_phy_stats(struct mana_port_context *apc); int mana_pre_alloc_rxbufs(struct mana_port_context *apc, int mtu, int num_queues); void mana_pre_dealloc_rxbufs(struct mana_port_context *apc); +void mana_unmap_skb(struct sk_buff *skb, struct mana_port_context *apc);

extern const struct ethtool_ops mana_ethtool_ops; extern struct dentry *mana_debugfs_root;

From: Dan Hamik dan@hamik.net

[ Upstream commit ef42cf705ca32c07a58133817567ac06ef74dc19 ]

Add the USB device ID 0x0b05:0x1cb6 to the rtw8852bu driver to support the ASUS AX57 Nano WiFi 6 USB adapter.This device uses the same Realtek RTL8852BU chipset as other supported models.

Tested on: Linux Mint 22 with kernel 6.8.0-87-generic. The adapter initializes successfully and connects to networks.

Signed-off-by: Dan Hamik dan@hamik.net Signed-off-by: Ping-Ke Shih pkshih@realtek.com Link: https://patch.msgid.link/010f019a76e1a84b-0a6f5e9f-2a43-4a9d-9c30-de4ae63630... Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture of the situation. Let me summarize my analysis:

## DETAILED ANALYSIS

### 1. COMMIT MESSAGE ANALYSIS

The commit message states: - **Subject**: "wifi: rtw89: rtw8852bu: Added dev id for ASUS AX57 NANO USB Wifi dongle" - **Purpose**: Add USB device ID `0x0b05:0x1cb6` for the ASUS AX57 Nano WiFi 6 USB adapter - **Device**: Uses the Realtek RTL8852BU chipset (same as other supported models) - **Testing**: Tested on Linux Mint 22 with kernel 6.8.0-87-generic

**Notable absences**: - No `Cc: stable@vger.kernel.org` tag - No `Fixes:` tag - This is a hardware enablement patch, not a bug fix

### 2. CODE CHANGE ANALYSIS

The diff shows a **trivial 2-line addition**: ```c + { USB_DEVICE_AND_INTERFACE_INFO(0x0b05, 0x1cb6, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)&rtw89_8852bu_info }, ```

This adds a new USB device ID entry to the `rtw_8852bu_id_table[]` array. The change: - Uses the standard `USB_DEVICE_AND_INTERFACE_INFO()` macro - References the existing `rtw89_8852bu_info` driver info structure - Is identical in pattern to all other entries in the table - Enables the existing driver to match and bind to the ASUS AX57 Nano device

The vendor ID `0x0b05` is ASUS (ASUSTeK Computer Inc.), and `0x1cb6` is the specific product ID for this adapter. There's already another ASUS device in the table (`0x0b05, 0x1a62`), confirming ASUS devices work with this driver.

### 3. CLASSIFICATION

**This is a NEW DEVICE ID addition** - one of the explicitly allowed exception categories for stable kernel backports.

Per stable kernel rules:

"Adding PCI IDs, USB IDs, ACPI IDs, etc. to existing drivers. These

are trivial one-line additions that enable hardware support."

The commit: - Does NOT add new features - Does NOT change any driver logic - Does NOT add new APIs - Simply enables an existing, working driver to bind to a new USB device - The device uses the same RTL8852BU chipset that the driver already supports

### 4. SCOPE AND RISK ASSESSMENT

**Scope**: Extremely minimal - Lines changed: 2 lines added - Files touched: 1 file - Complexity: Trivial (simple array element addition) - Subsystem: Wireless networking (rtw89 driver)

**Risk**: Extremely LOW - The change cannot break existing functionality - It only adds a new USB ID to match - The driver infrastructure for RTL8852BU already exists and is tested - The device uses an identical chipset to other supported devices - Other ASUS devices already work with this driver

### 5. USER IMPACT

**Who benefits**: Users who purchase the ASUS AX57 Nano WiFi 6 USB adapter - This is a real, commercially available product - Without this patch, the device won't be recognized by the kernel - The commit author tested it and confirmed it works

**Severity**: Moderate for affected users - The device is completely non-functional without this ID - With the ID, full WiFi functionality is enabled

### 6. STABILITY INDICATORS

- **Tested by**: Dan Hamik (the patch author) - **Acked/Signed by**: Ping-Ke Shih (Realtek maintainer) - **Pattern**: Follows the exact same pattern as all other USB ID additions in this driver

### 7. DEPENDENCY CHECK - CRITICAL FINDING

**The rtw8852bu.c driver file only exists starting from v6.17.**

My investigation revealed: - The `rtw8852bu.c` file was first added in commit `0ed2a8b1a14e9` on July 5, 2025 - The rtw89 USB infrastructure (`usb.c`, `usb.h`) was added in commit `2135c28be6a84` on June 30, 2025 - Both commits first appeared in v6.17-rc1 - **The driver does NOT exist in v6.16 or any earlier stable trees** (confirmed by checking `git show v6.16:drivers/net/wireless/realtek/rtw89/rtw8852bu.c` which returns "fatal: path does not exist")

Current stable trees and rtw8852bu.c availability: | Stable Tree | rtw8852bu.c Available? | |-------------|------------------------| | 6.12.y (LTS) | ❌ No | | 6.15.y | ❌ No | | 6.16.y | ❌ No | | 6.17.y | ✅ Yes | | 6.18 | ✅ Yes |

### CONCLUSION

While this commit **meets the typical criteria** for stable backporting (it's a trivial USB device ID addition that enables hardware support using existing, tested driver code), there is a **critical dependency issue**:

**The rtw8852bu.c driver itself was only introduced in Linux 6.17 (v6.17-rc1).** This means:

1. For stable trees 6.17.y and later: The commit would be appropriate to backport as it enables new hardware with zero risk.

2. For stable trees earlier than 6.17 (6.16.y, 6.15.y, 6.12.y, 6.6.y, 6.1.y, etc.): The commit **cannot be backported** because the driver file doesn't exist. Backporting would require first backporting the entire rtw89 USB infrastructure (usb.c, usb.h) plus the rtw8852bu.c driver file, which would be a massive undertaking involving new functionality - NOT appropriate for stable.

Given that: 1. The primary purpose of stable backports is to bring fixes to LTS kernels (6.12.y, 6.6.y, 6.1.y) 2. This driver doesn't exist in any of those LTS trees 3. For the only stable tree where it exists (6.17.y), this is a very new kernel with limited user base compared to LTS 4. The commit lacks explicit `Cc: stable` tag from the maintainer

The practical utility of backporting is very limited. The only stable tree that could receive this is 6.17.y, which is not an LTS kernel. Users of actual LTS kernels (6.12, 6.6, 6.1) cannot benefit from this backport at all since the underlying driver doesn't exist there.

**YES** - This commit **is appropriate for backporting** to stable trees **where the driver exists (6.17.y only)**. It's a textbook example of a safe device ID addition - trivial, low-risk, enables hardware support without any code changes. However, the practical scope is limited to the 6.17.y stable tree only.

**YES**

drivers/net/wireless/realtek/rtw89/rtw8852bu.c | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtw89/rtw8852bu.c b/drivers/net/wireless/realtek/rtw89/rtw8852bu.c index 0694272f7ffae..83bdea040f40e 100644 --- a/drivers/net/wireless/realtek/rtw89/rtw8852bu.c +++ b/drivers/net/wireless/realtek/rtw89/rtw8852bu.c @@ -28,6 +28,8 @@ static const struct usb_device_id rtw_8852bu_id_table[] = { .driver_info = (kernel_ulong_t)&rtw89_8852bu_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x0b05, 0x1a62, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&rtw89_8852bu_info }, + { USB_DEVICE_AND_INTERFACE_INFO(0x0b05, 0x1cb6, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)&rtw89_8852bu_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x0db0, 0x6931, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&rtw89_8852bu_info }, { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3327, 0xff, 0xff, 0xff),

From: Jakub Kicinski kuba@kernel.org

[ Upstream commit 4c03592689bc19df9deda7a33d56c6ac0cec8651 ]

Commit e20dfbad8aab ("net: fix napi_consume_skb() with alien skbs") added a skb->cpu check to napi_consume_skb(), before the point where napi_consume_skb() validated skb is not NULL.

Add an explicit check to the early exit condition.

Reviewed-by: Eric Dumazet edumazet@google.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Summary Analysis

### 1. COMMIT MESSAGE ANALYSIS - **Purpose**: Fixes a regression introduced by commit e20dfbad8aab - **Problem**: The prior commit added `skb->alloc_cpu` check *before* the point where NULL was being handled - **Keywords**: "restore" indicates fixing a regression; explicitly references the bug-introducing commit - **Tags**: Reviewed-by Eric Dumazet (top networking maintainer), Signed-off-by Jakub Kicinski (net maintainer)

### 2. CODE CHANGE ANALYSIS

**Before the bug (e20dfbad8aab~1)**: ```c void napi_consume_skb(struct sk_buff *skb, int budget) { if (unlikely(!budget)) { dev_consume_skb_any(skb); // Safe with NULL return; } if (!skb_unref(skb)) // skb_unref() handles NULL! return; ... ```

**After e20dfbad8aab introduced the bug**: ```c if (skb->alloc_cpu != smp_processor_id() ...) // CRASH if skb==NULL ```

**The fix adds `|| !skb`** to redirect NULL skbs to `dev_consume_skb_any()` which safely handles NULL (verified via call chain: `dev_consume_skb_any` → `dev_kfree_skb_any_reason` → `sk_skb_reason_drop` → `skb_unref` which has explicit NULL check).

**Technical Mechanism**: The bug is a NULL pointer dereference. When `budget != 0` and `skb == NULL`, the code would try to access `skb->alloc_cpu`, causing a kernel oops/crash.

### 3. CLASSIFICATION - **Type**: Regression fix for NULL pointer dereference - **Severity**: HIGH - kernel crash/oops - **Category**: Core networking bug fix (not device ID, quirk, or DT)

### 4. SCOPE AND RISK ASSESSMENT - **Lines changed**: 1 (adds `|| !skb` to existing condition) - **Files touched**: 1 (`net/core/skbuff.c`) - **Complexity**: Trivial - single condition addition - **Risk**: VERY LOW - adds defensive NULL check to existing early-exit path - **Subsystem**: Core networking (`napi_consume_skb` is used by many drivers)

### 5. USER IMPACT - **Affected users**: Anyone using networking with drivers that call `napi_consume_skb(NULL, non_zero_budget)` - **Severity if hit**: Kernel crash/oops - **Scope**: Core networking path = HIGH impact potential

### 6. STABILITY INDICATORS - Reviewed-by: Eric Dumazet (authoritative networking maintainer) - Signed-off-by: Jakub Kicinski (net maintainer) - Obviously correct fix (adding NULL check before dereference)

### 7. DEPENDENCY CHECK - **Depends on**: Commit e20dfbad8aab must be present (the bug- introducing commit) - This fix should be backported to any stable tree that contains e20dfbad8aab

### CONCLUSION

This is a textbook stable backport candidate:

1. ✅ **Obviously correct**: Adding NULL check before pointer dereference 2. ✅ **Fixes real bug**: NULL pointer dereference → kernel crash 3. ✅ **Important issue**: Kernel oops in core networking path 4. ✅ **Small and contained**: Single character addition (`|| !skb`) 5. ✅ **No new features**: Pure regression fix 6. ✅ **Expert reviewed**: Eric Dumazet and Jakub Kicinski (net maintainers) 7. ✅ **Restores previous behavior**: Explicit goal stated in commit message

The fix is minimal, surgical, and addresses a serious crash in core networking code. The dependency on e20dfbad8aab is the only consideration - this fix must accompany that commit in any stable tree.

**YES**

net/core/skbuff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 6be01454f262a..9f9ea86620ace 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -1458,7 +1458,7 @@ void napi_skb_free_stolen_head(struct sk_buff *skb) void napi_consume_skb(struct sk_buff *skb, int budget) { /* Zero budget indicate non-NAPI context called us, like netpoll */ - if (unlikely(!budget)) { + if (unlikely(!budget || !skb)) { dev_consume_skb_any(skb); return; }

From: Chih-Kang Chang gary.chang@realtek.com

[ Upstream commit 3a12581fc292997f5ca6dafe3238afd39b77e798 ]

In the wpa_supplicant rekey flow, it sends an EAPOL packet 4/4 through nl80211_tx_control_port() and triggers wake_tx_queue() in the driver. Then, it sends nl80211_new_key() to configure a new key in mac80211. However, in wake_tx_queue(), a workqueue is used to process the TX packet, which might cause the driver to process the EAPOL packet later than nl80211_new_key(). This results in the EAPOL packet 4/4 being transmitted with the new key and IV, causing it to be dropped by the AP. Therefore, needs to flush TX queue before deleting the old key to ensure that the EAPOL 4/4 packet is transmitted using the old key.

Signed-off-by: Chih-Kang Chang gary.chang@realtek.com Signed-off-by: Ping-Ke Shih pkshih@realtek.com Link: https://patch.msgid.link/20251114060128.35363-2-pkshih@realtek.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## 3. CLASSIFICATION

**Type:** Bug fix - Race condition in WPA rekey flow

**User Impact:** WPA rekeying failures, causing: - WiFi authentication failures - Connection drops during normal operation - Poor user experience on networks that perform rekeying

This is a **functional bug**, not a security vulnerability - it causes legitimate authentication packets to be dropped.

## 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 1 line added - **Files touched:** 1 file (mac80211.c) - **Complexity:** Very low

**Pattern already exists in the driver:** Looking at `ps.c:65`, the same `flush_work(&rtwdev->txq_work)` pattern is already used before power mode changes. This fix applies the same proven pattern to key deletion.

**Risk:** Very low - the fix: - Uses well-understood kernel API (`flush_work()`) - Follows existing driver patterns - Only adds a synchronization point, doesn't change logic

## 5. DEPENDENCY CHECK

- `txq_work` has existed since the rtw89 driver was first introduced (commit e3ec7017f6a20 in October 2021, kernel 5.16) - The `set_key` function with the `DISABLE_KEY` path also exists since driver inception - No dependencies on other commits

## 6. STABILITY INDICATORS

**Pros:** - Simple, obvious fix using well-established pattern - Clear understanding of the race condition - Signed off by Realtek developers who maintain this driver

**Cons:** - No `Cc: stable@vger.kernel.org` tag - No `Fixes:` tag - Relatively new commit (November 2025) - No Tested-by or Reviewed-by tags

## 7. SUMMARY

| Criteria | Assessment | |----------|------------| | Fixes real bug | ✅ Yes - WPA rekey failure causing connection issues | | Obviously correct | ✅ Yes - follows existing pattern, minimal change | | Small and contained | ✅ Yes - 1 line | | No new features | ✅ Yes - pure bug fix | | Stable tag | ❌ No explicit request from maintainer | | Fixes tag | ❌ Missing | | Risk | ✅ Very low | | Dependencies | ✅ None - uses existing infrastructure |

## CONCLUSION

This commit **should be backported** to stable. Despite the lack of explicit stable tags, it meets all the technical criteria for stable inclusion:

1. **Fixes a real, user-visible bug** - WPA rekeying failures cause authentication problems 2. **Extremely minimal change** - just one line that adds a `flush_work()` call 3. **Uses proven pattern** - identical pattern already exists in `ps.c` 4. **Low risk** - synchronization-only change that cannot break existing functionality 5. **No dependencies** - the `txq_work` structure has existed since the driver was introduced

The fix ensures EAPOL 4/4 packets are transmitted with the correct key during WPA rekeying, which is essential for proper WiFi operation. The change is surgical and follows established patterns in the driver.

**YES**

drivers/net/wireless/realtek/rtw89/mac80211.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/realtek/rtw89/mac80211.c b/drivers/net/wireless/realtek/rtw89/mac80211.c index 7b04183a3a5dd..064bae533bceb 100644 --- a/drivers/net/wireless/realtek/rtw89/mac80211.c +++ b/drivers/net/wireless/realtek/rtw89/mac80211.c @@ -954,6 +954,7 @@ static int rtw89_ops_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd, } break; case DISABLE_KEY: + flush_work(&rtwdev->txq_work); rtw89_hci_flush_queues(rtwdev, BIT(rtwdev->hw->queues) - 1, false); rtw89_mac_flush_txq(rtwdev, BIT(rtwdev->hw->queues) - 1, false);

From: Grzegorz Nitka grzegorz.nitka@intel.com

[ Upstream commit ba2807b869a16d36b8bc76efa774fe433b3c45de ]

Add E825C 10GbE SGMII device to the list of devices supporting 100Mbit link mode. Without that change, 100Mbit link mode is ignored in ethtool interface. This change was missed while adding the support for E825C devices family.

Testing hints (please note, for previous version, 100baseT/Full entry was missing): [root@localhost]# ethtool eth3 Settings for eth3: Supported ports: [ TP ] Supported link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: None Advertised link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full ...

Signed-off-by: Grzegorz Nitka grzegorz.nitka@intel.com Reviewed-by: Aleksandr Loktionov aleksandr.loktionov@intel.com Reviewed-by: Paul Menzel pmenzel@molgen.mpg.de Reviewed-by: Simon Horman horms@kernel.org Tested-by: Rinitha S sx.rinitha@intel.com (A Contingent worker at Intel) Signed-off-by: Tony Nguyen anthony.l.nguyen@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

Now I have a complete understanding. Let me summarize my analysis:

## DETAILED ANALYSIS

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** `ice: Allow 100M speed for E825C SGMII device`

**Key phrases in commit message:** - "This change was missed while adding the support for E825C devices family" - This explicitly acknowledges this is a bug fix for a missed case when E825C was introduced - "Without that change, 100Mbit link mode is ignored in ethtool interface" - Describes the user-visible symptom

**Missing tags:** - No `Fixes:` tag (should logically point to `f64e189442332` - "ice: introduce new E825C devices family") - No `Cc: stable@vger.kernel.org` tag

**Tags present:** - Multiple `Reviewed-by:` tags (3 reviewers including Simon Horman) - `Tested-by:` tag from Intel QA

### 2. CODE CHANGE ANALYSIS

The change is extremely minimal - adding a single line to a switch statement:

```c bool ice_is_100m_speed_supported(struct ice_hw *hw) { switch (hw->device_id) { case ICE_DEV_ID_E822C_SGMII: case ICE_DEV_ID_E822L_SGMII: case ICE_DEV_ID_E823L_1GBE: case ICE_DEV_ID_E823C_SGMII: + case ICE_DEV_ID_E825C_SGMII: // <-- NEW LINE ADDED return true; default: return false; } } ```

**Technical mechanism:** - The `ice_is_100m_speed_supported()` function is called by `ice_mask_min_supported_speeds()` in `ice_ethtool.c` - This function is used to determine which link speeds to report to ethtool as supported - When `ice_is_100m_speed_supported()` returns `false`, the code masks off 100Mbit phy types (`ICE_PHY_TYPE_LOW_100BASE_TX` and `ICE_PHY_TYPE_LOW_100M_SGMII`) - Without this fix, E825C SGMII devices (PCI ID 0x579F) cannot advertise or use 100Mbit mode via ethtool, even though the hardware supports it

**Root cause:** When E825C support was added in commit `f64e189442332`, the developer forgot to also add `ICE_DEV_ID_E825C_SGMII` to the `ice_is_100m_speed_supported()` function. All other E8xx SGMII devices were already included.

### 3. CLASSIFICATION

**Type:** Bug fix - Missing device ID in a capability function

**Category analysis:** - ✅ **Device ID addition to existing driver** - This is adding a device ID to an existing whitelist function - ❌ Not a new feature - The 100M speed support exists, just missing one device - ❌ Not a security fix - ✅ Hardware capability fix - Enables correct hardware capability reporting

### 4. SCOPE AND RISK ASSESSMENT

**Size:** 1 line added to 1 file

**Risk level:** EXTREMELY LOW - The change adds a single `case` label to a switch statement - The function returns a boolean indicating device capability - No logic changes, no side effects, no behavior changes for any other device - The E825C_SGMII device ID (0x579F) already exists and is used in other places in the driver - Multiple reviewers including Simon Horman

**Subsystem:** Intel ice network driver (mature, widely used, well- tested)

### 5. USER IMPACT

**Who is affected:** - Users with Intel E825-C SGMII network devices (PCI ID 0x579F) - These are specific embedded/enterprise networking devices

**Symptom without fix:** - `ethtool` shows 100Mbit as NOT supported when it should be - Users cannot force 100Mbit link mode even if needed - Misleading capability reporting in network management tools

**Severity:** Medium-Low - Not a crash, security issue, or data corruption - Affects device functionality/usability - Users with this specific hardware are affected

### 6. STABILITY INDICATORS

**Positive signals:** - `Reviewed-by: Simon Horman horms@kernel.org` (well-known networking reviewer) - `Reviewed-by: Aleksandr Loktionov` (Intel) - `Reviewed-by: Paul Menzel` - `Tested-by: Rinitha S` (Intel QA) - Commit signed off by Intel maintainer Tony Nguyen

### 7. DEPENDENCY CHECK

**Dependencies:** - Requires E825C device support (introduced in v6.9-rc1 via `f64e189442332`) - Requires `ice_is_100m_speed_supported()` function (introduced in v6.1-rc1 via `39ed02a4ba527`)

**Stable tree applicability:** - v6.6.y: ❌ No E825C support, commit NOT applicable - v6.10.y: ✅ Has E825C support and `ice_is_100m_speed_supported()`, commit APPLICABLE - v6.11.y: ✅ APPLICABLE - v6.12.y: ✅ APPLICABLE

### 8. STABLE KERNEL RULES ASSESSMENT

| Rule | Assessment | |------|------------| | Obviously correct and tested | ✅ Yes - trivial addition, well- reviewed, tested | | Fixes real bug that affects users | ✅ Yes - 100Mbit mode not available on E825C SGMII | | Important issue | ⚠️ Moderate - not critical but affects device usability | | Small and contained | ✅ Yes - 1 line change | | No new features | ✅ Yes - enables existing functionality | | No new APIs | ✅ Yes | | Applies cleanly | ✅ Should apply cleanly to v6.10+ |

### CONCERNS

1. **No explicit stable markers:** The commit lacks `Cc: stable@vger.kernel.org` and `Fixes:` tags, suggesting the developer/maintainer didn't explicitly request backport

2. **Only applies to kernels with E825C support:** This fix is ONLY meaningful for kernels v6.10+ that have E825C device support. Backporting to v6.6.y would be pointless since those kernels don't have E825C at all.

3. **Not a critical fix:** While it's a real bug, it's not a crash, security issue, or data corruption - it's a feature parity/usability issue.

### RECOMMENDATION

This commit **SHOULD be backported** to stable kernels that have E825C support (v6.10+, v6.11+, v6.12+) for the following reasons:

1. **Clearly a bug fix:** The commit message explicitly states "This change was missed while adding the support for E825C devices family" 2. **Trivial and safe:** Single line addition to a capability whitelist - minimal risk 3. **Well-reviewed and tested:** Multiple reviewers and explicit testing 4. **Follows the device ID exception:** Adding device IDs to existing functions is a well-accepted stable practice 5. **Fixes real user issue:** Users with E825C SGMII hardware cannot configure 100Mbit mode

The lack of explicit stable tags appears to be an oversight rather than a deliberate decision to not backport. The change is clearly in the category of "hardware quirks/device ID additions that enable proper hardware support."

**YES**

drivers/net/ethernet/intel/ice/ice_common.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c index 2532b6f82e971..449418cf06c20 100644 --- a/drivers/net/ethernet/intel/ice/ice_common.c +++ b/drivers/net/ethernet/intel/ice/ice_common.c @@ -3389,6 +3389,7 @@ bool ice_is_100m_speed_supported(struct ice_hw *hw) case ICE_DEV_ID_E822L_SGMII: case ICE_DEV_ID_E823L_1GBE: case ICE_DEV_ID_E823C_SGMII: + case ICE_DEV_ID_E825C_SGMII: return true; default: return false;