Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

217 participants
124036 discussions

[PATCH] ARM: fix memset64() on big-endian

by Thomas Weißschuh

On big-endian systems the 32-bit low and high halves need to be swapped, for the underlying assembly implemenation to work correctly. Fixes: fd1d362600e2 ("ARM: implement memset32 & memset64") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> --- Found by the string_test_memset64 KUnit test. --- arch/arm/include/asm/string.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h index 6c607c68f3ad..c35250c4991b 100644 --- a/arch/arm/include/asm/string.h +++ b/arch/arm/include/asm/string.h @@ -42,7 +42,10 @@ static inline void *memset32(uint32_t *p, uint32_t v, __kernel_size_t n) extern void *__memset64(uint64_t *, uint32_t low, __kernel_size_t, uint32_t hi); static inline void *memset64(uint64_t *p, uint64_t v, __kernel_size_t n) { - return __memset64(p, v, n * 8, v >> 32); + if (IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN)) + return __memset64(p, v, n * 8, v >> 32); + else + return __memset64(p, v >> 32, n * 8, v); } /* --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251230-armeb-memset64-01f2ae83f9ef Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

4 days, 18 hours

[PATCH] usb: dwc3: Check for USB4 IP_NAME

by Thinh Nguyen

Synopsys renamed DWC_usb32 IP to DWC_usb4 as of IP version 1.30. No functional change except checking for the IP_NAME here. The driver will treat the new IP_NAME as if it's DWC_usb32. Additional features for USB4 will be introduced and checked separately. Cc: stable(a)vger.kernel.org Signed-off-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> --- drivers/usb/dwc3/core.c | 2 ++ drivers/usb/dwc3/core.h | 1 + 2 files changed, 3 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 96f85eada047..f71b75465a60 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -993,6 +993,8 @@ static bool dwc3_core_is_valid(struct dwc3 *dwc) reg = dwc3_readl(dwc->regs, DWC3_GSNPSID); dwc->ip = DWC3_GSNPS_ID(reg); + if (dwc->ip == DWC4_IP) + dwc->ip = DWC32_IP; /* This should read as U3 followed by revision number */ if (DWC3_IP_IS(DWC3)) { diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index a5fc92c4ffa3..45757169b672 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -1265,6 +1265,7 @@ struct dwc3 { #define DWC3_IP 0x5533 #define DWC31_IP 0x3331 #define DWC32_IP 0x3332 +#define DWC4_IP 0x3430 u32 revision; base-commit: 18514fd70ea4ca9de137bb3bceeac1bac4bcad75 -- 2.28.0

4 days, 19 hours

[PATCH v2 0/2] netrom: fix deadlock and refcount leak in nr_rt_device_down

by Junjie Cao

Hi, syzbot reported a circular locking dependency in the NET/ROM routing code involving nr_neigh_list_lock, nr_node_list_lock and nr_node->node_lock when nr_rt_device_down() interacts with the ioctl path. This series fixes that deadlock and also addresses a long-standing reference count leak found while auditing the same code. Patch 1/2 refactors nr_rt_device_down() to avoid nested locking between nr_neigh_list_lock and nr_node_list_lock by doing two separate passes over nodes and neighbours, and adjusts nr_rt_free() to follow the same lock ordering. Patch 2/2 fixes a per-route reference count leak by dropping nr_neigh->count and calling nr_neigh_put() when removing routes from nr_rt_device_down(), mirroring the behaviour of nr_dec_obs()/nr_del_node(). [1] https://syzkaller.appspot.com/bug?extid=14afda08dc3484d5db82 Thanks, Junjie

4 days, 20 hours

[PATCH 6.12.y 0/7] Few CVE fixes.

by Harshit Mogalapalli

Hi stable maintainers, I have tried backporting some fixes to stable kernel 6.12.y which also have CVE numbers and are fixing commits in 6.12.y. I am not a subsystem expert and have only done overall testing that we do for stable release candidate testing and not any patch specific testing. Note: All these patches are present backports from upstream. PATCH 1: The broken commit is in 6.12.y, and the fix is a clean cherry-pick and addresses CVE-2025-68206 PATCH 2: The broken commit is present in 6.12.y and the fix is a clean cherry-pick and addresses CVE-2025-40325. PATCH 3: The broken commit is present in 6.12.y and backport needed a minor conflict resolution due to missing commit fe69a3918084 ("drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs in 6.12.y PATCH 4,5,6: Patch 4 and 5 are pulled in as prerequisites for PATCH 6 which is a fix for CVE-2025-40170 and needed a minor conflict resolution due to missing commit: 22d6c9eebf2e ("net: Unexport shared functions for DCCP.") in 6.12.y PATCH 7: The broken commit in present in 6.12.y and the backport of the fix needed a minor conflict resolution due to missing commit in 6.12.y. This is fix for CVE-2025-40164. Please let me know if there are any comments. Regards, Harshit Andrii Melnychenko (1): netfilter: nft_ct: add seqadj extension for natted connections Boris Brezillon (1): drm/panthor: Flush shmem writes before mapping buffers CPU-uncached Eric Dumazet (2): ipv6: adopt dst_dev() helper net: use dst_dev_rcu() in sk_setup_caps() Justin Iurman (1): net: ipv6: ioam6: use consistent dst names Xiao Ni (1): md/raid10: wait barrier before returning discard request with REQ_NOWAIT Zqiang (1): usbnet: Fix using smp_processor_id() in preemptible code warnings drivers/gpu/drm/panthor/panthor_gem.c | 18 +++++++++++++ drivers/md/raid10.c | 3 +-- drivers/net/usb/usbnet.c | 2 ++ include/net/ip.h | 6 +++-- include/net/ip6_route.h | 4 +-- include/net/route.h | 2 +- net/core/sock.c | 16 +++++++----- net/ipv6/exthdrs.c | 2 +- net/ipv6/icmp.c | 4 ++- net/ipv6/ila/ila_lwt.c | 2 +- net/ipv6/ioam6_iptunnel.c | 37 ++++++++++++++------------- net/ipv6/ip6_gre.c | 8 +++--- net/ipv6/ip6_output.c | 19 +++++++------- net/ipv6/ip6_tunnel.c | 4 +-- net/ipv6/ip6_udp_tunnel.c | 2 +- net/ipv6/ip6_vti.c | 2 +- net/ipv6/ndisc.c | 6 +++-- net/ipv6/netfilter/nf_dup_ipv6.c | 2 +- net/ipv6/output_core.c | 2 +- net/ipv6/route.c | 20 +++++++++------ net/ipv6/rpl_iptunnel.c | 4 +-- net/ipv6/seg6_iptunnel.c | 20 ++++++++------- net/ipv6/seg6_local.c | 2 +- net/netfilter/nft_ct.c | 5 ++++ 24 files changed, 118 insertions(+), 74 deletions(-) -- 2.50.1

4 days, 21 hours

[PATCH v3 0/3] Address page fault in ima_restore_measurement_list()

by Harshit Mogalapalli

On x86_64: When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page This happens on x86_64 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") V1: https://lore.kernel.org/all/20251112193005.3772542-1-harshit.m.mogalapalli@… V1 attempted to do a similar sanity check in x86_64. Borislav suggested to add a generic helper ima_validate_range() which could then be used for both OF based and x86_64. Testing information: -------------------- On x86_64: With latest 6.19-rc2 based, we could reproduce the issue, and patched kernel works fine. (with mem=8G on a 16G memory machine) Thanks to Yifei for finding enabling IMA_KEXEC is the cause. Thanks for the reviews on V1. V1 -> V2: - Patch 1: Add a generic helper "ima_validate_range()" - Patch 2: Use this new helper in drivers/of/kexec.c -> No functional change. - Patch 3: Fix the page fault by doing sanity check with "ima_validate_range()" V2: https://lore.kernel.org/all/20251229081523.622515-1-harshit.m.mogalapalli@o… V2 -> V3: Update subject of Patch 1 to more appropriate one (Suggested by Mimi Zohar) Thanks, Harshit Harshit Mogalapalli (3): ima: verify the previous kernel's IMA buffer lies in addressable RAM of/kexec: refactor ima_get_kexec_buffer() to use ima_validate_range() x86/kexec: Add a sanity check on previous kernel's ima kexec buffer arch/x86/kernel/setup.c | 6 +++++ drivers/of/kexec.c | 15 +++---------- include/linux/ima.h | 1 + security/integrity/ima/ima_kexec.c | 35 ++++++++++++++++++++++++++++++ 4 files changed, 45 insertions(+), 12 deletions(-) -- 2.50.1

4 days, 21 hours

[PATCH 1/2] writeback: fix 100% CPU usage when dirtytime_expire_interval is 0

by Laveesh Bansal

When vm.dirtytime_expire_seconds is set to 0, wakeup_dirtytime_writeback() schedules delayed work with a delay of 0, causing immediate execution. The function then reschedules itself with 0 delay again, creating an infinite busy loop that causes 100% kworker CPU usage. Fix by: - Only scheduling delayed work in wakeup_dirtytime_writeback() when dirtytime_expire_interval is non-zero - Cancelling the delayed work in dirtytime_interval_handler() when the interval is set to 0 - Adding a guard in start_dirtytime_writeback() for defensive coding Tested by booting kernel in QEMU with virtme-ng: - Before fix: kworker CPU spikes to ~73% - After fix: CPU remains at normal levels - Setting interval back to non-zero correctly resumes writeback Fixes: a2f4870697a5 ("fs: make sure the timestamps for lazytime inodes eventually get written") Cc: stable(a)vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220227 Signed-off-by: Laveesh Bansal <laveeshb(a)laveeshbansal.com> --- fs/fs-writeback.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 6800886c4d10..cd21c74cd0e5 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2492,7 +2492,8 @@ static void wakeup_dirtytime_writeback(struct work_struct *w) wb_wakeup(wb); } rcu_read_unlock(); - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); } static int dirtytime_interval_handler(const struct ctl_table *table, int write, @@ -2501,8 +2502,12 @@ static int dirtytime_interval_handler(const struct ctl_table *table, int write, int ret; ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos); - if (ret == 0 && write) - mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + if (ret == 0 && write) { + if (dirtytime_expire_interval) + mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + else + cancel_delayed_work_sync(&dirtytime_work); + } return ret; } @@ -2519,7 +2524,8 @@ static const struct ctl_table vm_fs_writeback_table[] = { static int __init start_dirtytime_writeback(void) { - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); register_sysctl_init("vm", vm_fs_writeback_table); return 0; } -- 2.43.0

