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:

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

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index bd26a8db64096..b92bfd131567e 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -587,6 +587,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: 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:

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 f901ae18e68ad..a2830ec67e782 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: 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:

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: Tetsuo Handa penguin-kernel@I-love.SAKURA.ne.jp

[ Upstream commit 005d4b0d33f6b4a23d382b7930f7a96b95b01f39 ]

syzbot is reporting that S_IFMT bits of inode->i_mode can become bogus when the S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.

According to [1], the permissions field was treated as reserved in Mac OS 8 and 9. According to [2], the reserved field was explicitly initialized with 0, and that field must remain 0 as long as reserved. Therefore, when the "mode" field is not 0 (i.e. no longer reserved), the file must be S_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/ S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.

Reported-by: syzbot syzbot+895c23f6917da440ed0d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Link: https://developer.apple.com/library/archive/technotes/tn/tn1150.html#HFSPlus... [1] Link: https://developer.apple.com/library/archive/technotes/tn/tn1150.html#Reserve... [2] Signed-off-by: Tetsuo Handa penguin-kernel@I-love.SAKURA.ne.jp Reviewed-by: Viacheslav Dubeyko slava@dubeyko.com Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Link: https://lore.kernel.org/r/04ded9f9-73fb-496c-bfa5-89c4f5d1d7bb@I-love.SAKURA... Signed-off-by: Viacheslav Dubeyko slava@dubeyko.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Analysis of hfsplus: Verify inode mode when loading from disk

### 1. COMMIT MESSAGE ANALYSIS

**Key indicators:** - **Reported-by: syzbot** - This is a real bug found by automated fuzzing - **Closes:** link to syzkaller bug report confirms this is a genuine issue - **Reviewed-by:** present from the HFS+ maintainer (Viacheslav Dubeyko) - **No "Cc: stable@vger.kernel.org"** tag - **No "Fixes:" tag** - bug appears to exist since original HFS+ implementation

The commit describes that corrupted S_IFMT bits in the on-disk "mode" field can cause inode->i_mode to become bogus when loaded from disk. The commit message references Apple technical documentation explaining the expected values for the mode field.

### 2. CODE CHANGE ANALYSIS

The fix modifies `hfsplus_get_perms()` in two ways:

**a) Adds validation logic (the core fix):** ```c if (dir) { if (mode && !S_ISDIR(mode)) goto bad_type; } else if (mode) { switch (mode & S_IFMT) { case S_IFREG: case S_IFLNK: case S_IFCHR: case S_IFBLK: case S_IFIFO: case S_IFSOCK: break; default: goto bad_type; } } ``` This validates that: - For directories (`dir=1`): mode must be 0 or actually be a directory type - For files (`dir=0`): mode must be 0 or one of the valid file types (regular, symlink, char/block device, FIFO, socket)

**b) Changes return type from `void` to `int`:** - Returns -EIO on invalid mode with an error message - Callers (`hfsplus_cat_read_inode`) now check the return value and propagate errors

**Root cause:** The original code blindly trusted the mode field from disk without validating that the S_IFMT bits are consistent with the directory flag.

### 3. CLASSIFICATION

- **Type:** Bug fix (input validation) - **Security relevance:** Yes - crafted filesystem images could trigger this - **Category:** Filesystem robustness/hardening against corrupted data

### 4. SCOPE AND RISK ASSESSMENT

| Aspect | Assessment | |--------|------------| | Lines changed | ~30+ additions, moderate size | | Files touched | 1 file (fs/hfsplus/inode.c) | | Complexity | Low - straightforward validation logic | | Regression risk | **LOW** - only rejects clearly invalid data |

The validation is conservative and follows Apple's official HFS+ specification. It only rejects modes that are definitively wrong.

### 5. USER IMPACT

- **Affected users:** Those mounting HFS+ filesystems (macOS external drives, dual-boot setups) - **Trigger:** Mounting a corrupted or maliciously crafted HFS+ filesystem image - **Impact of bug:** Bogus inode mode can lead to undefined kernel behavior when processing the inode - **Impact of fix:** Graceful rejection with -EIO instead of corrupted internal state

### 6. STABILITY INDICATORS

- Reviewed by subsystem maintainer ✓ - Clean, standalone fix with no dependencies ✓ - The modified functions exist in older stable kernels ✓ - No unusual code patterns or risky constructs ✓

