From 745a579b614ed0657e3730e42d58a7cf8d7ad9d4 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 1 Sep 2025 14:48:45 +0200 Subject: [PATCH] 6.12-stable patches added patches: blk-zoned-fix-a-lockdep-complaint-about-recursive-locking.patch dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch drm-amd-amdgpu-disable-hwmon-power1_cap-for-gfx-11.0.3-on-vf-mode.patch drm-mediatek-fix-device-node-reference-count-leaks-in-mtk_drm_get_all_drm_priv.patch drm-nouveau-disp-always-accept-linear-modifier.patch drm-nouveau-fix-error-path-in-nvkm_gsp_fwsec_v2.patch drm-xe-vm-clear-the-scratch_pt-pointer-on-error.patch fs-smb-fix-inconsistent-refcnt-update.patch hid-asus-fix-uaf-via-hid_claimed_input-validation.patch hid-hid-ntrig-fix-unable-to-handle-page-fault-in-ntrig_report_version.patch hid-logitech-add-ids-for-g-pro-2-lightspeed.patch hid-multitouch-fix-slab-out-of-bounds-access-in-mt_report_fixup.patch hid-quirks-add-support-for-legion-go-dual-dinput-modes.patch hid-wacom-add-a-new-art-pen-2.patch kvm-x86-use-array_index_nospec-with-indices-that-come-from-guest.patch net-usb-qmi_wwan-add-telit-cinterion-le910c4-wwx-new-compositions.patch revert-drm-amdgpu-fix-incorrect-vm-flags-to-map-bo.patch risc-v-kvm-fix-stack-overrun-when-loading-vlenb.patch smb3-client-fix-return-code-mapping-of-remap_file_range.patch x86-cpu-topology-use-initial-apic-id-from-xtopology-leaf-on-amd-hygon.patch x86-microcode-amd-handle-the-case-of-no-bios-microcode.patch xfs-do-not-propagate-enodata-disk-errors-into-xattr-code.patch --- ...ep-complaint-about-recursive-locking.patch | 119 +++++++++++++++ ...rect_remap-allocations-are-decrypted.patch | 48 +++++++ ...power1_cap-for-gfx-11.0.3-on-vf-mode.patch | 50 +++++++ ...nt-leaks-in-mtk_drm_get_all_drm_priv.patch | 83 +++++++++++ ...u-disp-always-accept-linear-modifier.patch | 38 +++++ ...-fix-error-path-in-nvkm_gsp_fwsec_v2.patch | 40 ++++++ ...lear-the-scratch_pt-pointer-on-error.patch | 47 ++++++ ...s-smb-fix-inconsistent-refcnt-update.patch | 59 ++++++++ ...uaf-via-hid_claimed_input-validation.patch | 135 ++++++++++++++++++ ...e-page-fault-in-ntrig_report_version.patch | 39 +++++ ...itech-add-ids-for-g-pro-2-lightspeed.patch | 65 +++++++++ ...-of-bounds-access-in-mt_report_fixup.patch | 75 ++++++++++ ...port-for-legion-go-dual-dinput-modes.patch | 51 +++++++ .../hid-wacom-add-a-new-art-pen-2.patch | 26 ++++ ...ec-with-indices-that-come-from-guest.patch | 56 ++++++++ ...nterion-le910c4-wwx-new-compositions.patch | 104 ++++++++++++++ ...gpu-fix-incorrect-vm-flags-to-map-bo.patch | 34 +++++ ...fix-stack-overrun-when-loading-vlenb.patch | 38 +++++ queue-6.12/series | 22 +++ ...urn-code-mapping-of-remap_file_range.patch | 47 ++++++ ...-id-from-xtopology-leaf-on-amd-hygon.patch | 113 +++++++++++++++ ...handle-the-case-of-no-bios-microcode.patch | 66 +++++++++ ...-enodata-disk-errors-into-xattr-code.patch | 81 +++++++++++ 23 files changed, 1436 insertions(+) create mode 100644 queue-6.12/blk-zoned-fix-a-lockdep-complaint-about-recursive-locking.patch create mode 100644 queue-6.12/dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch create mode 100644 queue-6.12/drm-amd-amdgpu-disable-hwmon-power1_cap-for-gfx-11.0.3-on-vf-mode.patch create mode 100644 queue-6.12/drm-mediatek-fix-device-node-reference-count-leaks-in-mtk_drm_get_all_drm_priv.patch create mode 100644 queue-6.12/drm-nouveau-disp-always-accept-linear-modifier.patch create mode 100644 queue-6.12/drm-nouveau-fix-error-path-in-nvkm_gsp_fwsec_v2.patch create mode 100644 queue-6.12/drm-xe-vm-clear-the-scratch_pt-pointer-on-error.patch create mode 100644 queue-6.12/fs-smb-fix-inconsistent-refcnt-update.patch create mode 100644 queue-6.12/hid-asus-fix-uaf-via-hid_claimed_input-validation.patch create mode 100644 queue-6.12/hid-hid-ntrig-fix-unable-to-handle-page-fault-in-ntrig_report_version.patch create mode 100644 queue-6.12/hid-logitech-add-ids-for-g-pro-2-lightspeed.patch create mode 100644 queue-6.12/hid-multitouch-fix-slab-out-of-bounds-access-in-mt_report_fixup.patch create mode 100644 queue-6.12/hid-quirks-add-support-for-legion-go-dual-dinput-modes.patch create mode 100644 queue-6.12/hid-wacom-add-a-new-art-pen-2.patch create mode 100644 queue-6.12/kvm-x86-use-array_index_nospec-with-indices-that-come-from-guest.patch create mode 100644 queue-6.12/net-usb-qmi_wwan-add-telit-cinterion-le910c4-wwx-new-compositions.patch create mode 100644 queue-6.12/revert-drm-amdgpu-fix-incorrect-vm-flags-to-map-bo.patch create mode 100644 queue-6.12/risc-v-kvm-fix-stack-overrun-when-loading-vlenb.patch create mode 100644 queue-6.12/smb3-client-fix-return-code-mapping-of-remap_file_range.patch create mode 100644 queue-6.12/x86-cpu-topology-use-initial-apic-id-from-xtopology-leaf-on-amd-hygon.patch create mode 100644 queue-6.12/x86-microcode-amd-handle-the-case-of-no-bios-microcode.patch create mode 100644 queue-6.12/xfs-do-not-propagate-enodata-disk-errors-into-xattr-code.patch diff --git a/queue-6.12/blk-zoned-fix-a-lockdep-complaint-about-recursive-locking.patch b/queue-6.12/blk-zoned-fix-a-lockdep-complaint-about-recursive-locking.patch new file mode 100644 index 0000000000..98b85a4e10 --- /dev/null +++ b/queue-6.12/blk-zoned-fix-a-lockdep-complaint-about-recursive-locking.patch @@ -0,0 +1,119 @@ +From 198f36f902ec7e99b645382505f74b87a4523ed9 Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Mon, 25 Aug 2025 11:27:19 -0700 +Subject: blk-zoned: Fix a lockdep complaint about recursive locking + +From: Bart Van Assche + +commit 198f36f902ec7e99b645382505f74b87a4523ed9 upstream. + +If preparing a write bio fails then blk_zone_wplug_bio_work() calls +bio_endio() with zwplug->lock held. If a device mapper driver is stacked +on top of the zoned block device then this results in nested locking of +zwplug->lock. The resulting lockdep complaint is a false positive +because this is nested locking and not recursive locking. Suppress this +false positive by calling blk_zone_wplug_bio_io_error() without holding +zwplug->lock. This is safe because no code in +blk_zone_wplug_bio_io_error() depends on zwplug->lock being held. This +patch suppresses the following lockdep complaint: + +WARNING: possible recursive locking detected +-------------------------------------------- +kworker/3:0H/46 is trying to acquire lock: +ffffff882968b830 (&zwplug->lock){-...}-{2:2}, at: blk_zone_write_plug_bio_endio+0x64/0x1f0 + +but task is already holding lock: +ffffff88315bc230 (&zwplug->lock){-...}-{2:2}, at: blk_zone_wplug_bio_work+0x8c/0x48c + +other info that might help us debug this: + Possible unsafe locking scenario: + + CPU0 + ---- + lock(&zwplug->lock); + lock(&zwplug->lock); + + *** DEADLOCK *** + + May be due to missing lock nesting notation + +3 locks held by kworker/3:0H/46: + #0: ffffff8809486758 ((wq_completion)sdd_zwplugs){+.+.}-{0:0}, at: process_one_work+0x1bc/0x65c + #1: ffffffc085de3d70 ((work_completion)(&zwplug->bio_work)){+.+.}-{0:0}, at: process_one_work+0x1e4/0x65c + #2: ffffff88315bc230 (&zwplug->lock){-...}-{2:2}, at: blk_zone_wplug_bio_work+0x8c/0x48c + +stack backtrace: +CPU: 3 UID: 0 PID: 46 Comm: kworker/3:0H Tainted: G W OE 6.12.38-android16-5-maybe-dirty-4k #1 8b362b6f76e3645a58cd27d86982bce10d150025 +Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE +Hardware name: Spacecraft board based on MALIBU (DT) +Workqueue: sdd_zwplugs blk_zone_wplug_bio_work +Call trace: + dump_backtrace+0xfc/0x17c + show_stack+0x18/0x28 + dump_stack_lvl+0x40/0xa0 + dump_stack+0x18/0x24 + print_deadlock_bug+0x38c/0x398 + __lock_acquire+0x13e8/0x2e1c + lock_acquire+0x134/0x2b4 + _raw_spin_lock_irqsave+0x5c/0x80 + blk_zone_write_plug_bio_endio+0x64/0x1f0 + bio_endio+0x9c/0x240 + __dm_io_complete+0x214/0x260 + clone_endio+0xe8/0x214 + bio_endio+0x218/0x240 + blk_zone_wplug_bio_work+0x204/0x48c + process_one_work+0x26c/0x65c + worker_thread+0x33c/0x498 + kthread+0x110/0x134 + ret_from_fork+0x10/0x20 + +Cc: stable@vger.kernel.org +Cc: Damien Le Moal +Cc: Christoph Hellwig +Fixes: dd291d77cc90 ("block: Introduce zone write plugging") +Signed-off-by: Bart Van Assche +Reviewed-by: Damien Le Moal +Link: https://lore.kernel.org/r/20250825182720.1697203-1-bvanassche@acm.org +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-zoned.c | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +--- a/block/blk-zoned.c ++++ b/block/blk-zoned.c +@@ -1281,14 +1281,14 @@ static void blk_zone_wplug_bio_work(stru + struct block_device *bdev; + unsigned long flags; + struct bio *bio; ++ bool prepared; + + /* + * Submit the next plugged BIO. If we do not have any, clear + * the plugged flag. + */ +- spin_lock_irqsave(&zwplug->lock, flags); +- + again: ++ spin_lock_irqsave(&zwplug->lock, flags); + bio = bio_list_pop(&zwplug->bio_list); + if (!bio) { + zwplug->flags &= ~BLK_ZONE_WPLUG_PLUGGED; +@@ -1296,13 +1296,14 @@ again: + goto put_zwplug; + } + +- if (!blk_zone_wplug_prepare_bio(zwplug, bio)) { ++ prepared = blk_zone_wplug_prepare_bio(zwplug, bio); ++ spin_unlock_irqrestore(&zwplug->lock, flags); ++ ++ if (!prepared) { + blk_zone_wplug_bio_io_error(zwplug, bio); + goto again; + } + +- spin_unlock_irqrestore(&zwplug->lock, flags); +- + bdev = bio->bi_bdev; + + /* diff --git a/queue-6.12/dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch b/queue-6.12/dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch new file mode 100644 index 0000000000..07f86efc23 --- /dev/null +++ b/queue-6.12/dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch @@ -0,0 +1,48 @@ +From 89a2d212bdb4bc29bed8e7077abe054b801137ea Mon Sep 17 00:00:00 2001 +From: Shanker Donthineni +Date: Mon, 11 Aug 2025 13:17:59 -0500 +Subject: dma/pool: Ensure DMA_DIRECT_REMAP allocations are decrypted + +From: Shanker Donthineni + +commit 89a2d212bdb4bc29bed8e7077abe054b801137ea upstream. + +When CONFIG_DMA_DIRECT_REMAP is enabled, atomic pool pages are +remapped via dma_common_contiguous_remap() using the supplied +pgprot. Currently, the mapping uses +pgprot_dmacoherent(PAGE_KERNEL), which leaves the memory encrypted +on systems with memory encryption enabled (e.g., ARM CCA Realms). + +This can cause the DMA layer to fail or crash when accessing the +memory, as the underlying physical pages are not configured as +expected. + +Fix this by requesting a decrypted mapping in the vmap() call: +pgprot_decrypted(pgprot_dmacoherent(PAGE_KERNEL)) + +This ensures that atomic pool memory is consistently mapped +unencrypted. + +Cc: stable@vger.kernel.org +Signed-off-by: Shanker Donthineni +Reviewed-by: Catalin Marinas +Signed-off-by: Marek Szyprowski +Link: https://lore.kernel.org/r/20250811181759.998805-1-sdonthineni@nvidia.com +Signed-off-by: Greg Kroah-Hartman +--- + kernel/dma/pool.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/dma/pool.c ++++ b/kernel/dma/pool.c +@@ -102,8 +102,8 @@ static int atomic_pool_expand(struct gen + + #ifdef CONFIG_DMA_DIRECT_REMAP + addr = dma_common_contiguous_remap(page, pool_size, +- pgprot_dmacoherent(PAGE_KERNEL), +- __builtin_return_address(0)); ++ pgprot_decrypted(pgprot_dmacoherent(PAGE_KERNEL)), ++ __builtin_return_address(0)); + if (!addr) + goto free_page; + #else diff --git a/queue-6.12/drm-amd-amdgpu-disable-hwmon-power1_cap-for-gfx-11.0.3-on-vf-mode.patch b/queue-6.12/drm-amd-amdgpu-disable-hwmon-power1_cap-for-gfx-11.0.3-on-vf-mode.patch new file mode 100644 index 0000000000..33c0c3ef99 --- /dev/null +++ b/queue-6.12/drm-amd-amdgpu-disable-hwmon-power1_cap-for-gfx-11.0.3-on-vf-mode.patch @@ -0,0 +1,50 @@ +From 5dff50802b285da8284a7bf17ae2fdc6f1357023 Mon Sep 17 00:00:00 2001 +From: Yang Wang +Date: Mon, 25 Aug 2025 12:54:01 +0800 +Subject: drm/amd/amdgpu: disable hwmon power1_cap* for gfx 11.0.3 on vf mode + +From: Yang Wang + +commit 5dff50802b285da8284a7bf17ae2fdc6f1357023 upstream. + +the PPSMC_MSG_GetPptLimit msg is not valid for gfx 11.0.3 on vf mode, +so skiped to create power1_cap* hwmon sysfs node. + +Signed-off-by: Yang Wang +Reviewed-by: Asad Kamal +Acked-by: Alex Deucher +Signed-off-by: Alex Deucher +(cherry picked from commit e82a8d441038d8cb10b63047a9e705c42479d156) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/amdgpu_pm.c | 18 ++++++++++-------- + 1 file changed, 10 insertions(+), 8 deletions(-) + +--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c ++++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c +@@ -3668,14 +3668,16 @@ static umode_t hwmon_attributes_visible( + effective_mode &= ~S_IWUSR; + + /* not implemented yet for APUs other than GC 10.3.1 (vangogh) and 9.4.3 */ +- if (((adev->family == AMDGPU_FAMILY_SI) || +- ((adev->flags & AMD_IS_APU) && (gc_ver != IP_VERSION(10, 3, 1)) && +- (gc_ver != IP_VERSION(9, 4, 3) && gc_ver != IP_VERSION(9, 4, 4)))) && +- (attr == &sensor_dev_attr_power1_cap_max.dev_attr.attr || +- attr == &sensor_dev_attr_power1_cap_min.dev_attr.attr || +- attr == &sensor_dev_attr_power1_cap.dev_attr.attr || +- attr == &sensor_dev_attr_power1_cap_default.dev_attr.attr)) +- return 0; ++ if (attr == &sensor_dev_attr_power1_cap_max.dev_attr.attr || ++ attr == &sensor_dev_attr_power1_cap_min.dev_attr.attr || ++ attr == &sensor_dev_attr_power1_cap.dev_attr.attr || ++ attr == &sensor_dev_attr_power1_cap_default.dev_attr.attr) { ++ if (adev->family == AMDGPU_FAMILY_SI || ++ ((adev->flags & AMD_IS_APU) && gc_ver != IP_VERSION(10, 3, 1) && ++ (gc_ver != IP_VERSION(9, 4, 3) && gc_ver != IP_VERSION(9, 4, 4))) || ++ (amdgpu_sriov_vf(adev) && gc_ver == IP_VERSION(11, 0, 3))) ++ return 0; ++ } + + /* not implemented yet for APUs having < GC 9.3.0 (Renoir) */ + if (((adev->family == AMDGPU_FAMILY_SI) || diff --git a/queue-6.12/drm-mediatek-fix-device-node-reference-count-leaks-in-mtk_drm_get_all_drm_priv.patch b/queue-6.12/drm-mediatek-fix-device-node-reference-count-leaks-in-mtk_drm_get_all_drm_priv.patch new file mode 100644 index 0000000000..75b03d042e --- /dev/null +++ b/queue-6.12/drm-mediatek-fix-device-node-reference-count-leaks-in-mtk_drm_get_all_drm_priv.patch @@ -0,0 +1,83 @@ +From 1f403699c40f0806a707a9a6eed3b8904224021a Mon Sep 17 00:00:00 2001 +From: Ma Ke +Date: Tue, 12 Aug 2025 15:19:32 +0800 +Subject: drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv + +From: Ma Ke + +commit 1f403699c40f0806a707a9a6eed3b8904224021a upstream. + +Using device_find_child() and of_find_device_by_node() to locate +devices could cause an imbalance in the device's reference count. +device_find_child() and of_find_device_by_node() both call +get_device() to increment the reference count of the found device +before returning the pointer. In mtk_drm_get_all_drm_priv(), these +references are never released through put_device(), resulting in +permanent reference count increments. Additionally, the +for_each_child_of_node() iterator fails to release node references in +all code paths. This leaks device node references when loop +termination occurs before reaching MAX_CRTC. These reference count +leaks may prevent device/node resources from being properly released +during driver unbind operations. + +As comment of device_find_child() says, 'NOTE: you will need to drop +the reference with put_device() after use'. + +Cc: stable@vger.kernel.org +Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") +Signed-off-by: Ma Ke +Reviewed-by: CK Hu +Link: https://patchwork.kernel.org/project/dri-devel/patch/20250812071932.471730-1-make24@iscas.ac.cn/ +Signed-off-by: Chun-Kuang Hu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 21 ++++++++++++++------- + 1 file changed, 14 insertions(+), 7 deletions(-) + +--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c ++++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c +@@ -381,19 +381,19 @@ static bool mtk_drm_get_all_drm_priv(str + + of_id = of_match_node(mtk_drm_of_ids, node); + if (!of_id) +- continue; ++ goto next_put_node; + + pdev = of_find_device_by_node(node); + if (!pdev) +- continue; ++ goto next_put_node; + + drm_dev = device_find_child(&pdev->dev, NULL, mtk_drm_match); + if (!drm_dev) +- continue; ++ goto next_put_device_pdev_dev; + + temp_drm_priv = dev_get_drvdata(drm_dev); + if (!temp_drm_priv) +- continue; ++ goto next_put_device_drm_dev; + + if (temp_drm_priv->data->main_len) + all_drm_priv[CRTC_MAIN] = temp_drm_priv; +@@ -405,10 +405,17 @@ static bool mtk_drm_get_all_drm_priv(str + if (temp_drm_priv->mtk_drm_bound) + cnt++; + +- if (cnt == MAX_CRTC) { +- of_node_put(node); ++next_put_device_drm_dev: ++ put_device(drm_dev); ++ ++next_put_device_pdev_dev: ++ put_device(&pdev->dev); ++ ++next_put_node: ++ of_node_put(node); ++ ++ if (cnt == MAX_CRTC) + break; +- } + } + + if (drm_priv->data->mmsys_dev_num == cnt) { diff --git a/queue-6.12/drm-nouveau-disp-always-accept-linear-modifier.patch b/queue-6.12/drm-nouveau-disp-always-accept-linear-modifier.patch new file mode 100644 index 0000000000..ad48e0a27d --- /dev/null +++ b/queue-6.12/drm-nouveau-disp-always-accept-linear-modifier.patch @@ -0,0 +1,38 @@ +From e2fe0c54fb7401e6ecd3c10348519ab9e23bd639 Mon Sep 17 00:00:00 2001 +From: James Jones +Date: Mon, 11 Aug 2025 15:00:16 -0700 +Subject: drm/nouveau/disp: Always accept linear modifier + +From: James Jones + +commit e2fe0c54fb7401e6ecd3c10348519ab9e23bd639 upstream. + +On some chipsets, which block-linear modifiers are +supported is format-specific. However, linear +modifiers are always be supported. The prior +modifier filtering logic was not accounting for +the linear case. + +Cc: stable@vger.kernel.org +Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp") +Signed-off-by: James Jones +Link: https://lore.kernel.org/r/20250811220017.1337-3-jajones@nvidia.com +Signed-off-by: Danilo Krummrich +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/dispnv50/wndw.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c ++++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c +@@ -663,6 +663,10 @@ static bool nv50_plane_format_mod_suppor + struct nouveau_drm *drm = nouveau_drm(plane->dev); + uint8_t i; + ++ /* All chipsets can display all formats in linear layout */ ++ if (modifier == DRM_FORMAT_MOD_LINEAR) ++ return true; ++ + if (drm->client.device.info.chipset < 0xc0) { + const struct drm_format_info *info = drm_format_info(format); + const uint8_t kind = (modifier >> 12) & 0xff; diff --git a/queue-6.12/drm-nouveau-fix-error-path-in-nvkm_gsp_fwsec_v2.patch b/queue-6.12/drm-nouveau-fix-error-path-in-nvkm_gsp_fwsec_v2.patch new file mode 100644 index 0000000000..f536c6a155 --- /dev/null +++ b/queue-6.12/drm-nouveau-fix-error-path-in-nvkm_gsp_fwsec_v2.patch @@ -0,0 +1,40 @@ +From 66e82b6e0a28d4970383e1ee5d60f431001128cd Mon Sep 17 00:00:00 2001 +From: Timur Tabi +Date: Tue, 12 Aug 2025 19:10:02 -0500 +Subject: drm/nouveau: fix error path in nvkm_gsp_fwsec_v2 + +From: Timur Tabi + +commit 66e82b6e0a28d4970383e1ee5d60f431001128cd upstream. + +Function nvkm_gsp_fwsec_v2() sets 'ret' if the kmemdup() call fails, but +it never uses or returns 'ret' after that point. We always need to release +the firmware regardless, so do that and then check for error. + +Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM") +Cc: stable@vger.kernel.org # v6.7+ +Signed-off-by: Timur Tabi +Link: https://lore.kernel.org/r/20250813001004.2986092-1-ttabi@nvidia.com +Signed-off-by: Danilo Krummrich +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c ++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/fwsec.c +@@ -209,11 +209,12 @@ nvkm_gsp_fwsec_v2(struct nvkm_gsp *gsp, + fw->boot_addr = bld->start_tag << 8; + fw->boot_size = bld->code_size; + fw->boot = kmemdup(bl->data + hdr->data_offset + bld->code_off, fw->boot_size, GFP_KERNEL); +- if (!fw->boot) +- ret = -ENOMEM; + + nvkm_firmware_put(bl); + ++ if (!fw->boot) ++ return -ENOMEM; ++ + /* Patch in interface data. */ + return nvkm_gsp_fwsec_patch(gsp, fw, desc->InterfaceOffset, init_cmd); + } diff --git a/queue-6.12/drm-xe-vm-clear-the-scratch_pt-pointer-on-error.patch b/queue-6.12/drm-xe-vm-clear-the-scratch_pt-pointer-on-error.patch new file mode 100644 index 0000000000..291c8a7870 --- /dev/null +++ b/queue-6.12/drm-xe-vm-clear-the-scratch_pt-pointer-on-error.patch @@ -0,0 +1,47 @@ +From 2b55ddf36229e0278c956215784ab1feeff510aa Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= +Date: Thu, 21 Aug 2025 16:30:45 +0200 +Subject: drm/xe/vm: Clear the scratch_pt pointer on error +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Hellström + +commit 2b55ddf36229e0278c956215784ab1feeff510aa upstream. + +Avoid triggering a dereference of an error pointer on cleanup in +xe_vm_free_scratch() by clearing any scratch_pt error pointer. + +Signed-off-by: Thomas Hellström +Fixes: 06951c2ee72d ("drm/xe: Use NULL PTEs as scratch PTEs") +Cc: Brian Welty +Cc: Rodrigo Vivi +Cc: Lucas De Marchi +Cc: # v6.8+ +Reviewed-by: Matthew Brost +Link: https://lore.kernel.org/r/20250821143045.106005-4-thomas.hellstrom@linux.intel.com +(cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/xe/xe_vm.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/xe/xe_vm.c ++++ b/drivers/gpu/drm/xe/xe_vm.c +@@ -1402,8 +1402,12 @@ static int xe_vm_create_scratch(struct x + + for (i = MAX_HUGEPTE_LEVEL; i < vm->pt_root[id]->level; i++) { + vm->scratch_pt[id][i] = xe_pt_create(vm, tile, i); +- if (IS_ERR(vm->scratch_pt[id][i])) +- return PTR_ERR(vm->scratch_pt[id][i]); ++ if (IS_ERR(vm->scratch_pt[id][i])) { ++ int err = PTR_ERR(vm->scratch_pt[id][i]); ++ ++ vm->scratch_pt[id][i] = NULL; ++ return err; ++ } + + xe_pt_populate_empty(tile, vm, vm->scratch_pt[id][i]); + } diff --git a/queue-6.12/fs-smb-fix-inconsistent-refcnt-update.patch b/queue-6.12/fs-smb-fix-inconsistent-refcnt-update.patch new file mode 100644 index 0000000000..d8556b4fb6 --- /dev/null +++ b/queue-6.12/fs-smb-fix-inconsistent-refcnt-update.patch @@ -0,0 +1,59 @@ +From ab529e6ca1f67bcf31f3ea80c72bffde2e9e053e Mon Sep 17 00:00:00 2001 +From: Shuhao Fu +Date: Thu, 28 Aug 2025 02:24:19 +0800 +Subject: fs/smb: Fix inconsistent refcnt update + +From: Shuhao Fu + +commit ab529e6ca1f67bcf31f3ea80c72bffde2e9e053e upstream. + +A possible inconsistent update of refcount was identified in `smb2_compound_op`. +Such inconsistent update could lead to possible resource leaks. + +Why it is a possible bug: +1. In the comment section of the function, it clearly states that the +reference to `cfile` should be dropped after calling this function. +2. Every control flow path would check and drop the reference to +`cfile`, except the patched one. +3. Existing callers would not handle refcount update of `cfile` if +-ENOMEM is returned. + +To fix the bug, an extra goto label "out" is added, to make sure that the +cleanup logic would always be respected. As the problem is caused by the +allocation failure of `vars`, the cleanup logic between label "finished" +and "out" can be safely ignored. According to the definition of function +`is_replayable_error`, the error code of "-ENOMEM" is not recoverable. +Therefore, the replay logic also gets ignored. + +Signed-off-by: Shuhao Fu +Acked-by: Paulo Alcantara (Red Hat) +Cc: stable@vger.kernel.org +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/smb2inode.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/fs/smb/client/smb2inode.c ++++ b/fs/smb/client/smb2inode.c +@@ -206,8 +206,10 @@ replay_again: + server = cifs_pick_channel(ses); + + vars = kzalloc(sizeof(*vars), GFP_ATOMIC); +- if (vars == NULL) +- return -ENOMEM; ++ if (vars == NULL) { ++ rc = -ENOMEM; ++ goto out; ++ } + rqst = &vars->rqst[0]; + rsp_iov = &vars->rsp_iov[0]; + +@@ -832,6 +834,7 @@ finished: + smb2_should_replay(tcon, &retries, &cur_sleep)) + goto replay_again; + ++out: + if (cfile) + cifsFileInfo_put(cfile); + diff --git a/queue-6.12/hid-asus-fix-uaf-via-hid_claimed_input-validation.patch b/queue-6.12/hid-asus-fix-uaf-via-hid_claimed_input-validation.patch new file mode 100644 index 0000000000..7451cb7640 --- /dev/null +++ b/queue-6.12/hid-asus-fix-uaf-via-hid_claimed_input-validation.patch @@ -0,0 +1,135 @@ +From d3af6ca9a8c34bbd8cff32b469b84c9021c9e7e4 Mon Sep 17 00:00:00 2001 +From: Qasim Ijaz +Date: Sun, 10 Aug 2025 19:10:41 +0100 +Subject: HID: asus: fix UAF via HID_CLAIMED_INPUT validation + +From: Qasim Ijaz + +commit d3af6ca9a8c34bbd8cff32b469b84c9021c9e7e4 upstream. + +After hid_hw_start() is called hidinput_connect() will eventually be +called to set up the device with the input layer since the +HID_CONNECT_DEFAULT connect mask is used. During hidinput_connect() +all input and output reports are processed and corresponding hid_inputs +are allocated and configured via hidinput_configure_usages(). This +process involves slot tagging report fields and configuring usages +by setting relevant bits in the capability bitmaps. However it is possible +that the capability bitmaps are not set at all leading to the subsequent +hidinput_has_been_populated() check to fail leading to the freeing of the +hid_input and the underlying input device. + +This becomes problematic because a malicious HID device like a +ASUS ROG N-Key keyboard can trigger the above scenario via a +specially crafted descriptor which then leads to a user-after-free +when the name of the freed input device is written to later on after +hid_hw_start(). Below, report 93 intentionally utilises the +HID_UP_UNDEFINED Usage Page which is skipped during usage +configuration, leading to the frees. + +0x05, 0x0D, // Usage Page (Digitizer) +0x09, 0x05, // Usage (Touch Pad) +0xA1, 0x01, // Collection (Application) +0x85, 0x0D, // Report ID (13) +0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00) +0x09, 0xC5, // Usage (0xC5) +0x15, 0x00, // Logical Minimum (0) +0x26, 0xFF, 0x00, // Logical Maximum (255) +0x75, 0x08, // Report Size (8) +0x95, 0x04, // Report Count (4) +0xB1, 0x02, // Feature (Data,Var,Abs) +0x85, 0x5D, // Report ID (93) +0x06, 0x00, 0x00, // Usage Page (Undefined) +0x09, 0x01, // Usage (0x01) +0x15, 0x00, // Logical Minimum (0) +0x26, 0xFF, 0x00, // Logical Maximum (255) +0x75, 0x08, // Report Size (8) +0x95, 0x1B, // Report Count (27) +0x81, 0x02, // Input (Data,Var,Abs) +0xC0, // End Collection + +Below is the KASAN splat after triggering the UAF: + +[ 21.672709] ================================================================== +[ 21.673700] BUG: KASAN: slab-use-after-free in asus_probe+0xeeb/0xf80 +[ 21.673700] Write of size 8 at addr ffff88810a0ac000 by task kworker/1:2/54 +[ 21.673700] +[ 21.673700] CPU: 1 UID: 0 PID: 54 Comm: kworker/1:2 Not tainted 6.16.0-rc4-g9773391cf4dd-dirty #36 PREEMPT(voluntary) +[ 21.673700] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 +[ 21.673700] Call Trace: +[ 21.673700] +[ 21.673700] dump_stack_lvl+0x5f/0x80 +[ 21.673700] print_report+0xd1/0x660 +[ 21.673700] kasan_report+0xe5/0x120 +[ 21.673700] __asan_report_store8_noabort+0x1b/0x30 +[ 21.673700] asus_probe+0xeeb/0xf80 +[ 21.673700] hid_device_probe+0x2ee/0x700 +[ 21.673700] really_probe+0x1c6/0x6b0 +[ 21.673700] __driver_probe_device+0x24f/0x310 +[ 21.673700] driver_probe_device+0x4e/0x220 +[...] +[ 21.673700] +[ 21.673700] Allocated by task 54: +[ 21.673700] kasan_save_stack+0x3d/0x60 +[ 21.673700] kasan_save_track+0x18/0x40 +[ 21.673700] kasan_save_alloc_info+0x3b/0x50 +[ 21.673700] __kasan_kmalloc+0x9c/0xa0 +[ 21.673700] __kmalloc_cache_noprof+0x139/0x340 +[ 21.673700] input_allocate_device+0x44/0x370 +[ 21.673700] hidinput_connect+0xcb6/0x2630 +[ 21.673700] hid_connect+0xf74/0x1d60 +[ 21.673700] hid_hw_start+0x8c/0x110 +[ 21.673700] asus_probe+0x5a3/0xf80 +[ 21.673700] hid_device_probe+0x2ee/0x700 +[ 21.673700] really_probe+0x1c6/0x6b0 +[ 21.673700] __driver_probe_device+0x24f/0x310 +[ 21.673700] driver_probe_device+0x4e/0x220 +[...] +[ 21.673700] +[ 21.673700] Freed by task 54: +[ 21.673700] kasan_save_stack+0x3d/0x60 +[ 21.673700] kasan_save_track+0x18/0x40 +[ 21.673700] kasan_save_free_info+0x3f/0x60 +[ 21.673700] __kasan_slab_free+0x3c/0x50 +[ 21.673700] kfree+0xcf/0x350 +[ 21.673700] input_dev_release+0xab/0xd0 +[ 21.673700] device_release+0x9f/0x220 +[ 21.673700] kobject_put+0x12b/0x220 +[ 21.673700] put_device+0x12/0x20 +[ 21.673700] input_free_device+0x4c/0xb0 +[ 21.673700] hidinput_connect+0x1862/0x2630 +[ 21.673700] hid_connect+0xf74/0x1d60 +[ 21.673700] hid_hw_start+0x8c/0x110 +[ 21.673700] asus_probe+0x5a3/0xf80 +[ 21.673700] hid_device_probe+0x2ee/0x700 +[ 21.673700] really_probe+0x1c6/0x6b0 +[ 21.673700] __driver_probe_device+0x24f/0x310 +[ 21.673700] driver_probe_device+0x4e/0x220 +[...] + +Fixes: 9ce12d8be12c ("HID: asus: Add i2c touchpad support") +Cc: stable@vger.kernel.org +Signed-off-by: Qasim Ijaz +Link: https://patch.msgid.link/20250810181041.44874-1-qasdev00@gmail.com +Signed-off-by: Benjamin Tissoires +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-asus.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/hid/hid-asus.c ++++ b/drivers/hid/hid-asus.c +@@ -1210,7 +1210,13 @@ static int asus_probe(struct hid_device + return ret; + } + +- if (!drvdata->input) { ++ /* ++ * Check that input registration succeeded. Checking that ++ * HID_CLAIMED_INPUT is set prevents a UAF when all input devices ++ * were freed during registration due to no usages being mapped, ++ * leaving drvdata->input pointing to freed memory. ++ */ ++ if (!drvdata->input || !(hdev->claimed & HID_CLAIMED_INPUT)) { + hid_err(hdev, "Asus input not registered\n"); + ret = -ENOMEM; + goto err_stop_hw; diff --git a/queue-6.12/hid-hid-ntrig-fix-unable-to-handle-page-fault-in-ntrig_report_version.patch b/queue-6.12/hid-hid-ntrig-fix-unable-to-handle-page-fault-in-ntrig_report_version.patch new file mode 100644 index 0000000000..26cc3dd597 --- /dev/null +++ b/queue-6.12/hid-hid-ntrig-fix-unable-to-handle-page-fault-in-ntrig_report_version.patch @@ -0,0 +1,39 @@ +From 185c926283da67a72df20a63a5046b3b4631b7d9 Mon Sep 17 00:00:00 2001 +From: Minjong Kim +Date: Wed, 13 Aug 2025 19:30:22 +0900 +Subject: HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version() + +From: Minjong Kim + +commit 185c926283da67a72df20a63a5046b3b4631b7d9 upstream. + +in ntrig_report_version(), hdev parameter passed from hid_probe(). +sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null +if hdev->dev.parent->parent is null, usb_dev has +invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned +when usb_rcvctrlpipe() use usb_dev,it trigger +page fault error for address(0xffffffffffffff58) + +add null check logic to ntrig_report_version() +before calling hid_to_usb_dev() + +Signed-off-by: Minjong Kim +Link: https://patch.msgid.link/20250813-hid-ntrig-page-fault-fix-v2-1-f98581f35106@samsung.com +Signed-off-by: Benjamin Tissoires +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-ntrig.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/hid/hid-ntrig.c ++++ b/drivers/hid/hid-ntrig.c +@@ -144,6 +144,9 @@ static void ntrig_report_version(struct + struct usb_device *usb_dev = hid_to_usb_dev(hdev); + unsigned char *data = kmalloc(8, GFP_KERNEL); + ++ if (!hid_is_usb(hdev)) ++ return; ++ + if (!data) + goto err_free; + diff --git a/queue-6.12/hid-logitech-add-ids-for-g-pro-2-lightspeed.patch b/queue-6.12/hid-logitech-add-ids-for-g-pro-2-lightspeed.patch new file mode 100644 index 0000000000..a52253858d --- /dev/null +++ b/queue-6.12/hid-logitech-add-ids-for-g-pro-2-lightspeed.patch @@ -0,0 +1,65 @@ +From ab1bb82f3db20e23eace06db52031b1164a110c2 Mon Sep 17 00:00:00 2001 +From: Matt Coffin +Date: Wed, 20 Aug 2025 01:49:51 -0600 +Subject: HID: logitech: Add ids for G PRO 2 LIGHTSPEED + +From: Matt Coffin + +commit ab1bb82f3db20e23eace06db52031b1164a110c2 upstream. + +Adds support for the G PRO 2 LIGHTSPEED Wireless via it's nano receiver +or directly. This nano receiver appears to work identically to the 1_1 +receiver for the case I've verified, which is the battery status through +lg-hidpp. + +The same appears to be the case wired, sharing much with the Pro X +Superlight 2; differences seemed to lie in userland configuration rather +than in interfaces used by hid_logitech_hidpp on the kernel side. + +I verified the sysfs interface for battery charge/discharge status, and +capacity read to be working on my 910-007290 device (white). + +Signed-off-by: Matt Coffin +Reviewed-by: Bastien Nocera +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-ids.h | 1 + + drivers/hid/hid-logitech-dj.c | 4 ++++ + drivers/hid/hid-logitech-hidpp.c | 2 ++ + 3 files changed, 7 insertions(+) + +--- a/drivers/hid/hid-ids.h ++++ b/drivers/hid/hid-ids.h +@@ -900,6 +900,7 @@ + #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_2 0xc534 + #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1 0xc539 + #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1 0xc53f ++#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_2 0xc543 + #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY 0xc53a + #define USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER 0xc548 + #define USB_DEVICE_ID_SPACETRAVELLER 0xc623 +--- a/drivers/hid/hid-logitech-dj.c ++++ b/drivers/hid/hid-logitech-dj.c +@@ -1983,6 +1983,10 @@ static const struct hid_device_id logi_d + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, + USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1), + .driver_data = recvr_type_gaming_hidpp}, ++ { /* Logitech lightspeed receiver (0xc543) */ ++ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, ++ USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_2), ++ .driver_data = recvr_type_gaming_hidpp}, + + { /* Logitech 27 MHz HID++ 1.0 receiver (0xc513) */ + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER), +--- a/drivers/hid/hid-logitech-hidpp.c ++++ b/drivers/hid/hid-logitech-hidpp.c +@@ -4624,6 +4624,8 @@ static const struct hid_device_id hidpp_ + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC094) }, + { /* Logitech G Pro X Superlight 2 Gaming Mouse over USB */ + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC09b) }, ++ { /* Logitech G PRO 2 LIGHTSPEED Wireless Mouse over USB */ ++ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xc09a) }, + + { /* G935 Gaming Headset */ + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0x0a87), diff --git a/queue-6.12/hid-multitouch-fix-slab-out-of-bounds-access-in-mt_report_fixup.patch b/queue-6.12/hid-multitouch-fix-slab-out-of-bounds-access-in-mt_report_fixup.patch new file mode 100644 index 0000000000..e69e275610 --- /dev/null +++ b/queue-6.12/hid-multitouch-fix-slab-out-of-bounds-access-in-mt_report_fixup.patch @@ -0,0 +1,75 @@ +From 0379eb8691b9c4477da0277ae0832036ca4410b4 Mon Sep 17 00:00:00 2001 +From: Qasim Ijaz +Date: Sun, 10 Aug 2025 19:09:24 +0100 +Subject: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() + +From: Qasim Ijaz + +commit 0379eb8691b9c4477da0277ae0832036ca4410b4 upstream. + +A malicious HID device can trigger a slab out-of-bounds during +mt_report_fixup() by passing in report descriptor smaller than +607 bytes. mt_report_fixup() attempts to patch byte offset 607 +of the descriptor with 0x25 by first checking if byte offset +607 is 0x15 however it lacks bounds checks to verify if the +descriptor is big enough before conducting this check. Fix +this bug by ensuring the descriptor size is at least 608 +bytes before accessing it. + +Below is the KASAN splat after the out of bounds access happens: + +[ 13.671954] ================================================================== +[ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 +[ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 +[ 13.673297] +[ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 +[ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 +[ 13.673297] Call Trace: +[ 13.673297] +[ 13.673297] dump_stack_lvl+0x5f/0x80 +[ 13.673297] print_report+0xd1/0x660 +[ 13.673297] kasan_report+0xe5/0x120 +[ 13.673297] __asan_report_load1_noabort+0x18/0x20 +[ 13.673297] mt_report_fixup+0x103/0x110 +[ 13.673297] hid_open_report+0x1ef/0x810 +[ 13.673297] mt_probe+0x422/0x960 +[ 13.673297] hid_device_probe+0x2e2/0x6f0 +[ 13.673297] really_probe+0x1c6/0x6b0 +[ 13.673297] __driver_probe_device+0x24f/0x310 +[ 13.673297] driver_probe_device+0x4e/0x220 +[ 13.673297] __device_attach_driver+0x169/0x320 +[ 13.673297] bus_for_each_drv+0x11d/0x1b0 +[ 13.673297] __device_attach+0x1b8/0x3e0 +[ 13.673297] device_initial_probe+0x12/0x20 +[ 13.673297] bus_probe_device+0x13d/0x180 +[ 13.673297] device_add+0xe3a/0x1670 +[ 13.673297] hid_add_device+0x31d/0xa40 +[...] + +Fixes: c8000deb6836 ("HID: multitouch: Add support for GT7868Q") +Cc: stable@vger.kernel.org +Signed-off-by: Qasim Ijaz +Reviewed-by: Jiri Slaby +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-multitouch.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/hid/hid-multitouch.c ++++ b/drivers/hid/hid-multitouch.c +@@ -1453,6 +1453,14 @@ static const __u8 *mt_report_fixup(struc + if (hdev->vendor == I2C_VENDOR_ID_GOODIX && + (hdev->product == I2C_DEVICE_ID_GOODIX_01E8 || + hdev->product == I2C_DEVICE_ID_GOODIX_01E9)) { ++ if (*size < 608) { ++ dev_info( ++ &hdev->dev, ++ "GT7868Q fixup: report descriptor is only %u bytes, skipping\n", ++ *size); ++ return rdesc; ++ } ++ + if (rdesc[607] == 0x15) { + rdesc[607] = 0x25; + dev_info( diff --git a/queue-6.12/hid-quirks-add-support-for-legion-go-dual-dinput-modes.patch b/queue-6.12/hid-quirks-add-support-for-legion-go-dual-dinput-modes.patch new file mode 100644 index 0000000000..719d98cd5e --- /dev/null +++ b/queue-6.12/hid-quirks-add-support-for-legion-go-dual-dinput-modes.patch @@ -0,0 +1,51 @@ +From 1f3214aae9f49faf495f3836216afbc6c5400b2e Mon Sep 17 00:00:00 2001 +From: Antheas Kapenekakis +Date: Sun, 3 Aug 2025 18:02:53 +0200 +Subject: HID: quirks: add support for Legion Go dual dinput modes + +From: Antheas Kapenekakis + +commit 1f3214aae9f49faf495f3836216afbc6c5400b2e upstream. + +The Legion Go features detachable controllers which support a dual +dinput mode. In this mode, the controllers appear under a single HID +device with two applications. + +Currently, both controllers appear under the same event device, causing +their controls to be mixed up. This patch separates the two so that +they can be used independently. + +In addition, the latest firmware update for the Legion Go swaps the IDs +to the ones used by the Legion Go 2, so add those IDs as well. + +[jkosina@suse.com: improved shortlog] +Signed-off-by: Antheas Kapenekakis +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/hid-ids.h | 2 ++ + drivers/hid/hid-quirks.c | 2 ++ + 2 files changed, 4 insertions(+) + +--- a/drivers/hid/hid-ids.h ++++ b/drivers/hid/hid-ids.h +@@ -825,6 +825,8 @@ + #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019 0x6019 + #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_602E 0x602e + #define USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6093 0x6093 ++#define USB_DEVICE_ID_LENOVO_LEGION_GO_DUAL_DINPUT 0x6184 ++#define USB_DEVICE_ID_LENOVO_LEGION_GO2_DUAL_DINPUT 0x61ed + + #define USB_VENDOR_ID_LETSKETCH 0x6161 + #define USB_DEVICE_ID_WP9620N 0x4d15 +--- a/drivers/hid/hid-quirks.c ++++ b/drivers/hid/hid-quirks.c +@@ -124,6 +124,8 @@ static const struct hid_device_id hid_qu + { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X_V2), HID_QUIRK_MULTI_INPUT }, + { HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_PENSKETCH_T609A), HID_QUIRK_MULTI_INPUT }, + { HID_USB_DEVICE(USB_VENDOR_ID_LABTEC, USB_DEVICE_ID_LABTEC_ODDOR_HANDBRAKE), HID_QUIRK_ALWAYS_POLL }, ++ { HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_LEGION_GO_DUAL_DINPUT), HID_QUIRK_MULTI_INPUT }, ++ { HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_LEGION_GO2_DUAL_DINPUT), HID_QUIRK_MULTI_INPUT }, + { HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_OPTICAL_USB_MOUSE_600E), HID_QUIRK_ALWAYS_POLL }, + { HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D), HID_QUIRK_ALWAYS_POLL }, + { HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019), HID_QUIRK_ALWAYS_POLL }, diff --git a/queue-6.12/hid-wacom-add-a-new-art-pen-2.patch b/queue-6.12/hid-wacom-add-a-new-art-pen-2.patch new file mode 100644 index 0000000000..ba99e63bd9 --- /dev/null +++ b/queue-6.12/hid-wacom-add-a-new-art-pen-2.patch @@ -0,0 +1,26 @@ +From 9fc51941d9e7793da969b2c66e6f8213c5b1237f Mon Sep 17 00:00:00 2001 +From: Ping Cheng +Date: Sun, 10 Aug 2025 22:40:30 -0700 +Subject: HID: wacom: Add a new Art Pen 2 + +From: Ping Cheng + +commit 9fc51941d9e7793da969b2c66e6f8213c5b1237f upstream. + +Signed-off-by: Ping Cheng +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/wacom_wac.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/hid/wacom_wac.c ++++ b/drivers/hid/wacom_wac.c +@@ -684,6 +684,7 @@ static bool wacom_is_art_pen(int tool_id + case 0x885: /* Intuos3 Marker Pen */ + case 0x804: /* Intuos4/5 13HD/24HD Marker Pen */ + case 0x10804: /* Intuos4/5 13HD/24HD Art Pen */ ++ case 0x204: /* Art Pen 2 */ + is_art_pen = true; + break; + } diff --git a/queue-6.12/kvm-x86-use-array_index_nospec-with-indices-that-come-from-guest.patch b/queue-6.12/kvm-x86-use-array_index_nospec-with-indices-that-come-from-guest.patch new file mode 100644 index 0000000000..d7d85ea765 --- /dev/null +++ b/queue-6.12/kvm-x86-use-array_index_nospec-with-indices-that-come-from-guest.patch @@ -0,0 +1,56 @@ +From c87bd4dd43a624109c3cc42d843138378a7f4548 Mon Sep 17 00:00:00 2001 +From: Thijs Raymakers +Date: Mon, 4 Aug 2025 08:44:05 +0200 +Subject: KVM: x86: use array_index_nospec with indices that come from guest + +From: Thijs Raymakers + +commit c87bd4dd43a624109c3cc42d843138378a7f4548 upstream. + +min and dest_id are guest-controlled indices. Using array_index_nospec() +after the bounds checks clamps these values to mitigate speculative execution +side-channels. + +Signed-off-by: Thijs Raymakers +Cc: stable@vger.kernel.org +Cc: Sean Christopherson +Cc: Paolo Bonzini +Cc: Greg Kroah-Hartman +Fixes: 715062970f37 ("KVM: X86: Implement PV sched yield hypercall") +Fixes: bdf7ffc89922 ("KVM: LAPIC: Fix pv ipis out-of-bounds access") +Fixes: 4180bf1b655a ("KVM: X86: Implement "send IPI" hypercall") +Link: https://lore.kernel.org/r/20250804064405.4802-1-thijs@raymakers.nl +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/lapic.c | 2 ++ + arch/x86/kvm/x86.c | 7 +++++-- + 2 files changed, 7 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -860,6 +860,8 @@ static int __pv_send_ipi(unsigned long * + if (min > map->max_apic_id) + return 0; + ++ min = array_index_nospec(min, map->max_apic_id + 1); ++ + for_each_set_bit(i, ipi_bitmap, + min((u32)BITS_PER_LONG, (map->max_apic_id - min + 1))) { + if (map->phys_map[min + i]) { +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -9969,8 +9969,11 @@ static void kvm_sched_yield(struct kvm_v + rcu_read_lock(); + map = rcu_dereference(vcpu->kvm->arch.apic_map); + +- if (likely(map) && dest_id <= map->max_apic_id && map->phys_map[dest_id]) +- target = map->phys_map[dest_id]->vcpu; ++ if (likely(map) && dest_id <= map->max_apic_id) { ++ dest_id = array_index_nospec(dest_id, map->max_apic_id + 1); ++ if (map->phys_map[dest_id]) ++ target = map->phys_map[dest_id]->vcpu; ++ } + + rcu_read_unlock(); + diff --git a/queue-6.12/net-usb-qmi_wwan-add-telit-cinterion-le910c4-wwx-new-compositions.patch b/queue-6.12/net-usb-qmi_wwan-add-telit-cinterion-le910c4-wwx-new-compositions.patch new file mode 100644 index 0000000000..9ede4b972d --- /dev/null +++ b/queue-6.12/net-usb-qmi_wwan-add-telit-cinterion-le910c4-wwx-new-compositions.patch @@ -0,0 +1,104 @@ +From e81a7f65288c7e2cfb7e7890f648e099fd885ab3 Mon Sep 17 00:00:00 2001 +From: Fabio Porcedda +Date: Fri, 22 Aug 2025 11:13:24 +0200 +Subject: net: usb: qmi_wwan: add Telit Cinterion LE910C4-WWX new compositions + +From: Fabio Porcedda + +commit e81a7f65288c7e2cfb7e7890f648e099fd885ab3 upstream. + +Add the following Telit Cinterion LE910C4-WWX new compositions: + +0x1034: tty (AT) + tty (AT) + rmnet +T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 8 Spd=480 MxCh= 0 +D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 +P: Vendor=1bc7 ProdID=1034 Rev=00.00 +S: Manufacturer=Telit +S: Product=LE910C4-WWX +S: SerialNumber=93f617e7 +C: #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA +I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option +E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms +E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option +E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms +E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan +E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms +E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms + +0x1037: tty (diag) + tty (Telit custom) + tty (AT) + tty (AT) + rmnet +T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 15 Spd=480 MxCh= 0 +D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 +P: Vendor=1bc7 ProdID=1037 Rev=00.00 +S: Manufacturer=Telit +S: Product=LE910C4-WWX +S: SerialNumber=93f617e7 +C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA +I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option +E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option +E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option +E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=2ms +E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option +E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=2ms +E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan +E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=2ms +E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms + +0x1038: tty (Telit custom) + tty (AT) + tty (AT) + rmnet +T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 9 Spd=480 MxCh= 0 +D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 +P: Vendor=1bc7 ProdID=1038 Rev=00.00 +S: Manufacturer=Telit +S: Product=LE910C4-WWX +S: SerialNumber=93f617e7 +C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA +I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option +E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option +E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=2ms +E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option +E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=84(I) Atr=03(Int.) MxPS= 64 Ivl=2ms +E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan +E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=86(I) Atr=03(Int.) MxPS= 64 Ivl=2ms +E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms + +Cc: stable@vger.kernel.org +Signed-off-by: Fabio Porcedda +Link: https://patch.msgid.link/20250822091324.39558-1-Fabio.Porcedda@telit.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/qmi_wwan.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/net/usb/qmi_wwan.c ++++ b/drivers/net/usb/qmi_wwan.c +@@ -1355,6 +1355,9 @@ static const struct usb_device_id produc + {QMI_FIXED_INTF(0x2357, 0x0201, 4)}, /* TP-LINK HSUPA Modem MA180 */ + {QMI_FIXED_INTF(0x2357, 0x9000, 4)}, /* TP-LINK MA260 */ + {QMI_QUIRK_SET_DTR(0x1bc7, 0x1031, 3)}, /* Telit LE910C1-EUX */ ++ {QMI_QUIRK_SET_DTR(0x1bc7, 0x1034, 2)}, /* Telit LE910C4-WWX */ ++ {QMI_QUIRK_SET_DTR(0x1bc7, 0x1037, 4)}, /* Telit LE910C4-WWX */ ++ {QMI_QUIRK_SET_DTR(0x1bc7, 0x1038, 3)}, /* Telit LE910C4-WWX */ + {QMI_QUIRK_SET_DTR(0x1bc7, 0x103a, 0)}, /* Telit LE910C4-WWX */ + {QMI_QUIRK_SET_DTR(0x1bc7, 0x1040, 2)}, /* Telit LE922A */ + {QMI_QUIRK_SET_DTR(0x1bc7, 0x1050, 2)}, /* Telit FN980 */ diff --git a/queue-6.12/revert-drm-amdgpu-fix-incorrect-vm-flags-to-map-bo.patch b/queue-6.12/revert-drm-amdgpu-fix-incorrect-vm-flags-to-map-bo.patch new file mode 100644 index 0000000000..8b48852030 --- /dev/null +++ b/queue-6.12/revert-drm-amdgpu-fix-incorrect-vm-flags-to-map-bo.patch @@ -0,0 +1,34 @@ +From ac4ed2da4c1305a1a002415058aa7deaf49ffe3e Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 25 Aug 2025 13:40:22 -0400 +Subject: Revert "drm/amdgpu: fix incorrect vm flags to map bo" + +From: Alex Deucher + +commit ac4ed2da4c1305a1a002415058aa7deaf49ffe3e upstream. + +This reverts commit b08425fa77ad2f305fe57a33dceb456be03b653f. + +Revert this to align with 6.17 because the fixes tag +was wrong on this commit. + +Signed-off-by: Alex Deucher +(cherry picked from commit be33e8a239aac204d7e9e673c4220ef244eb1ba3) +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c +@@ -88,8 +88,8 @@ int amdgpu_map_static_csa(struct amdgpu_ + } + + r = amdgpu_vm_bo_map(adev, *bo_va, csa_addr, 0, size, +- AMDGPU_VM_PAGE_READABLE | AMDGPU_VM_PAGE_WRITEABLE | +- AMDGPU_VM_PAGE_EXECUTABLE); ++ AMDGPU_PTE_READABLE | AMDGPU_PTE_WRITEABLE | ++ AMDGPU_PTE_EXECUTABLE); + + if (r) { + DRM_ERROR("failed to do bo_map on static CSA, err=%d\n", r); diff --git a/queue-6.12/risc-v-kvm-fix-stack-overrun-when-loading-vlenb.patch b/queue-6.12/risc-v-kvm-fix-stack-overrun-when-loading-vlenb.patch new file mode 100644 index 0000000000..f921f36f88 --- /dev/null +++ b/queue-6.12/risc-v-kvm-fix-stack-overrun-when-loading-vlenb.patch @@ -0,0 +1,38 @@ +From 799766208f09f95677a9ab111b93872d414fbad7 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= +Date: Tue, 5 Aug 2025 12:44:21 +0200 +Subject: RISC-V: KVM: fix stack overrun when loading vlenb +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Radim Krčmář + +commit 799766208f09f95677a9ab111b93872d414fbad7 upstream. + +The userspace load can put up to 2048 bits into an xlen bit stack +buffer. We want only xlen bits, so check the size beforehand. + +Fixes: 2fa290372dfe ("RISC-V: KVM: add 'vlenb' Vector CSR") +Cc: stable@vger.kernel.org +Signed-off-by: Radim Krčmář +Reviewed-by: Nutty Liu +Reviewed-by: Daniel Henrique Barboza +Link: https://lore.kernel.org/r/20250805104418.196023-4-rkrcmar@ventanamicro.com +Signed-off-by: Anup Patel +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/kvm/vcpu_vector.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/riscv/kvm/vcpu_vector.c ++++ b/arch/riscv/kvm/vcpu_vector.c +@@ -181,6 +181,8 @@ int kvm_riscv_vcpu_set_reg_vector(struct + struct kvm_cpu_context *cntx = &vcpu->arch.guest_context; + unsigned long reg_val; + ++ if (reg_size != sizeof(reg_val)) ++ return -EINVAL; + if (copy_from_user(®_val, uaddr, reg_size)) + return -EFAULT; + if (reg_val != cntx->vector.vlenb) diff --git a/queue-6.12/series b/queue-6.12/series index 7f624fbcaa..d64bfa748e 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -64,3 +64,25 @@ l2tp-do-not-use-sock_hold-in-pppol2tp_session_get_so.patch fbnic-move-phylink-resume-out-of-service_task-and-in.patch efivarfs-fix-slab-out-of-bounds-in-efivarfs_d_compar.patch net-macb-disable-clocks-once.patch +kvm-x86-use-array_index_nospec-with-indices-that-come-from-guest.patch +risc-v-kvm-fix-stack-overrun-when-loading-vlenb.patch +x86-microcode-amd-handle-the-case-of-no-bios-microcode.patch +x86-cpu-topology-use-initial-apic-id-from-xtopology-leaf-on-amd-hygon.patch +hid-asus-fix-uaf-via-hid_claimed_input-validation.patch +hid-multitouch-fix-slab-out-of-bounds-access-in-mt_report_fixup.patch +hid-quirks-add-support-for-legion-go-dual-dinput-modes.patch +hid-logitech-add-ids-for-g-pro-2-lightspeed.patch +hid-wacom-add-a-new-art-pen-2.patch +hid-hid-ntrig-fix-unable-to-handle-page-fault-in-ntrig_report_version.patch +revert-drm-amdgpu-fix-incorrect-vm-flags-to-map-bo.patch +blk-zoned-fix-a-lockdep-complaint-about-recursive-locking.patch +dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch +fs-smb-fix-inconsistent-refcnt-update.patch +net-usb-qmi_wwan-add-telit-cinterion-le910c4-wwx-new-compositions.patch +smb3-client-fix-return-code-mapping-of-remap_file_range.patch +xfs-do-not-propagate-enodata-disk-errors-into-xattr-code.patch +drm-xe-vm-clear-the-scratch_pt-pointer-on-error.patch +drm-nouveau-disp-always-accept-linear-modifier.patch +drm-nouveau-fix-error-path-in-nvkm_gsp_fwsec_v2.patch +drm-mediatek-fix-device-node-reference-count-leaks-in-mtk_drm_get_all_drm_priv.patch +drm-amd-amdgpu-disable-hwmon-power1_cap-for-gfx-11.0.3-on-vf-mode.patch diff --git a/queue-6.12/smb3-client-fix-return-code-mapping-of-remap_file_range.patch b/queue-6.12/smb3-client-fix-return-code-mapping-of-remap_file_range.patch new file mode 100644 index 0000000000..e69cf7cc7a --- /dev/null +++ b/queue-6.12/smb3-client-fix-return-code-mapping-of-remap_file_range.patch @@ -0,0 +1,47 @@ +From 0e08fa789d39aa01923e3ba144bd808291895c3c Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Sat, 23 Aug 2025 21:15:59 -0500 +Subject: smb3 client: fix return code mapping of remap_file_range + +From: Steve French + +commit 0e08fa789d39aa01923e3ba144bd808291895c3c upstream. + +We were returning -EOPNOTSUPP for various remap_file_range cases +but for some of these the copy_file_range_syscall() requires -EINVAL +to be returned (e.g. where source and target file ranges overlap when +source and target are the same file). This fixes xfstest generic/157 +which was expecting EINVAL for that (and also e.g. for when the src +offset is beyond end of file). + +Cc: stable@vger.kernel.org +Acked-by: Paulo Alcantara (Red Hat) +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/cifsfs.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/fs/smb/client/cifsfs.c ++++ b/fs/smb/client/cifsfs.c +@@ -1348,6 +1348,20 @@ static loff_t cifs_remap_file_range(stru + truncate_setsize(target_inode, new_size); + fscache_resize_cookie(cifs_inode_cookie(target_inode), + new_size); ++ } else if (rc == -EOPNOTSUPP) { ++ /* ++ * copy_file_range syscall man page indicates EINVAL ++ * is returned e.g when "fd_in and fd_out refer to the ++ * same file and the source and target ranges overlap." ++ * Test generic/157 was what showed these cases where ++ * we need to remap EOPNOTSUPP to EINVAL ++ */ ++ if (off >= src_inode->i_size) { ++ rc = -EINVAL; ++ } else if (src_inode == target_inode) { ++ if (off + len > destoff) ++ rc = -EINVAL; ++ } + } + if (rc == 0 && new_size > target_cifsi->netfs.zero_point) + target_cifsi->netfs.zero_point = new_size; diff --git a/queue-6.12/x86-cpu-topology-use-initial-apic-id-from-xtopology-leaf-on-amd-hygon.patch b/queue-6.12/x86-cpu-topology-use-initial-apic-id-from-xtopology-leaf-on-amd-hygon.patch new file mode 100644 index 0000000000..98af84e588 --- /dev/null +++ b/queue-6.12/x86-cpu-topology-use-initial-apic-id-from-xtopology-leaf-on-amd-hygon.patch @@ -0,0 +1,113 @@ +From c2415c407a2cde01290d52ce2a1f81b0616379a3 Mon Sep 17 00:00:00 2001 +From: K Prateek Nayak +Date: Mon, 25 Aug 2025 07:57:29 +0000 +Subject: x86/cpu/topology: Use initial APIC ID from XTOPOLOGY leaf on AMD/HYGON + +From: K Prateek Nayak + +commit c2415c407a2cde01290d52ce2a1f81b0616379a3 upstream. + +Prior to the topology parsing rewrite and the switchover to the new parsing +logic for AMD processors in + + c749ce393b8f ("x86/cpu: Use common topology code for AMD"), + +the initial_apicid on these platforms was: + +- First initialized to the LocalApicId from CPUID leaf 0x1 EBX[31:24]. + +- Then overwritten by the ExtendedLocalApicId in CPUID leaf 0xb + EDX[31:0] on processors that supported topoext. + +With the new parsing flow introduced in + + f7fb3b2dd92c ("x86/cpu: Provide an AMD/HYGON specific topology parser"), + +parse_8000_001e() now unconditionally overwrites the initial_apicid already +parsed during cpu_parse_topology_ext(). + +Although this has not been a problem on baremetal platforms, on virtualized AMD +guests that feature more than 255 cores, QEMU zeros out the CPUID leaf +0x8000001e on CPUs with CoreID > 255 to prevent collision of these IDs in +EBX[7:0] which can only represent a maximum of 255 cores [1]. + +This results in the following FW_BUG being logged when booting a guest +with more than 255 cores: + + [Firmware Bug]: CPU 512: APIC ID mismatch. CPUID: 0x0000 APIC: 0x0200 + +AMD64 Architecture Programmer's Manual Volume 2: System Programming Pub. +24593 Rev. 3.42 [2] Section 16.12 "x2APIC_ID" mentions the Extended +Enumeration leaf 0xb (Fn0000_000B_EDX[31:0])(which was later superseded by the +extended leaf 0x80000026) provides the full x2APIC ID under all circumstances +unlike the one reported by CPUID leaf 0x8000001e EAX which depends on the mode +in which APIC is configured. + +Rely on the APIC ID parsed during cpu_parse_topology_ext() from CPUID leaf +0x80000026 or 0xb and only use the APIC ID from leaf 0x8000001e if +cpu_parse_topology_ext() failed (has_topoext is false). + +On platforms that support the 0xb leaf (Zen2 or later, AMD guests on +QEMU) or the extended leaf 0x80000026 (Zen4 or later), the +initial_apicid is now set to the value parsed from EDX[31:0]. + +On older AMD/Hygon platforms that do not support the 0xb leaf but support the +TOPOEXT extension (families 0x15, 0x16, 0x17[Zen1], and Hygon), retain current +behavior where the initial_apicid is set using the 0x8000001e leaf. + +Issue debugged by Naveen N Rao (AMD) and Sairaj Kodilkar +. + + [ bp: Massage commit message. ] + +Fixes: c749ce393b8f ("x86/cpu: Use common topology code for AMD") +Suggested-by: Thomas Gleixner +Signed-off-by: K Prateek Nayak +Signed-off-by: Borislav Petkov (AMD) +Tested-by: Naveen N Rao (AMD) +Cc: stable@vger.kernel.org +Link: https://github.com/qemu/qemu/commit/35ac5dfbcaa4b [1] +Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 [2] +Link: https://lore.kernel.org/20250825075732.10694-2-kprateek.nayak@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/topology_amd.c | 23 ++++++++++++++--------- + 1 file changed, 14 insertions(+), 9 deletions(-) + +--- a/arch/x86/kernel/cpu/topology_amd.c ++++ b/arch/x86/kernel/cpu/topology_amd.c +@@ -80,20 +80,25 @@ static bool parse_8000_001e(struct topo_ + + cpuid_leaf(0x8000001e, &leaf); + +- tscan->c->topo.initial_apicid = leaf.ext_apic_id; +- + /* +- * If leaf 0xb is available, then the domain shifts are set +- * already and nothing to do here. Only valid for family >= 0x17. ++ * If leaf 0xb/0x26 is available, then the APIC ID and the domain ++ * shifts are set already. + */ +- if (!has_topoext && tscan->c->x86 >= 0x17) { ++ if (!has_topoext) { ++ tscan->c->topo.initial_apicid = leaf.ext_apic_id; ++ + /* +- * Leaf 0x80000008 set the CORE domain shift already. +- * Update the SMT domain, but do not propagate it. ++ * Leaf 0x8000008 sets the CORE domain shift but not the ++ * SMT domain shift. On CPUs with family >= 0x17, there ++ * might be hyperthreads. + */ +- unsigned int nthreads = leaf.core_nthreads + 1; ++ if (tscan->c->x86 >= 0x17) { ++ /* Update the SMT domain, but do not propagate it. */ ++ unsigned int nthreads = leaf.core_nthreads + 1; + +- topology_update_dom(tscan, TOPO_SMT_DOMAIN, get_count_order(nthreads), nthreads); ++ topology_update_dom(tscan, TOPO_SMT_DOMAIN, ++ get_count_order(nthreads), nthreads); ++ } + } + + store_node(tscan, leaf.nnodes_per_socket + 1, leaf.node_id); diff --git a/queue-6.12/x86-microcode-amd-handle-the-case-of-no-bios-microcode.patch b/queue-6.12/x86-microcode-amd-handle-the-case-of-no-bios-microcode.patch new file mode 100644 index 0000000000..aa9d867acc --- /dev/null +++ b/queue-6.12/x86-microcode-amd-handle-the-case-of-no-bios-microcode.patch @@ -0,0 +1,66 @@ +From fcf8239ad6a5de54fa7ce18e464c6b5951b982cb Mon Sep 17 00:00:00 2001 +From: "Borislav Petkov (AMD)" +Date: Wed, 20 Aug 2025 11:58:57 +0200 +Subject: x86/microcode/AMD: Handle the case of no BIOS microcode +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Borislav Petkov (AMD) + +commit fcf8239ad6a5de54fa7ce18e464c6b5951b982cb upstream. + +Machines can be shipped without any microcode in the BIOS. Which means, +the microcode patch revision is 0. + +Handle that gracefully. + +Fixes: 94838d230a6c ("x86/microcode/AMD: Use the family,model,stepping encoded in the patch ID") +Reported-by: Vítek Vávra +Signed-off-by: Borislav Petkov (AMD) +Cc: +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/microcode/amd.c | 22 ++++++++++++++++++++-- + 1 file changed, 20 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/cpu/microcode/amd.c ++++ b/arch/x86/kernel/cpu/microcode/amd.c +@@ -159,8 +159,28 @@ static int cmp_id(const void *key, const + return 1; + } + ++static u32 cpuid_to_ucode_rev(unsigned int val) ++{ ++ union zen_patch_rev p = {}; ++ union cpuid_1_eax c; ++ ++ c.full = val; ++ ++ p.stepping = c.stepping; ++ p.model = c.model; ++ p.ext_model = c.ext_model; ++ p.ext_fam = c.ext_fam; ++ ++ return p.ucode_rev; ++} ++ + static bool need_sha_check(u32 cur_rev) + { ++ if (!cur_rev) { ++ cur_rev = cpuid_to_ucode_rev(bsp_cpuid_1_eax); ++ pr_info_once("No current revision, generating the lowest one: 0x%x\n", cur_rev); ++ } ++ + switch (cur_rev >> 8) { + case 0x80012: return cur_rev <= 0x800126f; break; + case 0x80082: return cur_rev <= 0x800820f; break; +@@ -741,8 +761,6 @@ static struct ucode_patch *cache_find_pa + n.equiv_cpu = equiv_cpu; + n.patch_id = uci->cpu_sig.rev; + +- WARN_ON_ONCE(!n.patch_id); +- + list_for_each_entry(p, µcode_cache, plist) + if (patch_cpus_equivalent(p, &n, false)) + return p; diff --git a/queue-6.12/xfs-do-not-propagate-enodata-disk-errors-into-xattr-code.patch b/queue-6.12/xfs-do-not-propagate-enodata-disk-errors-into-xattr-code.patch new file mode 100644 index 0000000000..58076f9cbb --- /dev/null +++ b/queue-6.12/xfs-do-not-propagate-enodata-disk-errors-into-xattr-code.patch @@ -0,0 +1,81 @@ +From ae668cd567a6a7622bc813ee0bb61c42bed61ba7 Mon Sep 17 00:00:00 2001 +From: Eric Sandeen +Date: Fri, 22 Aug 2025 12:55:56 -0500 +Subject: xfs: do not propagate ENODATA disk errors into xattr code + +From: Eric Sandeen + +commit ae668cd567a6a7622bc813ee0bb61c42bed61ba7 upstream. + +ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code; +namely, that the requested attribute name could not be found. + +However, a medium error from disk may also return ENODATA. At best, +this medium error may escape to userspace as "attribute not found" +when in fact it's an IO (disk) error. + +At worst, we may oops in xfs_attr_leaf_get() when we do: + + error = xfs_attr_leaf_hasname(args, &bp); + if (error == -ENOATTR) { + xfs_trans_brelse(args->trans, bp); + return error; + } + +because an ENODATA/ENOATTR error from disk leaves us with a null bp, +and the xfs_trans_brelse will then null-deref it. + +As discussed on the list, we really need to modify the lower level +IO functions to trap all disk errors and ensure that we don't let +unique errors like this leak up into higher xfs functions - many +like this should be remapped to EIO. + +However, this patch directly addresses a reported bug in the xattr +code, and should be safe to backport to stable kernels. A larger-scope +patch to handle more unique errors at lower levels can follow later. + +(Note, prior to 07120f1abdff we did not oops, but we did return the +wrong error code to userspace.) + +Signed-off-by: Eric Sandeen +Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines") +Cc: stable@vger.kernel.org # v5.9+ +Reviewed-by: Darrick J. Wong +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/libxfs/xfs_attr_remote.c | 7 +++++++ + fs/xfs/libxfs/xfs_da_btree.c | 6 ++++++ + 2 files changed, 13 insertions(+) + +--- a/fs/xfs/libxfs/xfs_attr_remote.c ++++ b/fs/xfs/libxfs/xfs_attr_remote.c +@@ -435,6 +435,13 @@ xfs_attr_rmtval_get( + 0, &bp, &xfs_attr3_rmt_buf_ops); + if (xfs_metadata_is_sick(error)) + xfs_dirattr_mark_sick(args->dp, XFS_ATTR_FORK); ++ /* ++ * ENODATA from disk implies a disk medium failure; ++ * ENODATA for xattrs means attribute not found, so ++ * disambiguate that here. ++ */ ++ if (error == -ENODATA) ++ error = -EIO; + if (error) + return error; + +--- a/fs/xfs/libxfs/xfs_da_btree.c ++++ b/fs/xfs/libxfs/xfs_da_btree.c +@@ -2833,6 +2833,12 @@ xfs_da_read_buf( + &bp, ops); + if (xfs_metadata_is_sick(error)) + xfs_dirattr_mark_sick(dp, whichfork); ++ /* ++ * ENODATA from disk implies a disk medium failure; ENODATA for ++ * xattrs means attribute not found, so disambiguate that here. ++ */ ++ if (error == -ENODATA && whichfork == XFS_ATTR_FORK) ++ error = -EIO; + if (error) + goto out_free; + -- 2.47.3