The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y
git checkout FETCH_HEAD
git cherry-pick -x cd65ee81240e8bc3c3119b46db7f60c80864b90b
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025070814-pebbly-diffused-9cd9@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From cd65ee81240e8bc3c3119b46db7f60c80864b90b Mon Sep 17 00:00:00 2001
From: Hongyu Xie <xiehongyu1(a)kylinos.cn>
Date: Fri, 27 Jun 2025 17:41:20 +0300
Subject: [PATCH] xhci: Disable stream for xHC controller with
XHCI_BROKEN_STREAMS
Disable stream for platform xHC controller with broken stream.
Fixes: 14aec589327a6 ("storage: accept some UAS devices if streams are unavailable")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Hongyu Xie <xiehongyu1(a)kylinos.cn>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Link: https://lore.kernel.org/r/20250627144127.3889714-3-mathias.nyman@linux.inte…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6dab142e7278..c79d5ed48a08 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -328,7 +328,8 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s
}
usb3_hcd = xhci_get_usb3_hcd(xhci);
- if (usb3_hcd && HCC_MAX_PSA(xhci->hcc_params) >= 4)
+ if (usb3_hcd && HCC_MAX_PSA(xhci->hcc_params) >= 4 &&
+ !(xhci->quirks & XHCI_BROKEN_STREAMS))
usb3_hcd->can_do_streams = 1;
if (xhci->shared_hcd) {
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x cd65ee81240e8bc3c3119b46db7f60c80864b90b
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025070814-harmonica-eclipse-ad04@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From cd65ee81240e8bc3c3119b46db7f60c80864b90b Mon Sep 17 00:00:00 2001
From: Hongyu Xie <xiehongyu1(a)kylinos.cn>
Date: Fri, 27 Jun 2025 17:41:20 +0300
Subject: [PATCH] xhci: Disable stream for xHC controller with
XHCI_BROKEN_STREAMS
Disable stream for platform xHC controller with broken stream.
Fixes: 14aec589327a6 ("storage: accept some UAS devices if streams are unavailable")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Hongyu Xie <xiehongyu1(a)kylinos.cn>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Link: https://lore.kernel.org/r/20250627144127.3889714-3-mathias.nyman@linux.inte…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6dab142e7278..c79d5ed48a08 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -328,7 +328,8 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s
}
usb3_hcd = xhci_get_usb3_hcd(xhci);
- if (usb3_hcd && HCC_MAX_PSA(xhci->hcc_params) >= 4)
+ if (usb3_hcd && HCC_MAX_PSA(xhci->hcc_params) >= 4 &&
+ !(xhci->quirks & XHCI_BROKEN_STREAMS))
usb3_hcd->can_do_streams = 1;
if (xhci->shared_hcd) {
[Sinldo Technology]
Company Profile
Hong Kong Sinldo Technology Co., Ltd. was established in 2009 and focuses on the supply chain of Qualcomm chips. As a leading supplier in the industry,
We have established solid cooperative relationships with many internationally renowned manufacturers and are committed to providing customers with high-quality and reliable chip products.
Business Scope:
Import and distribution of Qualcomm chips
Management and bidding for excess electronic components
Provide high-quality customer service and technical support
Mission
Stable supply
Vision
Mutual benefit and Triumph
Value
Reduce Fees and increase efficiency
Environment
The company is located in the core business district, with convenient transportation, elegant environment and complete surrounding supporting facilities, which facilitates the travel and business exchanges of employees and customers.
Milestones
2025
2020
2015
2009
It is expected to complete the upgrade strategic planning, further increase market share, and strive for sustainable development
The company implemented a digital management system and began to actively develop online Deals channels
The company has added multiple 4G Qualcomm chips and established partnerships with more OEM customers。
The company was formally established in Shenzhen and initially established cooperative relationships with global suppliers
Company Environment
Coastal Huanqing
Building
Office Area
storehouse
[Qualcomm]Company Spot
[ WIFI6 - IPQ5018 Kits ]
IPQ5018-0-MRQFN232-MT-01-0
QCN6102-0-DRQFN116-TR-01-0
QCA8337-AL3C
Snapdragon SDM-450-B Kits
SDM-450-B-792NSP-TR-01-0-AA
WTR-2965-0-59F0WNSP-TR-07-1
PMI-8952-0-144WLNSP-TR-02-0-00
WCN-3680B-0-79BWLNSP-TR-05-1
PM-8953-0-187F0WNSP-TR-01-1
MDM9x07 Kits
MDM-9607-0-328PSP-TR-00-0
MDM-9207-0-328PSP-TR-00-0
WTR-2965-0-59F0WNSP-TR-07-1
PMD-9607-0-94WLNSP-TR-04-2
[Sinldo Technology Co., Ltd.]
Email:yesunjian888(a)gmail.com
Skype:625285556(a)qq.com
Address:Room 2305, Hai'an Huanqing Building,
Futian Road, Futian District, Shenzhen
Wechat
Hit subscribe now to receive regular updates and our product’s latest features! Subscribe
If you don't want to receive our emails, you can easily unsubscribe here.
Alan Ye
Purchasing Manager
:+86 136 0651 6680
QUALCOMM
Supply chain : yesunjian888(a)gmail.com
HCR_EL2.VSE is delivering a virtual SError to the guest, and does not
affect EL2 itself. However, when computing the host's HCR_EL2 value,
we take the guest's view of HCR_EL2.VSE at face value, and apply it
irrespective of the guest's exception level we are returning to.
The result is that a L1 hypervisor injecting a virtual SError to an L2
by setting its HCR_EL2.VSE to 1 results in itself getting the SError
as if it was a physical one if it traps for any reason before returning
to L2.
Fix it by filtering HCR_EL2.VSE out when entering the L1 host context.
Fixes: 04ab519bb86df ("KVM: arm64: nv: Configure HCR_EL2 for FEAT_NV2")
Signed-off-by: Marc Zyngier <maz(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
arch/arm64/kvm/hyp/vhe/switch.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 477f1580ffeaa..eddda649d9ee1 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -68,6 +68,9 @@ static u64 __compute_hcr(struct kvm_vcpu *vcpu)
if (!vcpu_el2_e2h_is_set(vcpu))
hcr |= HCR_NV1;
+ /* Virtual SErrors only apply to L2, not L1 */
+ guest_hcr &= ~HCR_VSE;
+
write_sysreg_s(vcpu->arch.ctxt.vncr_array, SYS_VNCR_EL2);
} else {
host_data_clear_flag(VCPU_IN_HYP_CONTEXT);
--
2.39.2
Hi,
Imagine having direct access to 1,605 top exhibitors and 86,571 attendees at Integrated Systems Europe (ISE) 2025.
We have the latest comprehensive list with last-minute additions, helping you connect with decision-makers, industry leaders, and potential partners.
Available Data Fields: Individual Email Address, Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, and more.
Act fast — respond by July 20th to claim your 20% discount.
Interested? Simply reply with “Send me pricing” and I’ll get all the details over to you.
Best regards,
Mary Jannifer
Sr. Demand Generation
Not interested? Reply “Unfollow” to opt out.
Use cdev_del() instead of direct kobject_put() when cdev_add() fails.
This aligns with standard kernel practice and maintains consistency
within the driver's own error paths.
Found by code review.
Cc: stable(a)vger.kernel.org
Fixes: 8cb5d216ab33 ("char: xillybus: Move class-related functions to new xillybus_class.c")
Signed-off-by: Ma Ke <make24(a)iscas.ac.cn>
---
Changes in v4:
- Apologize, due to the long time that has passed since the last v2 version, I was negligent when submitting v3. I have now corrected it;
Changes in v3:
- modified the patch description, centralized cdev cleanup through standard API and maintained symmetry with driver's existing error handling;
Changes in v2:
- modified the patch as suggestions to avoid UAF.
---
drivers/char/xillybus/xillybus_class.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/xillybus/xillybus_class.c b/drivers/char/xillybus/xillybus_class.c
index c92a628e389e..493bbed918c2 100644
--- a/drivers/char/xillybus/xillybus_class.c
+++ b/drivers/char/xillybus/xillybus_class.c
@@ -103,8 +103,7 @@ int xillybus_init_chrdev(struct device *dev,
unit->num_nodes);
if (rc) {
dev_err(dev, "Failed to add cdev.\n");
- /* kobject_put() is normally done by cdev_del() */
- kobject_put(&unit->cdev->kobj);
+ cdev_del(unit->cdev);
goto unregister_chrdev;
}
--
2.25.1
The quilt patch titled
Subject: kasan: use vmalloc_dump_obj() for vmalloc error reports
has been removed from the -mm tree. Its filename was
kasan-use-vmalloc_dump_obj-for-vmalloc-error-reports.patch
This patch was dropped because it was merged into the mm-hotfixes-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Marco Elver <elver(a)google.com>
Subject: kasan: use vmalloc_dump_obj() for vmalloc error reports
Date: Wed, 16 Jul 2025 17:23:28 +0200
Since 6ee9b3d84775 ("kasan: remove kasan_find_vm_area() to prevent
possible deadlock"), more detailed info about the vmalloc mapping and the
origin was dropped due to potential deadlocks.
While fixing the deadlock is necessary, that patch was too quick in
killing an otherwise useful feature, and did no due-diligence in
understanding if an alternative option is available.
Restore printing more helpful vmalloc allocation info in KASAN reports
with the help of vmalloc_dump_obj(). Example report:
| BUG: KASAN: vmalloc-out-of-bounds in vmalloc_oob+0x4c9/0x610
| Read of size 1 at addr ffffc900002fd7f3 by task kunit_try_catch/493
|
| CPU: [...]
| Call Trace:
| <TASK>
| dump_stack_lvl+0xa8/0xf0
| print_report+0x17e/0x810
| kasan_report+0x155/0x190
| vmalloc_oob+0x4c9/0x610
| [...]
|
| The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900002fd000 allocated at vmalloc_oob+0x36/0x610
| The buggy address belongs to the physical page:
| page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x126364
| flags: 0x200000000000000(node=0|zone=2)
| raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000
| raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
| page dumped because: kasan: bad access detected
|
| [..]
Link: https://lkml.kernel.org/r/20250716152448.3877201-1-elver@google.com
Fixes: 6ee9b3d84775 ("kasan: remove kasan_find_vm_area() to prevent possible deadlock")
Signed-off-by: Marco Elver <elver(a)google.com>
Suggested-by: Uladzislau Rezki <urezki(a)gmail.com>
Acked-by: Uladzislau Rezki (Sony) <urezki(a)gmail.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Andrey Konovalov <andreyknvl(a)gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Cc: Yeoreum Yun <yeoreum.yun(a)arm.com>
Cc: Yunseong Kim <ysk(a)kzalloc.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/kasan/report.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/mm/kasan/report.c~kasan-use-vmalloc_dump_obj-for-vmalloc-error-reports
+++ a/mm/kasan/report.c
@@ -399,7 +399,9 @@ static void print_address_description(vo
}
if (is_vmalloc_addr(addr)) {
- pr_err("The buggy address %px belongs to a vmalloc virtual mapping\n", addr);
+ pr_err("The buggy address belongs to a");
+ if (!vmalloc_dump_obj(addr))
+ pr_cont(" vmalloc virtual mapping\n");
page = vmalloc_to_page(addr);
}
_
Patches currently in -mm which might be from elver(a)google.com are