### 7. DEPENDENCY CHECK

This is a standalone fix. The `hfsplus_get_perms` and `hfsplus_cat_read_inode` functions exist in all stable trees where HFS+ is supported.

---

## Summary

**What it fixes:** Prevents corrupted or maliciously crafted HFS+ filesystem images from causing bogus inode modes to be loaded into the kernel.

**Why it matters for stable:** This is a defensive fix that prevents accepting corrupted data, which could lead to undefined behavior. syzbot found this bug, indicating it can be triggered by crafted input - a potential security concern.

**Meets stable criteria:** - ✓ Obviously correct (validates according to Apple's HFS+ specification) - ✓ Fixes a real bug that affects users (syzbot found it with crafted images) - ✓ Small and contained (single file, ~30 lines of validation) - ✓ Low regression risk (only rejects clearly invalid data) - ✗ No explicit stable tag (author didn't request it)

**Risk vs Benefit:** - **Risk:** Very low - adds validation that only rejects invalid data - **Benefit:** Prevents kernel from operating on corrupted inode modes from crafted/corrupted filesystems

The lack of explicit stable tags suggests the author may not have intended this for stable, but the fix clearly meets stable criteria as a filesystem robustness fix against corrupted input. Filesystem fixes for handling crafted/corrupted data are generally appropriate for stable trees.

**YES**

fs/hfsplus/inode.c | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/fs/hfsplus/inode.c b/fs/hfsplus/inode.c index b51a411ecd237..e290e417ed3a7 100644 --- a/fs/hfsplus/inode.c +++ b/fs/hfsplus/inode.c @@ -180,13 +180,29 @@ const struct dentry_operations hfsplus_dentry_operations = { .d_compare = hfsplus_compare_dentry, };

-static void hfsplus_get_perms(struct inode *inode, - struct hfsplus_perm *perms, int dir) +static int hfsplus_get_perms(struct inode *inode, + struct hfsplus_perm *perms, int dir) { struct hfsplus_sb_info *sbi = HFSPLUS_SB(inode->i_sb); u16 mode;

mode = be16_to_cpu(perms->mode); + if (dir) { + if (mode && !S_ISDIR(mode)) + goto bad_type; + } else if (mode) { + switch (mode & S_IFMT) { + case S_IFREG: + case S_IFLNK: + case S_IFCHR: + case S_IFBLK: + case S_IFIFO: + case S_IFSOCK: + break; + default: + goto bad_type; + } + }

i_uid_write(inode, be32_to_cpu(perms->owner)); if ((test_bit(HFSPLUS_SB_UID, &sbi->flags)) || (!i_uid_read(inode) && !mode)) @@ -212,6 +228,10 @@ static void hfsplus_get_perms(struct inode *inode, inode->i_flags |= S_APPEND; else inode->i_flags &= ~S_APPEND; + return 0; +bad_type: + pr_err("invalid file type 0%04o for inode %lu\n", mode, inode->i_ino); + return -EIO; }

static int hfsplus_file_open(struct inode *inode, struct file *file) @@ -516,7 +536,9 @@ int hfsplus_cat_read_inode(struct inode *inode, struct hfs_find_data *fd) } hfs_bnode_read(fd->bnode, &entry, fd->entryoffset, sizeof(struct hfsplus_cat_folder)); - hfsplus_get_perms(inode, &folder->permissions, 1); + res = hfsplus_get_perms(inode, &folder->permissions, 1); + if (res) + goto out; set_nlink(inode, 1); inode->i_size = 2 + be32_to_cpu(folder->valence); inode_set_atime_to_ts(inode, hfsp_mt2ut(folder->access_date)); @@ -545,7 +567,9 @@ int hfsplus_cat_read_inode(struct inode *inode, struct hfs_find_data *fd)