4 days, 21 hours

[PATCH 1/2] writeback: fix 100% CPU usage when dirtytime_expire_interval is 0

by Laveesh Bansal

From: Laveesh Bansal <laveeshbansal(a)gmail.com> When vm.dirtytime_expire_seconds is set to 0, wakeup_dirtytime_writeback() schedules delayed work with a delay of 0, causing immediate execution. The function then reschedules itself with 0 delay again, creating an infinite busy loop that causes 100% kworker CPU usage. Fix by: - Only scheduling delayed work in wakeup_dirtytime_writeback() when dirtytime_expire_interval is non-zero - Cancelling the delayed work in dirtytime_interval_handler() when the interval is set to 0 - Adding a guard in start_dirtytime_writeback() for defensive coding Tested by booting kernel in QEMU with virtme-ng: - Before fix: kworker CPU spikes to ~73% - After fix: CPU remains at normal levels - Setting interval back to non-zero correctly resumes writeback Fixes: a2f4870697a5 ("fs: make sure the timestamps for lazytime inodes eventually get written") Cc: stable(a)vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220227 Signed-off-by: Laveesh Bansal <laveeshbansal(a)gmail.com> --- fs/fs-writeback.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 6800886c4d10..cd21c74cd0e5 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2492,7 +2492,8 @@ static void wakeup_dirtytime_writeback(struct work_struct *w) wb_wakeup(wb); } rcu_read_unlock(); - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); } static int dirtytime_interval_handler(const struct ctl_table *table, int write, @@ -2501,8 +2502,12 @@ static int dirtytime_interval_handler(const struct ctl_table *table, int write, int ret; ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos); - if (ret == 0 && write) - mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + if (ret == 0 && write) { + if (dirtytime_expire_interval) + mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + else + cancel_delayed_work_sync(&dirtytime_work); + } return ret; } @@ -2519,7 +2524,8 @@ static const struct ctl_table vm_fs_writeback_table[] = { static int __init start_dirtytime_writeback(void) { - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); register_sysctl_init("vm", vm_fs_writeback_table); return 0; } -- 2.43.0

4 days, 21 hours

Re: NRF 2026 Retail's Big Show more information

by Amy Giles

Hi, I wanted to see if you had time to review the email I sent earlier. Should you need any other details, don't hesitate to reach out. Best Amy Giles Please reply with REMOVE if you don't wish to receive further emails -----Original Message----- Hi, Hope you're having a great day! Are you looking for leads from NRF 2026 Retail's Big Show? Attendees count: 30,000 Leads Data Fields: Company Name, Web URL, Contact Name, Title, Direct Email, Phone Number, Mailing Address, Industry, Employee Size, Annual Sales. If you're interested in these leads, I'd be glad to share the pricing. Let me know! Thanks for the quick reply. I'm excited to get your thoughts. Best Amy Giles Demand Generation Manager Zoom Connect, Inc Please reply with REMOVE if you don't wish to receive further emails

4 days, 21 hours

RE: CES 2026: Audience Breakdown & Leads

by Jessica Garcia

Hi , Just touching base to see if you're available to discuss this further. If you have any uncertainties, I'm happy to help. Regards Jessica Marketing Manager Campaign Data Leads., Please reply with REMOVE if you don't wish to receive further emails -----Original Message----- From: Jessica Garcia Subject: CES 2026: Audience Breakdown & Leads Hi , Trust you're in good spirits. Is the idea of buying the CES 2026 attendees' details for your marketing efforts something you'd like to explore? Expo Name: Consumer Electronics Show 2026 Total Number of records: 40,000 records List includes: Company Name, Contact Name, Job Title, Mailing Address, Phone, Emails, etc. Best chance to connect with participants Feel free to contact me if you are interested in acquiring this list so that I can share pricing information with you Hoping for your prompt feedback. Regards Jessica Marketing Manager Campaign Data Leads., Please reply with REMOVE if you don't wish to receive further emails

5 days

[PATCH 2/5] ARM: dts: microchip: sama7d65: fix size-cells property for i2c3

by nicolas.ferre＠microchip.com

From: Nicolas Ferre <nicolas.ferre(a)microchip.com> Fix the #size-cells property for i2c3 node and remove the dtbs_check error telling that "#size-cells: 0 was expected" from schema atmel,at91sam-i2c.yaml and i2c-controller.yaml. Fixes: b51e4aea3ecf ("ARM: dts: microchip: sama7d65: Add FLEXCOMs to sama7d65 SoC") Cc: <stable(a)vger.kernel.org> # 6.16+ Signed-off-by: Nicolas Ferre <nicolas.ferre(a)microchip.com> --- arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi index 5f3a7b178aa7..868045c650a7 100644 --- a/arch/arm/boot/dts/microchip/sama7d65.dtsi +++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi @@ -527,7 +527,7 @@ i2c3: i2c@600 { interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; clocks = <&pmc PMC_TYPE_PERIPHERAL 37>; #address-cells = <1>; - #size-cells = <1>; + #size-cells = <0>; dmas = <&dma0 AT91_XDMAC_DT_PERID(12)>, <&dma0 AT91_XDMAC_DT_PERID(11)>; dma-names = "tx", "rx"; -- 2.43.0

5 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror