--- /dev/null
+From 198f36f902ec7e99b645382505f74b87a4523ed9 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bvanassche@acm.org>
+Date: Mon, 25 Aug 2025 11:27:19 -0700
+Subject: blk-zoned: Fix a lockdep complaint about recursive locking
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+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 <dlemoal@kernel.org>
+Cc: Christoph Hellwig <hch@lst.de>
+Fixes: dd291d77cc90 ("block: Introduce zone write plugging")
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
+Link: https://lore.kernel.org/r/20250825182720.1697203-1-bvanassche@acm.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
+ /*
--- /dev/null
+From 89a2d212bdb4bc29bed8e7077abe054b801137ea Mon Sep 17 00:00:00 2001
+From: Shanker Donthineni <sdonthineni@nvidia.com>
+Date: Mon, 11 Aug 2025 13:17:59 -0500
+Subject: dma/pool: Ensure DMA_DIRECT_REMAP allocations are decrypted
+
+From: Shanker Donthineni <sdonthineni@nvidia.com>
+
+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 <sdonthineni@nvidia.com>
+Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
+Link: https://lore.kernel.org/r/20250811181759.998805-1-sdonthineni@nvidia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 5dff50802b285da8284a7bf17ae2fdc6f1357023 Mon Sep 17 00:00:00 2001
+From: Yang Wang <kevinyang.wang@amd.com>
+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 <kevinyang.wang@amd.com>
+
+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 <kevinyang.wang@amd.com>
+Reviewed-by: Asad Kamal <asad.kamal@amd.com>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit e82a8d441038d8cb10b63047a9e705c42479d156)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) ||
--- /dev/null
+From 1f403699c40f0806a707a9a6eed3b8904224021a Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+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 <make24@iscas.ac.cn>
+
+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 <make24@iscas.ac.cn>
+Reviewed-by: CK Hu <ck.hu@mediatek.com>
+Link: https://patchwork.kernel.org/project/dri-devel/patch/20250812071932.471730-1-make24@iscas.ac.cn/
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
--- /dev/null
+From e2fe0c54fb7401e6ecd3c10348519ab9e23bd639 Mon Sep 17 00:00:00 2001
+From: James Jones <jajones@nvidia.com>
+Date: Mon, 11 Aug 2025 15:00:16 -0700
+Subject: drm/nouveau/disp: Always accept linear modifier
+
+From: James Jones <jajones@nvidia.com>
+
+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 <jajones@nvidia.com>
+Link: https://lore.kernel.org/r/20250811220017.1337-3-jajones@nvidia.com
+Signed-off-by: Danilo Krummrich <dakr@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 66e82b6e0a28d4970383e1ee5d60f431001128cd Mon Sep 17 00:00:00 2001
+From: Timur Tabi <ttabi@nvidia.com>
+Date: Tue, 12 Aug 2025 19:10:02 -0500
+Subject: drm/nouveau: fix error path in nvkm_gsp_fwsec_v2
+
+From: Timur Tabi <ttabi@nvidia.com>
+
+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 <ttabi@nvidia.com>
+Link: https://lore.kernel.org/r/20250813001004.2986092-1-ttabi@nvidia.com
+Signed-off-by: Danilo Krummrich <dakr@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From 2b55ddf36229e0278c956215784ab1feeff510aa Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>
+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 <thomas.hellstrom@linux.intel.com>
+
+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 <thomas.hellstrom@linux.intel.com>
+Fixes: 06951c2ee72d ("drm/xe: Use NULL PTEs as scratch PTEs")
+Cc: Brian Welty <brian.welty@intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Cc: Lucas De Marchi <lucas.demarchi@intel.com>
+Cc: <stable@vger.kernel.org> # v6.8+
+Reviewed-by: Matthew Brost <matthew.brost@intel.com>
+Link: https://lore.kernel.org/r/20250821143045.106005-4-thomas.hellstrom@linux.intel.com
+(cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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]);
+ }
--- /dev/null
+From ab529e6ca1f67bcf31f3ea80c72bffde2e9e053e Mon Sep 17 00:00:00 2001
+From: Shuhao Fu <sfual@cse.ust.hk>
+Date: Thu, 28 Aug 2025 02:24:19 +0800
+Subject: fs/smb: Fix inconsistent refcnt update
+
+From: Shuhao Fu <sfual@cse.ust.hk>
+
+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 <sfual@cse.ust.hk>
+Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From d3af6ca9a8c34bbd8cff32b469b84c9021c9e7e4 Mon Sep 17 00:00:00 2001
+From: Qasim Ijaz <qasdev00@gmail.com>
+Date: Sun, 10 Aug 2025 19:10:41 +0100
+Subject: HID: asus: fix UAF via HID_CLAIMED_INPUT validation
+
+From: Qasim Ijaz <qasdev00@gmail.com>
+
+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] <TASK>
+[ 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 <qasdev00@gmail.com>
+Link: https://patch.msgid.link/20250810181041.44874-1-qasdev00@gmail.com
+Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 185c926283da67a72df20a63a5046b3b4631b7d9 Mon Sep 17 00:00:00 2001
+From: Minjong Kim <minbell.kim@samsung.com>
+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 <minbell.kim@samsung.com>
+
+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 <minbell.kim@samsung.com>
+Link: https://patch.msgid.link/20250813-hid-ntrig-page-fault-fix-v2-1-f98581f35106@samsung.com
+Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From ab1bb82f3db20e23eace06db52031b1164a110c2 Mon Sep 17 00:00:00 2001
+From: Matt Coffin <mcoffin13@gmail.com>
+Date: Wed, 20 Aug 2025 01:49:51 -0600
+Subject: HID: logitech: Add ids for G PRO 2 LIGHTSPEED
+
+From: Matt Coffin <mcoffin13@gmail.com>
+
+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 <mcoffin13@gmail.com>
+Reviewed-by: Bastien Nocera <hadess@hadess.net>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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),
--- /dev/null
+From 0379eb8691b9c4477da0277ae0832036ca4410b4 Mon Sep 17 00:00:00 2001
+From: Qasim Ijaz <qasdev00@gmail.com>
+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 <qasdev00@gmail.com>
+
+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] <TASK>
+[ 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 <qasdev00@gmail.com>
+Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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(
--- /dev/null
+From 1f3214aae9f49faf495f3836216afbc6c5400b2e Mon Sep 17 00:00:00 2001
+From: Antheas Kapenekakis <lkml@antheas.dev>
+Date: Sun, 3 Aug 2025 18:02:53 +0200
+Subject: HID: quirks: add support for Legion Go dual dinput modes
+
+From: Antheas Kapenekakis <lkml@antheas.dev>
+
+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 <lkml@antheas.dev>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 },
--- /dev/null
+From 9fc51941d9e7793da969b2c66e6f8213c5b1237f Mon Sep 17 00:00:00 2001
+From: Ping Cheng <pinglinux@gmail.com>
+Date: Sun, 10 Aug 2025 22:40:30 -0700
+Subject: HID: wacom: Add a new Art Pen 2
+
+From: Ping Cheng <pinglinux@gmail.com>
+
+commit 9fc51941d9e7793da969b2c66e6f8213c5b1237f upstream.
+
+Signed-off-by: Ping Cheng <ping.cheng@wacom.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From c87bd4dd43a624109c3cc42d843138378a7f4548 Mon Sep 17 00:00:00 2001
+From: Thijs Raymakers <thijs@raymakers.nl>
+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 <thijs@raymakers.nl>
+
+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 <thijs@raymakers.nl>
+Cc: stable@vger.kernel.org
+Cc: Sean Christopherson <seanjc@google.com>
+Cc: Paolo Bonzini <pbonzini@redhat.com>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+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 <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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();
+
--- /dev/null
+From e81a7f65288c7e2cfb7e7890f648e099fd885ab3 Mon Sep 17 00:00:00 2001
+From: Fabio Porcedda <fabio.porcedda@gmail.com>
+Date: Fri, 22 Aug 2025 11:13:24 +0200
+Subject: net: usb: qmi_wwan: add Telit Cinterion LE910C4-WWX new compositions
+
+From: Fabio Porcedda <fabio.porcedda@gmail.com>
+
+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 <fabio.porcedda@gmail.com>
+Link: https://patch.msgid.link/20250822091324.39558-1-Fabio.Porcedda@telit.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From ac4ed2da4c1305a1a002415058aa7deaf49ffe3e Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Mon, 25 Aug 2025 13:40:22 -0400
+Subject: Revert "drm/amdgpu: fix incorrect vm flags to map bo"
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+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 <alexander.deucher@amd.com>
+(cherry picked from commit be33e8a239aac204d7e9e673c4220ef244eb1ba3)
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 799766208f09f95677a9ab111b93872d414fbad7 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@ventanamicro.com>
+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ář <rkrcmar@ventanamicro.com>
+
+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ář <rkrcmar@ventanamicro.com>
+Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com>
+Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
+Link: https://lore.kernel.org/r/20250805104418.196023-4-rkrcmar@ventanamicro.com
+Signed-off-by: Anup Patel <anup@brainfault.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
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
--- /dev/null
+From 0e08fa789d39aa01923e3ba144bd808291895c3c Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Sat, 23 Aug 2025 21:15:59 -0500
+Subject: smb3 client: fix return code mapping of remap_file_range
+
+From: Steve French <stfrench@microsoft.com>
+
+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) <pc@manguebit.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From c2415c407a2cde01290d52ce2a1f81b0616379a3 Mon Sep 17 00:00:00 2001
+From: K Prateek Nayak <kprateek.nayak@amd.com>
+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 <kprateek.nayak@amd.com>
+
+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) <naveen@kernel.org> and Sairaj Kodilkar
+<sarunkod@amd.com>.
+
+ [ bp: Massage commit message. ]
+
+Fixes: c749ce393b8f ("x86/cpu: Use common topology code for AMD")
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Tested-by: Naveen N Rao (AMD) <naveen@kernel.org>
+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 <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From fcf8239ad6a5de54fa7ce18e464c6b5951b982cb Mon Sep 17 00:00:00 2001
+From: "Borislav Petkov (AMD)" <bp@alien8.de>
+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) <bp@alien8.de>
+
+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 <vit.vavra.kh@gmail.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: <stable@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From ae668cd567a6a7622bc813ee0bb61c42bed61ba7 Mon Sep 17 00:00:00 2001
+From: Eric Sandeen <sandeen@redhat.com>
+Date: Fri, 22 Aug 2025 12:55:56 -0500
+Subject: xfs: do not propagate ENODATA disk errors into xattr code
+
+From: Eric Sandeen <sandeen@redhat.com>
+
+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 <sandeen@redhat.com>
+Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines")
+Cc: stable@vger.kernel.org # v5.9+
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+Signed-off-by: Carlos Maiolino <cem@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