hfsplus_inode_read_fork(inode, HFSPLUS_IS_RSRC(inode) ? &file->rsrc_fork : &file->data_fork); - hfsplus_get_perms(inode, &file->permissions, 0); + res = hfsplus_get_perms(inode, &file->permissions, 0); + if (res) + goto out; set_nlink(inode, 1); if (S_ISREG(inode->i_mode)) { if (file->permissions.dev)

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 63e652ad1e0de..edf7e27e1e375 100644 --- a/fs/hfsplus/bnode.c +++ b/fs/hfsplus/bnode.c @@ -704,6 +704,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: 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: 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:

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

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index c70e79e69be8d..36f18f2657ab8 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -685,6 +685,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: 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: Shuai Zhang quic_shuaz@quicinc.com

[ Upstream commit a8b38d19857d42a1f2e90c9d9b0f74de2500acd7 ]

The new platform uses the QCA2066 chip along with a new board ID, which requires a dedicated firmware file to ensure proper initialization. Without this entry, the driver cannot locate and load the correct firmware, resulting in Bluetooth bring-up failure.

This patch adds a new entry to the firmware table for QCA2066 so that the driver can correctly identify the board ID and load the appropriate firmware from 'qca/QCA2066/' in the linux-firmware repository.

Signed-off-by: Shuai Zhang quic_shuaz@quicinc.com Acked-by: Dmitry Baryshkov dmitry.baryshkov@oss.qualcomm.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:

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

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index cc03c8c38b16f..22f1932fe9126 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3267,6 +3267,7 @@ static const struct qca_device_info qca_devices_table[] = {

static const struct qca_custom_firmware qca_custom_btfws[] = { { 0x00130201, 0x030A, "QCA2066" }, + { 0x00130201, 0x030B, "QCA2066" }, { }, };

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 edf7e27e1e375..482a6c5faa197 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: 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: Quan Zhou quan.zhou@mediatek.com

[ Upstream commit 066f417be5fd8c7fe581c5550206364735dad7a3 ]

Set the MT76_STATE_MCU_RUNNING bit only after mt7921_load_clc() has successfully completed. Previously, the MCU_RUNNING state was set before loading CLC, which could cause conflict between chip mcu_init retry and mac_reset flow, result in chip init fail and chip abnormal status. By moving the state set after CLC load, firmware initialization becomes robust and resolves init fail issue.

Signed-off-by: Quan Zhou quan.zhou@mediatek.com Reviewed-by: druth@chromium.org Link: https://patch.msgid.link/19ec8e4465142e774f17801025accd0ae2214092.1763465933... Signed-off-by: Felix Fietkau nbd@nbd.name Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

# Commit Analysis: wifi: mt76: mt792x: fix wifi init fail by setting MCU_RUNNING after CLC load

## 1. COMMIT MESSAGE ANALYSIS

**Subject:** Clearly indicates a bug fix ("fix wifi init fail")

**Problem described:** Setting `MT76_STATE_MCU_RUNNING` bit before CLC (Country/Legal Configuration) load completion could cause conflicts between MCU init retry and mac_reset flows, resulting in chip initialization failure and abnormal chip status.

**Tags present:** - `Signed-off-by:` Quan Zhou (MediaTek - chip vendor) and Felix Fietkau (mt76 maintainer) - `Reviewed-by:` druth@chromium.org (Chrome OS kernel team - indicates real-world Chromebook impact) - No explicit `Cc: stable@vger.kernel.org` tag - No explicit `Fixes:` tag

## 2. CODE CHANGE ANALYSIS

The change is extremely simple and surgical:

**Before the fix:** ```c set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state); // State set here err = mt7921_load_clc(dev, mt792x_ram_name(dev)); // CLC load after ```

**After the fix:** ```c err = mt7921_load_clc(dev, mt792x_ram_name(dev)); // CLC load first set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state); // State set after success ```

**Technical mechanism:** - `MT76_STATE_MCU_RUNNING` indicates the MCU is fully operational - Setting this flag prematurely (before CLC load) could allow other code paths to think the MCU is ready when it's not - If something triggers MCU init retry or mac_reset during CLC load, there's a race condition - The conflict causes complete initialization failure and abnormal chip state

**Why fix is correct:** - The state bit should only be set when initialization is truly complete - This ensures no code sees MCU_RUNNING during the vulnerable CLC loading phase - Error handling remains intact (if CLC load fails, function returns error)

## 3. CLASSIFICATION

- **Type:** Bug fix - initialization failure fix - **NOT** a feature addition - Fixes a real runtime bug affecting device usability

## 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment | |--------|------------| | Lines changed | ~6 lines (just moving 1 line in 2 files) | | Files touched | 2 (mt7921/mcu.c, mt7925/mcu.c) | | Complexity | Very low - simple reordering | | Regression risk | LOW - no logic changes, just timing | | Subsystem | Wireless driver (contained) |

The change is almost purely a reordering operation within the same function. If CLC load succeeds, the state gets set (same as before, just later). If it fails, function returns error anyway.

## 5. USER IMPACT

**Affected hardware:** MediaTek mt7921 and mt7925 WiFi chips

These are **extremely common** chips found in: - Many Chromebooks (Chrome OS review indicates this) - Consumer laptops (Dell, Lenovo, HP, etc.) - USB WiFi adapters - Various PC builds

**Severity:** HIGH - WiFi initialization failure = device doesn't work at all - "chip abnormal status" suggests chip may be left in broken state - Users cannot use their WiFi until reboot or driver reload

## 6. STABILITY INDICATORS

- Reviewed by Chromium kernel team (indicates real-world testing on Chromebooks) - From MediaTek engineer (hardware vendor knows their chip) - Accepted by mt76 maintainer Felix Fietkau - Clean, minimal change with clear rationale

## 7. DEPENDENCY CHECK

The change is self-contained. It only reorders existing function calls within `mt7921_run_firmware()` and `mt7925_run_firmware()`. No new dependencies are introduced.

The mt7921 driver has been in stable kernels for some time. The mt7925 is newer and may not exist in older stable trees, but the mt7921 portion would still be valuable.

## STABLE KERNEL CRITERIA CHECK

| Criterion | Met? | Notes | |-----------|------|-------| | Obviously correct | ✅ | Simple reordering, logic is clear | | Fixes real bug | ✅ | WiFi init failure - real user impact | | Small and contained | ✅ | 6 lines, 2 files, same subsystem | | No new features | ✅ | No new APIs or functionality | | No architectural changes | ✅ | Minimal change |

## RISK vs BENEFIT

**Benefit:** High - Fixes WiFi initialization failure on widely-deployed hardware. Without this fix, affected users may have non-functional WiFi.

**Risk:** Very low - The change is a trivial reordering of two operations. The logic remains identical; only the timing of when the state bit is set changes. The fix has been reviewed by the chip vendor and Chrome OS team.

## CONCLUSION

This commit is an ideal candidate for stable backporting:

1. **Fixes a real, user-visible bug** - WiFi doesn't work 2. **Minimal change** - Just reordering one line in each of two files 3. **Well-reviewed** - MediaTek and Chrome OS review 4. **Low regression risk** - No logic changes, simple timing fix 5. **High user impact** - mt7921/mt7925 are very common chips 6. **Contained scope** - Only affects initialization path of specific driver

The lack of `Cc: stable` tag doesn't disqualify it - many legitimate fixes don't include this tag. The important factors are all positive: it fixes a real bug, is small, safe, and affects real users.

**YES**

drivers/net/wireless/mediatek/mt76/mt7921/mcu.c | 2 +- drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c index 86bd33b916a9d..edc1df3c071e5 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c @@ -646,10 +646,10 @@ int mt7921_run_firmware(struct mt792x_dev *dev) if (err) return err;

- set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state); err = mt7921_load_clc(dev, mt792x_ram_name(dev)); if (err) return err; + set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);

return mt7921_mcu_fw_log_2_host(dev, 1); } diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c index 8eda407e4135e..c12b71b71cfc7 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -1003,10 +1003,10 @@ int mt7925_run_firmware(struct mt792x_dev *dev) if (err) return err;

- set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state); err = mt7925_load_clc(dev, mt792x_ram_name(dev)); if (err) return err; + set_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state);

return mt7925_mcu_fw_log_2_host(dev, 1); }

From: Johannes Berg johannes.berg@intel.com

[ Upstream commit 9f33477b9a31a1edfe2df9f1a0359cccb0e16b4c ]

If an interface is set down or, per the previous patch, changes type, radar detection for it should be cancelled. This is done for AP mode in mac80211 (somewhat needlessly, since cfg80211 can do it, but didn't until now), but wasn't handled for mesh, so if radar detection was started and then the interface set down or its type switched (the latter sometimes happning in the hwsim test 'mesh_peer_connected_dfs'), radar detection would be around with the interface unknown to the driver, later leading to some warnings around chanctx usage.

Link: https://patch.msgid.link/20251121174021.290120e419e3.I2a5650c9062e29c988992d... Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Summary and Analysis

### What the Bug Fixes This commit fixes a cleanup issue where radar detection (DFS CAC) was not properly stopped when a mesh interface was brought down or changed type. This left residual radar detection state that caused warnings about chanctx (channel context) usage, since the driver thought radar detection was still active for an interface that no longer existed.

### Technical Details The fix: 1. Adds a new `cfg80211_stop_radar_detection()` function in `mlme.c` that iterates through all valid links, ends CAC via `rdev_end_cac()`, and sends `NL80211_RADAR_CAC_ABORTED` notification 2. Calls this new function in `cfg80211_leave()` (the cleanup path when interfaces go down)

### Critical Dependencies The code uses **per-link DFS infrastructure** that was introduced in: - **Commit 62c16f219a73c** ("wifi: cfg80211: move DFS related members to links[] in wireless_dev") - September 2024, **first in v6.12**

This commit accesses `wdev->links[link_id].cac_started` - this structure only exists in 6.12+. In older kernels (6.11 and earlier), `cac_started` was a simple top-level member of `wireless_dev`, not per-link.

### Stable Backport Assessment

**Against backporting:** 1. **No `Cc: stable@vger.kernel.org`** - The maintainer (Johannes Berg) did not request stable backporting 2. **No `Fixes:` tag** - No specific commit is identified as introducing the bug 3. **Dependencies on recent code** - The per-link DFS infrastructure only exists in kernel 6.12+ 4. **Cannot apply to LTS trees** - Would require substantial rework for 6.6.y, 6.1.y, 5.15.y, etc. 5. **Not critical severity** - The bug causes kernel warnings, not crashes, security issues, or data corruption 6. **Niche use case** - Mesh networking combined with DFS channels is relatively uncommon 7. **Very new feature** - The affected MLO/per-link DFS code is only one release old

**Supporting backporting:** - Does fix a real bug that causes warnings - Small, localized change (~25 lines) - From a known/trusted maintainer

### Conclusion

This commit fixes a legitimate bug but does **not** meet stable kernel criteria: - The maintainer did not request stable backporting - The affected code only exists in kernel 6.12+, making it only relevant to the most recent stable branch if any - The bug severity (warnings, not crashes/corruption/security) does not warrant the backporting effort - It cannot be cleanly applied to most stable trees due to structural code differences

**NO**

net/wireless/core.c | 1 + net/wireless/core.h | 1 + net/wireless/mlme.c | 19 +++++++++++++++++++ 3 files changed, 21 insertions(+)

diff --git a/net/wireless/core.c b/net/wireless/core.c index 54a34d8d356e0..5e5c1bc380a89 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -1365,6 +1365,7 @@ void cfg80211_leave(struct cfg80211_registered_device *rdev,

cfg80211_pmsr_wdev_down(wdev);

+ cfg80211_stop_radar_detection(wdev); cfg80211_stop_background_radar_detection(wdev);

switch (wdev->iftype) { diff --git a/net/wireless/core.h b/net/wireless/core.h index b6bd7f4d6385a..d5d78752227af 100644 --- a/net/wireless/core.h +++ b/net/wireless/core.h @@ -489,6 +489,7 @@ cfg80211_start_background_radar_detection(struct cfg80211_registered_device *rde struct wireless_dev *wdev, struct cfg80211_chan_def *chandef);

+void cfg80211_stop_radar_detection(struct wireless_dev *wdev); void cfg80211_stop_background_radar_detection(struct wireless_dev *wdev);

void cfg80211_background_cac_done_wk(struct work_struct *work); diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c index 46394eb2086f6..3fc175f9f8686 100644 --- a/net/wireless/mlme.c +++ b/net/wireless/mlme.c @@ -1295,6 +1295,25 @@ cfg80211_start_background_radar_detection(struct cfg80211_registered_device *rde return 0; }

+void cfg80211_stop_radar_detection(struct wireless_dev *wdev) +{ + struct wiphy *wiphy = wdev->wiphy; + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); + int link_id; + + for_each_valid_link(wdev, link_id) { + struct cfg80211_chan_def chandef; + + if (!wdev->links[link_id].cac_started) + continue; + + chandef = *wdev_chandef(wdev, link_id); + rdev_end_cac(rdev, wdev->netdev, link_id); + nl80211_radar_notify(rdev, &chandef, NL80211_RADAR_CAC_ABORTED, + wdev->netdev, GFP_KERNEL); + } +} + void cfg80211_stop_background_radar_detection(struct wireless_dev *wdev) { struct wiphy *wiphy = wdev->wiphy;