From: Greg Kroah-Hartman Date: Mon, 1 Sep 2025 12:48:23 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v5.4.298~20 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1649224d762ef922f3baea8d09d6a5414ef08b30;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch drm-nouveau-disp-always-accept-linear-modifier.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-multitouch-fix-slab-out-of-bounds-access-in-mt_report_fixup.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 smb3-client-fix-return-code-mapping-of-remap_file_range.patch --- diff --git a/queue-6.1/dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch b/queue-6.1/dma-pool-ensure-dma_direct_remap-allocations-are-decrypted.patch new file mode 100644 index 0000000000..07f86efc23 --- /dev/null +++ b/queue-6.1/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.1/drm-nouveau-disp-always-accept-linear-modifier.patch b/queue-6.1/drm-nouveau-disp-always-accept-linear-modifier.patch new file mode 100644 index 0000000000..ad48e0a27d --- /dev/null +++ b/queue-6.1/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.1/fs-smb-fix-inconsistent-refcnt-update.patch b/queue-6.1/fs-smb-fix-inconsistent-refcnt-update.patch new file mode 100644 index 0000000000..c113a26651 --- /dev/null +++ b/queue-6.1/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 +@@ -81,8 +81,10 @@ static int smb2_compound_op(const unsign + int len; + + 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]; + +@@ -510,6 +512,7 @@ static int smb2_compound_op(const unsign + break; + } + ++out: + if (cfile) + cifsFileInfo_put(cfile); + diff --git a/queue-6.1/hid-asus-fix-uaf-via-hid_claimed_input-validation.patch b/queue-6.1/hid-asus-fix-uaf-via-hid_claimed_input-validation.patch new file mode 100644 index 0000000000..c915c4d15f --- /dev/null +++ b/queue-6.1/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 +@@ -1117,7 +1117,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.1/hid-hid-ntrig-fix-unable-to-handle-page-fault-in-ntrig_report_version.patch b/queue-6.1/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.1/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.1/hid-multitouch-fix-slab-out-of-bounds-access-in-mt_report_fixup.patch b/queue-6.1/hid-multitouch-fix-slab-out-of-bounds-access-in-mt_report_fixup.patch new file mode 100644 index 0000000000..5f4a5c6315 --- /dev/null +++ b/queue-6.1/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 +@@ -1448,6 +1448,14 @@ static __u8 *mt_report_fixup(struct hid_ + 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.1/hid-wacom-add-a-new-art-pen-2.patch b/queue-6.1/hid-wacom-add-a-new-art-pen-2.patch new file mode 100644 index 0000000000..cc464dc0cc --- /dev/null +++ b/queue-6.1/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 +@@ -679,6 +679,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.1/kvm-x86-use-array_index_nospec-with-indices-that-come-from-guest.patch b/queue-6.1/kvm-x86-use-array_index_nospec-with-indices-that-come-from-guest.patch new file mode 100644 index 0000000000..d9f5e8f604 --- /dev/null +++ b/queue-6.1/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 +@@ -684,6 +684,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 +@@ -9681,8 +9681,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.1/net-usb-qmi_wwan-add-telit-cinterion-le910c4-wwx-new-compositions.patch b/queue-6.1/net-usb-qmi_wwan-add-telit-cinterion-le910c4-wwx-new-compositions.patch new file mode 100644 index 0000000000..a651f03fbd --- /dev/null +++ b/queue-6.1/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 +@@ -1362,6 +1362,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.1/revert-drm-amdgpu-fix-incorrect-vm-flags-to-map-bo.patch b/queue-6.1/revert-drm-amdgpu-fix-incorrect-vm-flags-to-map-bo.patch new file mode 100644 index 0000000000..59d60342c1 --- /dev/null +++ b/queue-6.1/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 +@@ -93,8 +93,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.1/series b/queue-6.1/series index 39e2b81d22..d78905d4d8 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -32,3 +32,14 @@ net-rose-convert-use-field-to-refcount_t.patch net-rose-include-node-references-in-rose_neigh-refco.patch sctp-initialize-more-fields-in-sctp_v6_from_sk.patch efivarfs-fix-slab-out-of-bounds-in-efivarfs_d_compar.patch +kvm-x86-use-array_index_nospec-with-indices-that-come-from-guest.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-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 +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 +drm-nouveau-disp-always-accept-linear-modifier.patch diff --git a/queue-6.1/smb3-client-fix-return-code-mapping-of-remap_file_range.patch b/queue-6.1/smb3-client-fix-return-code-mapping-of-remap_file_range.patch new file mode 100644 index 0000000000..5a23fe7d6b --- /dev/null +++ b/queue-6.1/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 +@@ -1363,6 +1363,20 @@ static loff_t cifs_remap_file_range(stru + netfs_resize_file(&target_cifsi->netfs, 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; ++ } + } + } +