kernel/linux.git, branch v5.15.197

Linux 5.15.197

2025-12-06T21:09:37+00:00

Link: https://lore.kernel.org/r/20251203152414.082328008@linuxfoundation.org Tested-by: Hardik Garg Tested-by: Shuah Khan Tested-by: Ron Economos Link: https://lore.kernel.org/r/20251204163821.402208337@linuxfoundation.org Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Brett A C Sheffield Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman

libbpf: Fix invalid return address register in s390

2025-12-06T21:09:37+00:00

commit 7244eb669397f309c3d014264823cdc9cb3f8e6b upstream. There is currently an invalid register mapping in the s390 return address register. As the manual[1] states, the return address can be found at r14. In bpf_tracing.h, the s390 registers were named gprs(general purpose registers). This commit fixes the problem by correcting the mistyped mapping. [1]: https://uclibc.org/docs/psABI-s390x.pdf#page=14 Fixes: 3cc31d794097 ("libbpf: Normalize PT_REGS_xxx() macro definitions") Signed-off-by: Daniel T. Lee Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20221224071527.2292-7-danieltimlee@gmail.com Signed-off-by: Greg Kroah-Hartman

libbpf, riscv: Use a0 for RC register

2025-12-06T21:09:37+00:00

commit 935dc35c75318fa213d26808ad8bb130fb0b486e upstream. According to the RISC-V calling convention register usage here [0], a0 is used as return value register, so rename it to make it consistent with the spec. [0] section 18.2, table 18.2 https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf Fixes: 589fed479ba1 ("riscv, libbpf: Add RISC-V (RV64) support to bpf_tracing.h") Signed-off-by: Yixun Lan Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Acked-by: Amjad OULED-AMEUR Link: https://lore.kernel.org/bpf/20220706140204.47926-1-dlan@gentoo.org Signed-off-by: Greg Kroah-Hartman

libbpf: Fix riscv register names

2025-12-06T21:09:37+00:00

commit 5c101153bfd67387ba159b7864176217a40757da upstream. riscv registers are accessed via struct user_regs_struct, not struct pt_regs. The program counter member in this struct is called pc, not epc. The frame pointer is called s0, not fp. Fixes: 3cc31d794097 ("libbpf: Normalize PT_REGS_xxx() macro definitions") Signed-off-by: Ilya Leoshkevich Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220209021745.2215452-6-iii@linux.ibm.com Signed-off-by: Greg Kroah-Hartman

selftests/bpf: Don't rely on preserving volatile in PT_REGS macros in loop3

2025-12-06T21:09:36+00:00

commit 70bc793382a0e37ba4e35e4d1a317b280b829a44 upstream. PT_REGS*() macro on some architectures force-cast struct pt_regs to other types (user_pt_regs, etc) and might drop volatile modifiers, if any. Volatile isn't really required as pt_regs value isn't supposed to change during the BPF program run, so this is correct behavior. But progs/loop3.c relies on that volatile modifier to ensure that loop is preserved. Fix loop3.c by declaring i and sum variables as volatile instead. It preserves the loop and makes the test pass on all architectures (including s390x which is currently broken). Fixes: 3cc31d794097 ("libbpf: Normalize PT_REGS_xxx() macro definitions") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220106205156.955373-1-andrii@kernel.org Signed-off-by: Greg Kroah-Hartman

scsi: pm80xx: Set phy->enable_completion only when we

2025-12-06T21:09:36+00:00

[ Upstream commit e4f949ef1516c0d74745ee54a0f4882c1f6c7aea ] pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash. Signed-off-by: Igor Pylypiv Signed-off-by: Terrence Adams Link: https://lore.kernel.org/r/20240627155924.2361370-2-tadamsjr@google.com Acked-by: Jack Wang Signed-off-by: Martin K. Petersen Signed-off-by: Nazar Kalashnikov Signed-off-by: Greg Kroah-Hartman

Bluetooth: Add more enc key size check

2025-12-06T21:09:36+00:00

[ Upstream commit 04a342cc49a8522e99c9b3346371c329d841dcd2 ] When we are slave role and receives l2cap conn req when encryption has started, we should check the enc key size to avoid KNOB attack or BLUFFS attack. >From SIG recommendation, implementations are advised to reject service-level connections on an encrypted baseband link with key strengths below 7 octets. A simple and clear way to achieve this is to place the enc key size check in hci_cc_read_enc_key_size() The btmon log below shows the case that lacks enc key size check. > HCI Event: Connect Request (0x04) plen 10 Address: BB:22:33:44:55:99 (OUI BB-22-33) Class: 0x480104 Major class: Computer (desktop, notebook, PDA, organizers) Minor class: Desktop workstation Capturing (Scanner, Microphone) Telephony (Cordless telephony, Modem, Headset) Link type: ACL (0x01) < HCI Command: Accept Connection Request (0x01|0x0009) plen 7 Address: BB:22:33:44:55:99 (OUI BB-22-33) Role: Peripheral (0x01) > HCI Event: Command Status (0x0f) plen 4 Accept Connection Request (0x01|0x0009) ncmd 2 Status: Success (0x00) > HCI Event: Connect Complete (0x03) plen 11 Status: Success (0x00) Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Link type: ACL (0x01) Encryption: Disabled (0x00) ... > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Encryption: Enabled with E0 (0x01) < HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2 Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) > HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 2 Status: Success (0x00) Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Key size: 6 // We should check the enc key size ... > ACL Data RX: Handle 1 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 3 len 4 PSM: 25 (0x0019) Source CID: 64 < ACL Data TX: Handle 1 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 3 len 8 Destination CID: 64 Source CID: 64 Result: Connection pending (0x0001) Status: Authorization pending (0x0002) > HCI Event: Number of Completed Packets (0x13) plen 5 Num handles: 1 Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Count: 1 #35: len 16 (25 Kb/s) Latency: 5 msec (2-7 msec ~4 msec) < ACL Data TX: Handle 1 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 3 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000) Cc: stable@vger.kernel.org Signed-off-by: Alex Lu Signed-off-by: Max Chou Signed-off-by: Luiz Augusto von Dentz [ Nazar Kalashnikov: change status to rp_status due to function parameter conflict ] Signed-off-by: Nazar Kalashnikov Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: psy: Set max current to zero when disconnected

2025-12-06T21:09:36+00:00

[ Upstream commit 23379a17334fc24c4a9cbd9967d33dcd9323cc7c ] The ucsi_psy_get_current_max function defaults to 0.1A when it is not clear how much current the partner device can support. But this does not check the port is connected, and will report 0.1A max current when nothing is connected. Update ucsi_psy_get_current_max to report 0A when there is no connection. Fixes: af833e7f7db3 ("usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2 and Default") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Reviewed-by: Heikki Krogerus Reviewed-by: Sebastian Reichel Tested-by: Kenneth R. Crudup Rule: add Link: https://lore.kernel.org/stable/20251017000051.2094101-1-jthies%40google.com Link: https://patch.msgid.link/20251106011446.2052583-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman [ adapted UCSI_CONSTAT() macro to direct flag access ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usb: renesas_usbhs: Fix synchronous external abort on unbind

2025-12-06T21:09:36+00:00

[ Upstream commit eb9ac779830b2235847b72cb15cf07c7e3333c5e ] A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo "0x1d6b" > idVendor echo "0x0104" > idProduct mkdir -p strings/0x409 echo "0123456789" > strings/0x409/serialnumber echo "Renesas." > strings/0x409/manufacturer echo "Ethernet Gadget" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo "ECM" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove. Cc: stable Fixes: f1407d5c6624 ("usb: renesas_usbhs: Add Renesas USBHS common code") Signed-off-by: Claudiu Beznea Link: https://patch.msgid.link/20251027140741.557198-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usb: renesas_usbhs: Convert to platform remove callback returning void

2025-12-06T21:09:36+00:00

[ Upstream commit 456a91ce7de4b9157fd5013c1e4dd8dd3c6daccb ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Reviewed-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20230517230239.187727-89-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: eb9ac779830b ("usb: renesas_usbhs: Fix synchronous external abort on unbind") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman