- Linux-stable-mirror - lists.linaro.org

by Neil Gammie

Hello all, please forgive me if this issue is already known, but I couldn't find any reference to it with regard to the 6.17.9 kernel. Anyway, when updating from 6.17.8 to 6.17.9, the following error is raised on every boot: Dec 04 14:44:20 P14s kernel: amdgpu: Topology: Add dGPU node [0x1638:0x1002] Dec 04 14:44:20 P14s kernel: kfd kfd: amdgpu: added device 1002:1638 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 11 on hub 0 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 8 Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: Runtime PM not available Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: amdgpu: [drm] Using custom brightness curve Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: [drm] Registered 4 planes with drm panic Dec 04 14:44:20 P14s kernel: [drm] Initialized amdgpu 3.64.0 for 0000:07:00.0 on minor 1 Dec 04 14:44:20 P14s kernel: fbcon: amdgpudrmfb (fb0) is primary device Dec 04 14:44:20 P14s kernel: amdgpu 0000:07:00.0: [drm] *ERROR* dc_dmub_srv_log_diagnostic_data: DMCUB error - collecting diagnostic data Dec 04 14:44:21 P14s kernel: amdgpu 0000:07:00.0: [drm] fb0: amdgpudrmfb frame buffer device Setup is as follows: Hardware: ThinkPad P14s Gen 2 AMD Processor: AMD Ryzen™ 7 PRO 5850U OS: Arch Linux AMD Firmware: linux-firmware-amdgpu 20251125 Running a bisection gives the following: git bisect start # status: waiting for both good and bad commits # good: [8ac42a63c561a8b4cccfe84ed8b97bb057e6ffae] Linux 6.17.8 git bisect good 8ac42a63c561a8b4cccfe84ed8b97bb057e6ffae # status: waiting for bad commit, 1 good commit known # bad: [1bfd0faa78d09eb41b81b002e0292db0f3e75de0] Linux 6.17.9 git bisect bad 1bfd0faa78d09eb41b81b002e0292db0f3e75de0 # bad: [92ef36a75fbb56a02a16b141fe684f64fb2b1cb9] lib/crypto: arm/curve25519: Disable on CPU_BIG_ENDIAN git bisect bad 92ef36a75fbb56a02a16b141fe684f64fb2b1cb9 # bad: [aaba523dd7b6106526c24b1fd9b5fc35e5aaa88d] sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rto git bisect bad aaba523dd7b6106526c24b1fd9b5fc35e5aaa88d # bad: [b3b288206a1ea7e21472f8d1c7834ebface9bb33] drm/amdkfd: fix suspend/resume all calls in mes based eviction path git bisect bad b3b288206a1ea7e21472f8d1c7834ebface9bb33 # good: [ac486718d6cc96e07bc67094221e682ba5ea6f76] drm/amd/pm: Use pm_display_cfg in legacy DPM (v2) git bisect good ac486718d6cc96e07bc67094221e682ba5ea6f76 # bad: [1009f007b3afba93082599e263b3807d05177d53] RISC-V: clear hot-unplugged cores from all task mm_cpumasks to avoid rfence errors git bisect bad 1009f007b3afba93082599e263b3807d05177d53 # bad: [ccd8af579101ca68f1fba8c9e055554202381cab] drm/amd: Disable ASPM on SI git bisect bad ccd8af579101ca68f1fba8c9e055554202381cab # bad: [e95425b6df29cc88fac7d0d77aa38a5a131dbf45] drm/amd/pm: Disable MCLK switching on SI at high pixel clocks git bisect bad e95425b6df29cc88fac7d0d77aa38a5a131dbf45 # bad: [5ee434b55134c24df7ad426d40fe28c6542fab4d] drm/amd/display: Disable fastboot on DCE 6 too git bisect bad 5ee434b55134c24df7ad426d40fe28c6542fab4d # first bad commit: [5ee434b55134c24df7ad426d40fe28c6542fab4d] drm/amd/display: Disable fastboot on DCE 6 too The error still occurs in 6.18, but reverting the above bad commit removes it. Although an error is reported, the system still boots to the graphical interface and appears to function normally, although I have neither benchmarked graphics performance or used the system for an extended period after the error has been flagged. Yours faithfully, Neil Gammie

3 days, 20 hours

1
0
0 0

[PATCH 6.1.y] ksmbd: fix out-of-bounds in parse_sec_desc()

by Rajani Kantha

From: Namjae Jeon <linkinjeon(a)kernel.org> commit d6e13e19063db24f94b690159d0633aaf72a0f03 upstream. If osidoffset, gsidoffset and dacloffset could be greater than smb_ntsd struct size. If it is smaller, It could cause slab-out-of-bounds. And when validating sid, It need to check it included subauth array size. Cc: stable(a)vger.kernel.org Reported-by: Norbert Szetei <norbert(a)doyensec.com> Tested-by: Norbert Szetei <norbert(a)doyensec.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Rajani Kantha <681739313(a)139.com> --- fs/smb/server/smbacl.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/fs/smb/server/smbacl.c b/fs/smb/server/smbacl.c index 90c5e3edbf46..5c05f0e8b6ea 100644 --- a/fs/smb/server/smbacl.c +++ b/fs/smb/server/smbacl.c @@ -815,6 +815,13 @@ static int parse_sid(struct smb_sid *psid, char *end_of_acl) return -EINVAL; } + if (!psid->num_subauth) + return 0; + + if (psid->num_subauth > SID_MAX_SUB_AUTHORITIES || + end_of_acl < (char *)psid + 8 + sizeof(__le32) * psid->num_subauth) + return -EINVAL; + return 0; } @@ -856,6 +863,9 @@ int parse_sec_desc(struct user_namespace *user_ns, struct smb_ntsd *pntsd, pntsd->type = cpu_to_le16(DACL_PRESENT); if (pntsd->osidoffset) { + if (le32_to_cpu(pntsd->osidoffset) < sizeof(struct smb_ntsd)) + return -EINVAL; + rc = parse_sid(owner_sid_ptr, end_of_acl); if (rc) { pr_err("%s: Error %d parsing Owner SID\n", __func__, rc); @@ -871,6 +881,9 @@ int parse_sec_desc(struct user_namespace *user_ns, struct smb_ntsd *pntsd, } if (pntsd->gsidoffset) { + if (le32_to_cpu(pntsd->gsidoffset) < sizeof(struct smb_ntsd)) + return -EINVAL; + rc = parse_sid(group_sid_ptr, end_of_acl); if (rc) { pr_err("%s: Error %d mapping Owner SID to gid\n", @@ -892,6 +905,9 @@ int parse_sec_desc(struct user_namespace *user_ns, struct smb_ntsd *pntsd, pntsd->type |= cpu_to_le16(DACL_PROTECTED); if (dacloffset) { + if (dacloffset < sizeof(struct smb_ntsd)) + return -EINVAL; + parse_dacl(user_ns, dacl_ptr, end_of_acl, owner_sid_ptr, group_sid_ptr, fattr); } -- 2.17.1

3 days, 20 hours

1
0
0 0

[PATCH 6.1] net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()

by Chen Yu

From: Vladimir Oltean <vladimir.oltean(a)nxp.com> [ Upstream commit 5f2b28b79d2d1946ee36ad8b3dc0066f73c90481 ] There are actually 2 problems: - deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds. - The memmove itself should move size - i - 1 elements, because the last element is out of bounds. The out-of-bounds element still remains out of bounds after being accessed, so the problem is only that we touch it, not that it becomes in active use. But I suppose it can lead to issues if the out-of-bounds element is part of an unmapped page. Fixes: 6666cebc5e30 ("net: dsa: sja1105: Add support for VLAN operations") Signed-off-by: Vladimir Oltean <vladimir.oltean(a)nxp.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250318115716.2124395-4-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Chen Yu <xnguchen(a)sina.cn> --- drivers/net/dsa/sja1105/sja1105_static_config.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/sja1105/sja1105_static_config.c b/drivers/net/dsa/sja1105/sja1105_static_config.c index baba204ad62f..2ac91fe2a79b 100644 --- a/drivers/net/dsa/sja1105/sja1105_static_config.c +++ b/drivers/net/dsa/sja1105/sja1105_static_config.c @@ -1921,8 +1921,10 @@ int sja1105_table_delete_entry(struct sja1105_table *table, int i) if (i > table->entry_count) return -ERANGE; - memmove(entries + i * entry_size, entries + (i + 1) * entry_size, - (table->entry_count - i) * entry_size); + if (i + 1 < table->entry_count) { + memmove(entries + i * entry_size, entries + (i + 1) * entry_size, + (table->entry_count - i - 1) * entry_size); + } table->entry_count--; -- 2.17.1

3 days, 22 hours

1
0
0 0

[PATCH v2 1/3] dm-pcache: advance slot index before writing slot

by Dongsheng Yang

In dm-pcache, in order to ensure crash-consistency, a dual-copy scheme is used to alternately update metadata, and there is a slot index that records the current slot. However, in the write path the current implementation writes directly to the current slot indexed by slot index, and then advances the slot — which ends up overwriting the existing slot, violating the crash-consistency guarantee. This patch fixes that behavior, preventing metadata from being overwritten incorrectly. In addition, this patch add a missing pmem_wmb() after memcpy_flushcache(). Signed-off-by: Dongsheng Yang <dongsheng.yang(a)linux.dev> Reviewed-by: Zheng Gu <cengku(a)gmail.com> Cc: stable(a)vger.kernel.org # 6.18 --- drivers/md/dm-pcache/cache.c | 8 ++++---- drivers/md/dm-pcache/cache_segment.c | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/md/dm-pcache/cache.c b/drivers/md/dm-pcache/cache.c index 698697a7a73c..d4385d76ac36 100644 --- a/drivers/md/dm-pcache/cache.c +++ b/drivers/md/dm-pcache/cache.c @@ -21,10 +21,10 @@ static void cache_info_write(struct pcache_cache *cache) cache_info->header.crc = pcache_meta_crc(&cache_info->header, sizeof(struct pcache_cache_info)); + cache->info_index = (cache->info_index + 1) % PCACHE_META_INDEX_MAX; memcpy_flushcache(get_cache_info_addr(cache), cache_info, sizeof(struct pcache_cache_info)); - - cache->info_index = (cache->info_index + 1) % PCACHE_META_INDEX_MAX; + pmem_wmb(); } static void cache_info_init_default(struct pcache_cache *cache); @@ -93,10 +93,10 @@ void cache_pos_encode(struct pcache_cache *cache, pos_onmedia.header.seq = seq; pos_onmedia.header.crc = cache_pos_onmedia_crc(&pos_onmedia); + *index = (*index + 1) % PCACHE_META_INDEX_MAX; + memcpy_flushcache(pos_onmedia_addr, &pos_onmedia, sizeof(struct pcache_cache_pos_onmedia)); pmem_wmb(); - - *index = (*index + 1) % PCACHE_META_INDEX_MAX; } int cache_pos_decode(struct pcache_cache *cache, diff --git a/drivers/md/dm-pcache/cache_segment.c b/drivers/md/dm-pcache/cache_segment.c index f0b58980806e..ae57cc261422 100644 --- a/drivers/md/dm-pcache/cache_segment.c +++ b/drivers/md/dm-pcache/cache_segment.c @@ -26,11 +26,11 @@ static void cache_seg_info_write(struct pcache_cache_segment *cache_seg) seg_info->header.seq++; seg_info->header.crc = pcache_meta_crc(&seg_info->header, sizeof(struct pcache_segment_info)); + cache_seg->info_index = (cache_seg->info_index + 1) % PCACHE_META_INDEX_MAX; + seg_info_addr = get_seg_info_addr(cache_seg); memcpy_flushcache(seg_info_addr, seg_info, sizeof(struct pcache_segment_info)); pmem_wmb(); - - cache_seg->info_index = (cache_seg->info_index + 1) % PCACHE_META_INDEX_MAX; mutex_unlock(&cache_seg->info_lock); } @@ -129,10 +129,10 @@ static void cache_seg_ctrl_write(struct pcache_cache_segment *cache_seg) cache_seg_gen.header.crc = pcache_meta_crc(&cache_seg_gen.header, sizeof(struct pcache_cache_seg_gen)); + cache_seg->gen_index = (cache_seg->gen_index + 1) % PCACHE_META_INDEX_MAX; + memcpy_flushcache(get_cache_seg_gen_addr(cache_seg), &cache_seg_gen, sizeof(struct pcache_cache_seg_gen)); pmem_wmb(); - - cache_seg->gen_index = (cache_seg->gen_index + 1) % PCACHE_META_INDEX_MAX; } static void cache_seg_ctrl_init(struct pcache_cache_segment *cache_seg) -- 2.43.0

3 days, 22 hours

1
2
0 0

[PATCH AUTOSEL 6.18-6.17] crypto: ccp - Add support for PCI device 0x115A

by Sasha Levin

From: "Mario Limonciello (AMD)" <superm1(a)kernel.org> [ Upstream commit 9fc6290117259a8dbf8247cb54559df62fd1550f ] PCI device 0x115A is similar to pspv5, except it doesn't have platform access mailbox support. Signed-off-by: Mario Limonciello (AMD) <superm1(a)kernel.org> Acked-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Comprehensive Analysis ### 1. COMMIT MESSAGE ANALYSIS **Subject:** `crypto: ccp - Add support for PCI device 0x115A` **Key Information:** - PCI device 0x115A is a new AMD security processor variant - The commit message states it's "similar to pspv5, except it doesn't have platform access mailbox support" - Signed off by Mario Limonciello (AMD engineer) and Tom Lendacky (AMD) - Merged by Herbert Xu (crypto maintainer) **Tags Present:** - `Signed-off-by`: 3 (proper sign-off chain) - `Acked-by`: Tom Lendacky (driver maintainer acknowledgment) - **NO** `Cc: stable(a)vger.kernel.org` tag - **NO** `Fixes:` tag (this is expected - it's not fixing a bug, it's enabling hardware) ### 2. CODE CHANGE ANALYSIS The commit adds: **A) New `pspv7` structure (~10 lines):** ```c static const struct psp_vdata pspv7 = { .tee = &teev2, .cmdresp_reg = 0x10944, .cmdbuff_addr_lo_reg = 0x10948, .cmdbuff_addr_hi_reg = 0x1094c, .bootloader_info_reg = 0x109ec, .feature_reg = 0x109fc, .inten_reg = 0x10510, .intsts_reg = 0x10514, }; ``` This is **identical to pspv5** except it omits the `.platform_access = &pa_v2` field. This is the explicit difference mentioned in the commit message. **B) New `dev_vdata[9]` entry (~6 lines):** ```c { /* 9 */ .bar = 2, #ifdef CONFIG_CRYPTO_DEV_SP_PSP .psp_vdata = &pspv7, #endif }, ``` **C) New PCI device ID entry (1 line):** ```c { PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] }, ``` ### 3. CLASSIFICATION **This is a NEW DEVICE ID addition** - one of the explicitly allowed exceptions for stable kernel backports. The commit: - Does NOT add new features or APIs - Does NOT change existing behavior - Only enables existing PSP driver functionality on new hardware - Uses established patterns already in the driver ### 4. SCOPE AND RISK ASSESSMENT **Change size:** ~17 lines total - Small, contained data-only change - No logic changes whatsoever - Follows identical patterns used by existing pspv1-pspv6 structures **Risk assessment: VERY LOW** - The driver already handles NULL `platform_access` - verified in `psp- dev.c`: ```c if (psp->vdata->platform_access) { ret = platform_access_dev_init(psp); ... } ``` - Several existing structures (pspv1, pspv4, pspv6) already omit `platform_access` - The `teev2` structure referenced already exists since v6.5 - All register offsets are identical to pspv5 ### 5. USER IMPACT **Who is affected:** - Users with AMD PCI device 0x115A (new AMD security processor variant) - Without this patch, this hardware is completely non-functional **Severity:** HIGH for affected users - enables critical security hardware (TPM-like functionality) ### 6. STABILITY INDICATORS **Positive signals:** - Acked by Tom Lendacky (the original driver author and AMD maintainer) - Follows exact same pattern as 10+ previous device ID additions in this driver - Same author (Mario Limonciello) has successfully added similar devices before (0x17E0, 0x156E, etc.) ### 7. DEPENDENCY CHECK **Required in stable tree:** - `teev2` structure - added in v6.5 (commit 4aa0931be8f0a) - Verified present in v6.6 and later **Recent related commits:** - 52e8ae868a824: "Add missing bootloader info reg for pspv5" (May 2025) - 72942d6538564: "Add missing tee info reg for teev2" (May 2025) The pspv7 structure in this commit already includes the `bootloader_info_reg` correctly, so it was created after these fixes. ### 8. COMPARISON WITH SIMILAR COMMITS This commit follows the exact same pattern as: - `bb4185e595e47`: "Add support for PCI device 0x156E" - Added pspv6 + dev_vdata[8] + PCI ID - `4aa0931be8f0a`: "Add support for PCI device 0x17E0" - Added pspv5/teev2 + dev_vdata[7] + PCI ID - `6cb345939b8cc`: "Add support for PCI device 0x1134" - Added PCI ID only - `63935e2ee1f2a`: "Add support for PCI device 0x17D8" - Added PCI ID only These similar device ID additions are routinely considered for stable trees. --- ## Final Assessment **Should this be backported?** **YES**, for the following reasons: 1. **Falls under the NEW DEVICE ID exception** - explicitly allowed per stable kernel rules for enabling real hardware 2. **Trivial, data-only change** - ~17 lines, no logic changes 3. **Uses existing, proven infrastructure** - teev2 exists, NULL platform_access handling exists 4. **Follows established patterns** - identical to 10+ previous similar commits in this driver 5. **Zero risk of regression** - only affects users with the specific 0x115A device 6. **Enables real hardware** - without this, users with this AMD security processor cannot use it at all 7. **Properly reviewed** - Acked by AMD maintainer, merged by crypto subsystem maintainer **Concerns:** - Requires stable tree to have v6.6+ (for teev2 structure) - May need the bootloader_info_reg fixes backported first for consistency (commits 52e8ae868a824 and 72942d6538564) The change is obviously correct, well-tested (used same patterns as existing code), and enables hardware support that users need. This is exactly the type of device ID addition that stable trees accept. **YES** drivers/crypto/ccp/sp-pci.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c index e7bb803912a6d..8891ceee1d7d0 100644 --- a/drivers/crypto/ccp/sp-pci.c +++ b/drivers/crypto/ccp/sp-pci.c @@ -459,6 +459,17 @@ static const struct psp_vdata pspv6 = { .intsts_reg = 0x10514, /* P2CMSG_INTSTS */ }; +static const struct psp_vdata pspv7 = { + .tee = &teev2, + .cmdresp_reg = 0x10944, /* C2PMSG_17 */ + .cmdbuff_addr_lo_reg = 0x10948, /* C2PMSG_18 */ + .cmdbuff_addr_hi_reg = 0x1094c, /* C2PMSG_19 */ + .bootloader_info_reg = 0x109ec, /* C2PMSG_59 */ + .feature_reg = 0x109fc, /* C2PMSG_63 */ + .inten_reg = 0x10510, /* P2CMSG_INTEN */ + .intsts_reg = 0x10514, /* P2CMSG_INTSTS */ +}; + #endif static const struct sp_dev_vdata dev_vdata[] = { @@ -525,6 +536,13 @@ static const struct sp_dev_vdata dev_vdata[] = { .psp_vdata = &pspv6, #endif }, + { /* 9 */ + .bar = 2, +#ifdef CONFIG_CRYPTO_DEV_SP_PSP + .psp_vdata = &pspv7, +#endif + }, + }; static const struct pci_device_id sp_pci_table[] = { { PCI_VDEVICE(AMD, 0x1537), (kernel_ulong_t)&dev_vdata[0] }, @@ -539,6 +557,7 @@ static const struct pci_device_id sp_pci_table[] = { { PCI_VDEVICE(AMD, 0x17E0), (kernel_ulong_t)&dev_vdata[7] }, { PCI_VDEVICE(AMD, 0x156E), (kernel_ulong_t)&dev_vdata[8] }, { PCI_VDEVICE(AMD, 0x17D8), (kernel_ulong_t)&dev_vdata[8] }, + { PCI_VDEVICE(AMD, 0x115A), (kernel_ulong_t)&dev_vdata[9] }, /* Last entry must be zero */ { 0, } }; -- 2.51.0

3 days, 23 hours

1
2
0 0

[PATCH] hwmon: (dell-smm): Fix off-by-one error in dell_smm_is_visible()

by Armin Wolf

The documentation states that on machines supporting only global fan mode control, the pwmX_enable attributes should only be created for the first fan channel (pwm1_enable, aka channel 0). Fix the off-by-one error caused by the fact that fan channels have a zero-based index. Cc: stable(a)vger.kernel.org Fixes: 1c1658058c99 ("hwmon: (dell-smm) Add support for automatic fan mode") Signed-off-by: Armin Wolf <W_Armin(a)gmx.de> --- drivers/hwmon/dell-smm-hwmon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/dell-smm-hwmon.c index 683baf361c4c..a34753fc2973 100644 --- a/drivers/hwmon/dell-smm-hwmon.c +++ b/drivers/hwmon/dell-smm-hwmon.c @@ -861,9 +861,9 @@ static umode_t dell_smm_is_visible(const void *drvdata, enum hwmon_sensor_types if (auto_fan) { /* * The setting affects all fans, so only create a - * single attribute. + * single attribute for the first fan channel. */ - if (channel != 1) + if (channel != 0) return 0; /* -- 2.39.5

4 days

2
1
0 0

[PATCH] hwmon: (w83791d) Convert macros to functions to avoid TOCTOU

by Gui-Dong Han

The macro FAN_FROM_REG evaluates its arguments multiple times. When used in lockless contexts involving shared driver data, this leads to Time-of-Check to Time-of-Use (TOCTOU) race conditions, potentially causing divide-by-zero errors. Convert the macro to a static function. This guarantees that arguments are evaluated only once (pass-by-value), preventing the race conditions. Additionally, in store_fan_div, move the calculation of the minimum limit inside the update lock. This ensures that the read-modify-write sequence operates on consistent data. Adhere to the principle of minimal changes by only converting macros that evaluate arguments multiple times and are used in lockless contexts. Link: https://lore.kernel.org/all/CALbr=LYJ_ehtp53HXEVkSpYoub+XYSTU8Rg=o1xxMJ8=5z… Fixes: 9873964d6eb2 ("[PATCH] HWMON: w83791d: New hardware monitoring driver for the Winbond W83791D") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)gmail.com> --- Based on the discussion in the link, I will submit a series of patches to address TOCTOU issues in the hwmon subsystem by converting macros to functions or adjusting locking where appropriate. --- drivers/hwmon/w83791d.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/hwmon/w83791d.c b/drivers/hwmon/w83791d.c index ace854b370a0..996e36951f9d 100644 --- a/drivers/hwmon/w83791d.c +++ b/drivers/hwmon/w83791d.c @@ -218,9 +218,14 @@ static u8 fan_to_reg(long rpm, int div) return clamp_val((1350000 + rpm * div / 2) / (rpm * div), 1, 254); } -#define FAN_FROM_REG(val, div) ((val) == 0 ? -1 : \ - ((val) == 255 ? 0 : \ - 1350000 / ((val) * (div)))) +static int fan_from_reg(int val, int div) +{ + if (val == 0) + return -1; + if (val == 255) + return 0; + return 1350000 / (val * div); +} /* for temp1 which is 8-bit resolution, LSB = 1 degree Celsius */ #define TEMP1_FROM_REG(val) ((val) * 1000) @@ -521,7 +526,7 @@ static ssize_t show_##reg(struct device *dev, struct device_attribute *attr, \ struct w83791d_data *data = w83791d_update_device(dev); \ int nr = sensor_attr->index; \ return sprintf(buf, "%d\n", \ - FAN_FROM_REG(data->reg[nr], DIV_FROM_REG(data->fan_div[nr]))); \ + fan_from_reg(data->reg[nr], DIV_FROM_REG(data->fan_div[nr]))); \ } show_fan_reg(fan); @@ -585,10 +590,10 @@ static ssize_t store_fan_div(struct device *dev, struct device_attribute *attr, if (err) return err; + mutex_lock(&data->update_lock); /* Save fan_min */ - min = FAN_FROM_REG(data->fan_min[nr], DIV_FROM_REG(data->fan_div[nr])); + min = fan_from_reg(data->fan_min[nr], DIV_FROM_REG(data->fan_div[nr])); - mutex_lock(&data->update_lock); data->fan_div[nr] = div_to_reg(nr, val); switch (nr) { -- 2.43.0

4 days

2
1
0 0

[PATCH AUTOSEL 6.18-5.10] ACPI: property: Use ACPI functions in acpi_graph_get_next_endpoint() only

by Sasha Levin

From: Sakari Ailus <sakari.ailus(a)linux.intel.com> [ Upstream commit 5d010473cdeaabf6a2d3a9e2aed2186c1b73c213 ] Calling fwnode_get_next_child_node() in ACPI implementation of the fwnode property API is somewhat problematic as the latter is used in the impelementation of the former. Instead of using fwnode_get_next_child_node() in acpi_graph_get_next_endpoint(), call acpi_get_next_subnode() directly instead. Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Reviewed-by: Jonathan Cameron <jonathan.cameron(a)huawei.com> Link: https://patch.msgid.link/20251001104320.1272752-3-sakari.ailus@linux.intel.… Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Analysis ### 1. COMMIT MESSAGE ANALYSIS The commit message states: - Problem: `acpi_graph_get_next_endpoint()` calls `fwnode_get_next_child_node()`, which dispatches back to ACPI code, creating unnecessary indirection. - Solution: Call `acpi_get_next_subnode()` directly instead. No "Cc: stable(a)vger.kernel.org" tag, no "Fixes:" tag, no explicit bug report link. The message says "somewhat problematic," indicating an architectural issue rather than a critical bug. ### 2. CODE CHANGE ANALYSIS The diff shows 4 replacements in `acpi_graph_get_next_endpoint()`: - Line 1475: `fwnode_get_next_child_node(fwnode, port)` → `acpi_get_next_subnode(fwnode, port)` - Line 1493: `fwnode_get_next_child_node(port, prev)` → `acpi_get_next_subnode(port, prev)` - Line 1495: `fwnode_get_next_child_node(fwnode, port)` → `acpi_get_next_subnode(fwnode, port)` - Line 1499: `fwnode_get_next_child_node(port, NULL)` → `acpi_get_next_subnode(port, NULL)` Call chain: 1. `fwnode_get_next_child_node()` dispatches via `fwnode_call_ptr_op()` to the fwnode-specific implementation. 2. For ACPI fwnodes, it calls `acpi_get_next_present_subnode()` (registered at line 1747). 3. `acpi_get_next_present_subnode()` filters non-present device nodes and calls `acpi_get_next_subnode()`. Why the change is safe: - Graph endpoints are ACPI data nodes (checked by `is_acpi_graph_node()` at line 1448: `is_acpi_data_node(fwnode)`). - `acpi_get_next_present_subnode()` only filters non-present device nodes (lines 1407-1408), not data nodes. - Therefore, for graph endpoints, `acpi_get_next_subnode()` and `fwnode_get_next_child_node()` behave the same. ### 3. CLASSIFICATION This is a bug fix addressing an architectural issue: - Removes unnecessary indirection in ACPI-specific code. - Avoids a circular dependency pattern (ACPI → generic → ACPI). - Functionally equivalent for graph endpoints. Not a feature addition, not a new API, not a refactor. ### 4. SCOPE AND RISK ASSESSMENT - Scope: 4 lines changed in one function in one file. - Risk: Very low — same behavior for graph endpoints, cleaner architecture. - Complexity: Low — direct function call replacement. ### 5. USER IMPACT - Who is affected: Users of ACPI graph endpoints (e.g., camera/media drivers, device tree-like ACPI usage). - Severity: Low — architectural improvement, not a visible bug fix. - Likelihood: The "somewhat problematic" wording suggests no immediate user-visible issue. ### 6. STABILITY INDICATORS - Reviewed-by: Laurent Pinchart, Jonathan Cameron - Signed-off-by: Rafael J. Wysocki (ACPI maintainer) - No "Tested-by:" tags - Commit date: October 1, 2025 (recent) ### 7. DEPENDENCY CHECK - `acpi_get_next_subnode()` exists in the same file and has been present for years. - No external dependencies introduced. - Should apply cleanly to stable trees that have this code. ### 8. HISTORICAL CONTEXT Related commits: - `79389a83bc388`: Introduced `acpi_graph_get_next_endpoint()` with `fwnode_get_next_child_node()` calls. - `48698e6cf44c3`: Introduced `acpi_get_next_present_subnode()` to filter non-present devices. - `5d010473cdeaa` (this commit): Removes the indirection. The pattern existed since the function was introduced; this commit cleans it up. ### 9. STABLE KERNEL CRITERIA EVALUATION - Obviously correct: Yes — direct call instead of indirection. - Fixes a real bug: Yes — architectural issue that could cause problems. - Important issue: Moderate — architectural improvement, not a critical bug. - Small and contained: Yes — 4 lines, single function. - No new features: Yes — same behavior, cleaner code. - Applies cleanly: Yes — should apply without conflicts. ### 10. RISK VS BENEFIT Benefits: - Removes unnecessary indirection. - Avoids circular dependency pattern. - Improves code clarity. - No functional change for graph endpoints. Risks: - Very low — functionally equivalent change. - No new code paths or logic changes. ### 11. CONCERNS AND CONSIDERATIONS - No "Cc: stable" tag, but that alone doesn't disqualify. - Recent commit (Oct 2025) — hasn't been in mainline long. - No explicit bug report or user complaint mentioned. - Architectural improvement rather than a critical fix. ### CONCLUSION This is a small, correct fix that removes unnecessary indirection in ACPI code. It fixes an architectural issue and is functionally equivalent for graph endpoints. It meets stable kernel criteria: correct, fixes a real issue, small scope, no new features, and should apply cleanly. However, it's an architectural improvement rather than a critical bug fix, and there's no explicit stable tag or user-visible bug report. The "somewhat problematic" wording suggests it may not cause immediate visible problems. Given the conservative nature of stable trees and the lack of evidence of user-visible impact, this is borderline but leans toward acceptable for stable backporting due to its correctness, small scope, and architectural benefit. **YES** drivers/acpi/property.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c index 43d5e457814e1..76158b1399029 100644 --- a/drivers/acpi/property.c +++ b/drivers/acpi/property.c @@ -1472,7 +1472,7 @@ static struct fwnode_handle *acpi_graph_get_next_endpoint( if (!prev) { do { - port = fwnode_get_next_child_node(fwnode, port); + port = acpi_get_next_subnode(fwnode, port); /* * The names of the port nodes begin with "port@" * followed by the number of the port node and they also @@ -1490,13 +1490,13 @@ static struct fwnode_handle *acpi_graph_get_next_endpoint( if (!port) return NULL; - endpoint = fwnode_get_next_child_node(port, prev); + endpoint = acpi_get_next_subnode(port, prev); while (!endpoint) { - port = fwnode_get_next_child_node(fwnode, port); + port = acpi_get_next_subnode(fwnode, port); if (!port) break; if (is_acpi_graph_node(port, "port")) - endpoint = fwnode_get_next_child_node(port, NULL); + endpoint = acpi_get_next_subnode(port, NULL); } /* -- 2.51.0

4 days

1
6
0 0

[PATCH net] net: phy: marvell-88q2xxx: Fix clamped value in mv88q2xxx_hwmon_write

by Thorsten Blum

The local variable 'val' was never clamped to -75000 or 180000 because the return value of clamp_val() was not used. Fix this by assigning the clamped value back to 'val', and use clamp() instead of clamp_val(). Cc: stable(a)vger.kernel.org Fixes: a557a92e6881 ("net: phy: marvell-88q2xxx: add support for temperature sensor") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/net/phy/marvell-88q2xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/marvell-88q2xxx.c b/drivers/net/phy/marvell-88q2xxx.c index f3d83b04c953..201dee1a1698 100644 --- a/drivers/net/phy/marvell-88q2xxx.c +++ b/drivers/net/phy/marvell-88q2xxx.c @@ -698,7 +698,7 @@ static int mv88q2xxx_hwmon_write(struct device *dev, switch (attr) { case hwmon_temp_max: - clamp_val(val, -75000, 180000); + val = clamp(val, -75000, 180000); val = (val / 1000) + 75; val = FIELD_PREP(MDIO_MMD_PCS_MV_TEMP_SENSOR3_INT_THRESH_MASK, val); -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

4 days

4
3
0 0

[PATCH 1/1] phy: tegra: xusb: Fix UTMI AO sleepwalk trigger programming sequence

by Wayne Chang

From: Haotien Hsu <haotienh(a)nvidia.com> The UTMIP sleepwalk programming sequence requires asserting both LINEVAL_WALK_EN and WAKE_WALK_EN when enabling the sleepwalk logic. However, the current code mistakenly cleared WAKE_WALK_EN, which prevents the sleepwalk trigger from operating correctly. Fix this by asserting WAKE_WALK_EN together with LINEVAL_WALK_EN. Fixes: 1f9cab6cc20c ("phy: tegra: xusb: Add wake/sleepwalk for Tegra186") Cc: stable(a)vger.kernel.org Signed-off-by: Haotien Hsu <haotienh(a)nvidia.com> Signed-off-by: Wayne Chang <waynec(a)nvidia.com> --- drivers/phy/tegra/xusb-tegra186.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c index e818f6c3980e..b2a76710c0c4 100644 --- a/drivers/phy/tegra/xusb-tegra186.c +++ b/drivers/phy/tegra/xusb-tegra186.c @@ -401,8 +401,7 @@ static int tegra186_utmi_enable_phy_sleepwalk(struct tegra_xusb_lane *lane, /* enable the trigger of the sleepwalk logic */ value = ao_readl(priv, XUSB_AO_UTMIP_SLEEPWALK_CFG(index)); - value |= LINEVAL_WALK_EN; - value &= ~WAKE_WALK_EN; + value |= LINEVAL_WALK_EN | WAKE_WALK_EN; ao_writel(priv, value, XUSB_AO_UTMIP_SLEEPWALK_CFG(index)); /* reset the walk pointer and clear the alarm of the sleepwalk logic, -- 2.25.1

4 days

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror