linux-stable.git/drivers, branch v6.18.2

usb: dwc3: dwc3_power_off_all_roothub_ports: Use ioremap_np when required

2025-12-18T13:03:42+00:00

commit 5ed9cc71432a8adf3c42223c935f714aac29901b upstream.

On Apple Silicon machines we can't use ioremap() / Device-nGnRE to map most
regions but must use ioremap_np() / Device-nGnRnE whenever
IORESOURCE_MEM_NONPOSTED is set. Make sure this is also done inside
dwc3_power_off_all_roothub_ports to prevent SErrors.

Fixes: 2d2a3349521d ("usb: dwc3: Add workaround for host mode VBUS glitch when boot")
Cc: stable@kernel.org
Acked-by: Thinh Nguyen 
Reviewed-by: Neal Gompa 
Signed-off-by: Sven Peter 
Link: https://patch.msgid.link/20251015-b4-aplpe-dwc3-v2-2-cbd65a2d511a@kernel.org
Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: fix use-after-free caused by uec->work

2025-12-18T13:03:42+00:00

commit 2b7a0f47aaf2439d517ba0a6b29c66a535302154 upstream.

The delayed work uec->work is scheduled in gaokun_ucsi_probe()
but never properly canceled in gaokun_ucsi_remove(). This creates
use-after-free scenarios where the ucsi and gaokun_ucsi structure
are freed after ucsi_destroy() completes execution, while the
gaokun_ucsi_register_worker() might be either currently executing
or still pending in the work queue. The already-freed gaokun_ucsi
or ucsi structure may then be accessed.

Furthermore, the race window is 3 seconds, which is sufficiently
long to make this bug easily reproducible. The following is the
trace captured by KASAN:

==================================================================
BUG: KASAN: slab-use-after-free in __run_timers+0x5ec/0x630
Write of size 8 at addr ffff00000ec28cc8 by task swapper/0/0
...
Call trace:
 show_stack+0x18/0x24 (C)
 dump_stack_lvl+0x78/0x90
 print_report+0x114/0x580
 kasan_report+0xa4/0xf0
 __asan_report_store8_noabort+0x20/0x2c
 __run_timers+0x5ec/0x630
 run_timer_softirq+0xe8/0x1cc
 handle_softirqs+0x294/0x720
 __do_softirq+0x14/0x20
 ____do_softirq+0x10/0x1c
 call_on_irq_stack+0x30/0x48
 do_softirq_own_stack+0x1c/0x28
 __irq_exit_rcu+0x27c/0x364
 irq_exit_rcu+0x10/0x1c
 el1_interrupt+0x40/0x60
 el1h_64_irq_handler+0x18/0x24
 el1h_64_irq+0x6c/0x70
 arch_local_irq_enable+0x4/0x8 (P)
 do_idle+0x334/0x458
 cpu_startup_entry+0x60/0x70
 rest_init+0x158/0x174
 start_kernel+0x2f8/0x394
 __primary_switched+0x8c/0x94

Allocated by task 72 on cpu 0 at 27.510341s:
 kasan_save_stack+0x2c/0x54
 kasan_save_track+0x24/0x5c
 kasan_save_alloc_info+0x40/0x54
 __kasan_kmalloc+0xa0/0xb8
 __kmalloc_node_track_caller_noprof+0x1c0/0x588
 devm_kmalloc+0x7c/0x1c8
 gaokun_ucsi_probe+0xa0/0x840  auxiliary_bus_probe+0x94/0xf8
 really_probe+0x17c/0x5b8
 __driver_probe_device+0x158/0x2c4
 driver_probe_device+0x10c/0x264
 __device_attach_driver+0x168/0x2d0
 bus_for_each_drv+0x100/0x188
 __device_attach+0x174/0x368
 device_initial_probe+0x14/0x20
 bus_probe_device+0x120/0x150
 device_add+0xb3c/0x10fc
 __auxiliary_device_add+0x88/0x130
...

Freed by task 73 on cpu 1 at 28.910627s:
 kasan_save_stack+0x2c/0x54
 kasan_save_track+0x24/0x5c
 __kasan_save_free_info+0x4c/0x74
 __kasan_slab_free+0x60/0x8c
 kfree+0xd4/0x410
 devres_release_all+0x140/0x1f0
 device_unbind_cleanup+0x20/0x190
 device_release_driver_internal+0x344/0x460
 device_release_driver+0x18/0x24
 bus_remove_device+0x198/0x274
 device_del+0x310/0xa84
...

The buggy address belongs to the object at ffff00000ec28c00
 which belongs to the cache kmalloc-512 of size 512
The buggy address is located 200 bytes inside of
 freed 512-byte region
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ec28
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x3fffe0000000040(head|node=0|zone=0|lastcpupid=0x1ffff)
page_type: f5(slab)
raw: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 03fffe0000000040 ffff000008801c80 dead000000000122 0000000000000000
head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 03fffe0000000002 fffffdffc03b0a01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff00000ec28b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff00000ec28c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff00000ec28c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                              ^
 ffff00000ec28d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff00000ec28d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Add disable_delayed_work_sync() in gaokun_ucsi_remove() to ensure
that uec->work is properly canceled and prevented from executing
after the ucsi and gaokun_ucsi structure have been deallocated.

Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
Cc: stable 
Signed-off-by: Duoming Zhou 
Reviewed-by: Heikki Krogerus 
Link: https://patch.msgid.link/cc31e12ef9ffbf86676585b02233165fd33f0d8e.1764065838.git.duoming@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman

usb: phy: Initialize struct usb_phy list_head

2025-12-18T13:03:42+00:00

commit c69ff68b097b0f53333114f1b2c3dc128f389596 upstream.

As part of the registration of a new 'struct usb_phy' with the USB PHY core
via either usb_add_phy(struct usb_phy *x, ...) or usb_add_phy_dev(struct
usb_phy *x) these functions call list_add_tail(&x->head, phy_list) in
order for the new instance x to be stored in phy_list, a static list
kept internally by the core.

After 7d21114dc6a2 ("usb: phy: Introduce one extcon device into usb phy")
when executing either of the registration functions above it is possible
that usb_add_extcon() fails, leading to either function returning before
the call to list_add_tail(), leaving x->head uninitialized.

Then, when a driver tries to undo the failed registration by calling
usb_remove_phy(struct usb_phy *x) there will be an unconditional call to
list_del(&x->head) acting on an uninitialized variable, and thus a
possible NULL pointer dereference.

Fix this by initializing x->head before usb_add_extcon() has a
chance to fail. Note that this was not needed before 7d21114dc6a2 since
list_add_phy() was executed unconditionally and it guaranteed that x->head
was initialized.

Fixes: 7d21114dc6a2 ("usb: phy: Introduce one extcon device into usb phy")
Cc: stable 
Signed-off-by: Diogo Ivo 
Link: https://patch.msgid.link/20251121-diogo-smaug_typec-v2-1-5c37c1169d57@tecnico.ulisboa.pt
Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: fix probe failure in gaokun_ucsi_probe()

2025-12-18T13:03:42+00:00

commit 6b120ef99fbcba9e413783561f8cc160719db589 upstream.

The gaokun_ucsi_probe() uses ucsi_create() to allocate a UCSI instance.
The ucsi_create() validates whether ops->poll_cci is defined, and if not,
it directly returns -EINVAL. However, the gaokun_ucsi_ops structure does
not define the poll_cci, causing ucsi_create() always fail with -EINVAL.
This issue can be observed in the kernel log with the following error:

ucsi_huawei_gaokun.ucsi huawei_gaokun_ec.ucsi.0: probe with driver
ucsi_huawei_gaokun.ucsi failed with error -22

Fix the issue by adding the missing poll_cci callback to gaokun_ucsi_ops.

Fixes: 00327d7f2c8c ("usb: typec: ucsi: add Huawei Matebook E Go ucsi driver")
Cc: stable 
Signed-off-by: Duoming Zhou 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Pengyu Luo 
Link: https://patch.msgid.link/4d077d6439d728be68646bb8c8678436a3a0885e.1764065838.git.duoming@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman

usb: gadget: tegra-xudc: Always reinitialize data toggle when clear halt

2025-12-18T13:03:41+00:00

commit 2585973c7f9ee31d21e5848c996fab2521fd383d upstream.

The driver previously skipped handling ClearFeature(ENDPOINT_HALT)
when the endpoint was already not halted. This prevented the
controller from resetting the data sequence number and reinitializing
the endpoint state.

According to USB 3.2 specification Rev. 1.1, section 9.4.5,
ClearFeature(ENDPOINT_HALT) must always reset the data sequence and
set the stream state machine to Disabled, regardless of whether the
endpoint was halted.

Remove the early return so that ClearFeature(ENDPOINT_HALT) always
resets the endpoint sequence state as required by the specification.

Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller")
Cc: stable 
Signed-off-by: Haotien Hsu 
Signed-off-by: Wayne Chang 
Link: https://patch.msgid.link/20251127033540.2287517-1-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs

2025-12-18T13:03:41+00:00

[ Upstream commit 96b010536ee020e716d28d9b359a4bcd18800aeb ]

Up to UEFI spec 2.9, the type byte of CPER struct for ARM processor
was defined simply as:

Type at byte offset 4:

	- Cache error
	- TLB Error
	- Bus Error
	- Micro-architectural Error
	All other values are reserved

Yet, there was no information about how this would be encoded.

Spec 2.9A errata corrected it by defining:

	- Bit 1 - Cache Error
	- Bit 2 - TLB Error
	- Bit 3 - Bus Error
	- Bit 4 - Micro-architectural Error
	All other values are reserved

That actually aligns with the values already defined on older
versions at N.2.4.1. Generic Processor Error Section.

Spec 2.10 also preserve the same encoding as 2.9A.

Adjust CPER and GHES handling code for both generic and ARM
processors to properly handle UEFI 2.9A and 2.10 encoding.

Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-information
Signed-off-by: Mauro Carvalho Chehab 
Reviewed-by: Jonathan Cameron 
Acked-by: Borislav Petkov (AMD) 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

efi/cper: Adjust infopfx size to accept an extra space

2025-12-18T13:03:41+00:00

[ Upstream commit 8ad2c72e21efb3dc76c5b14089fa7984cdd87898 ]

Compiling with W=1 with werror enabled produces an error:

drivers/firmware/efi/cper-arm.c: In function ‘cper_print_proc_arm’:
drivers/firmware/efi/cper-arm.c:298:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
  298 |                         snprintf(infopfx, sizeof(infopfx), "%s ", newpfx);
      |                                                                ^
drivers/firmware/efi/cper-arm.c:298:25: note: ‘snprintf’ output between 2 and 65 bytes into a destination of size 64
  298 |                         snprintf(infopfx, sizeof(infopfx), "%s ", newpfx);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As the logic there adds an space at the end of infopx buffer.
Add an extra space to avoid such warning.

Signed-off-by: Mauro Carvalho Chehab 
Reviewed-by: Jonathan Cameron 
Acked-by: Borislav Petkov (AMD) 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

efi/cper: Add a new helper function to print bitmasks

2025-12-18T13:03:41+00:00

[ Upstream commit a976d790f49499ccaa0f991788ad8ebf92e7fd5c ]

Add a helper function to print a string with names associated
to each bit field.

A typical example is:

	const char * const bits[] = {
		"bit 3 name",
		"bit 4 name",
		"bit 5 name",
	};
	char str[120];
        unsigned int bitmask = BIT(3) | BIT(5);

	#define MASK  GENMASK(5,3)

	cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask),
			 bits, ARRAY_SIZE(bits));

The above code fills string "str" with "bit 3 name|bit 5 name".

Reviewed-by: Jonathan Cameron 
Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Borislav Petkov (AMD) 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()

2025-12-18T13:03:40+00:00

[ Upstream commit 7dbc0d40d8347bd9de55c904f59ea44bcc8dedb7 ]

If irq_domain_translate_twocell() sets "hwirq" to >= MCHP_EIC_NIRQ (2) then
it results in an out of bounds access.

The code checks for invalid values, but doesn't set the error code.  Return
-EINVAL in that case, instead of returning success.

Fixes: 00fa3461c86d ("irqchip/mchp-eic: Add support for the Microchip EIC")
Signed-off-by: Dan Carpenter 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Claudiu Beznea 
Link: https://patch.msgid.link/aTfHmOz6IBpTIPU5@stanley.mountain
Signed-off-by: Sasha Levin

scsi: ufs: core: Fix an error handler crash

2025-12-18T13:03:40+00:00

[ Upstream commit 14be351e5cd07349377010e457a58fac99201832 ]

The UFS error handler may be activated before SCSI scanning has started
and hence before hba->ufs_device_wlun has been set. Check the
hba->ufs_device_wlun pointer before using it.

Cc: Peter Wang 
Cc: Nitin Rawat 
Fixes: e23ef4f22db3 ("scsi: ufs: core: Fix error handler host_sem issue")
Fixes: f966e02ae521 ("scsi: ufs: core: Fix runtime suspend error deadlock")
Signed-off-by: Bart Van Assche 
Reviewed-by: Peter Wang 
Reviewed-by: Nitin Rawat 
Tested-by: Nitin Rawat  #SM8750
Link: https://patch.msgid.link/20251204170457.994851-1-bvanassche@acm.org
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin