kernel/git/stable/linux-stable.git/drivers/firmware, branch linux-6.6.y

firmware: arm_scmi: Roll back partial protocol table registration

2026-09-14T11:30:05+00:00

[ Upstream commit 2224b622260ba590ab56ea1585d6bf7610be25b2 ] scmi_protocol_table_register() can leave earlier requests registered when a later entry in the same ID table fails. Each request retains a pointer to the driver's ID table, so a failed module load can leave a dangling pointer after the module storage is released. Unrequest only the successfully registered prefix, in reverse order, before returning the failure. Leave the failed entry and the remaining entries untouched because matching requests can be owned by another driver. Fixes: 2858f6e5f064 ("firmware: arm_scmi: Add multiple protocols registration support") Reported-by: Sashiko Link: https://patch.msgid.link/20260722173521.2184378-1-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: coreboot: Validate table bounds

2026-09-14T11:29:33+00:00

[ Upstream commit a58a57a1076f8c5dae0327e3710899478c3be901 ] The existing coreboot_table_populate() bounds checks limit individual entries to the mapped length. However, coreboot_table_probe() replaces the platform resource length with header and table sizes supplied by firmware before mapping the full table. A malformed table can overflow the 32-bit size addition or advertise an extent beyond the resource, causing the driver to map and parse memory outside the resource. A resource shorter than the fixed header is also mapped as though it contained a complete header. Reject resources shorter than the fixed header. After validating the signature, require a complete header, calculate the advertised extent with overflow checking, and reject extents beyond the resource before remapping the table. Fixes: d384d6f43d1e ("firmware: google memconsole: Add coreboot support") Signed-off-by: Laxman Acharya Padhya Link: https://lore.kernel.org/r/20260801165651.42172-1-acharyalaxman8848@gmail.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin

firmware: google: Add bounds checks in coreboot_table_populate()

2026-09-14T11:29:33+00:00

[ Upstream commit 7b1a1af4556a4f95ef273e91435fe804cbfcd223 ] coreboot_table_populate() iterates over firmware-provided table entries with no validation that the entries stay within the mapped memory region. A corrupt table with a large `entry->size` advances `ptr_entry` past the mapped region, causing an out-of-bounds read on the next iteration. Add a check before dereferencing `ptr_entry` to ensure the entry header is readable, and a second check after reading `entry->size` to ensure the full entry stays within the mapped region. Pass `len` from coreboot_table_probe() into coreboot_table_populate() to make the mapped region size available for validation. Signed-off-by: Titouan Ameline de Cadeville Reviewed-by: Julius Werner Link: https://lore.kernel.org/r/20260426214739.117131-1-titouan.ameline@gmail.com Signed-off-by: Tzung-Bi Shih Stable-dep-of: a58a57a1076f ("firmware: coreboot: Validate table bounds") Signed-off-by: Sasha Levin

firmware: arm_scmi: Unrequest devices if driver registration fails

2026-09-14T11:29:22+00:00

[ Upstream commit 9f7cd6a62aa754ed6b48cbd5d50de40add1bcc86 ] scmi_driver_register() requests protocol devices before registering the driver. If driver_register() fails, those requests remain in the global IDR and retain pointers to the module's ID table. Once the failed module load releases that storage, later request matching or SCMI device creation can dereference the stale pointers. Unrequest the complete protocol table before returning the registration failure. At this point table registration succeeded, so every entry is owned by the current registration attempt. Fixes: d3cd7c525fd2 ("firmware: arm_scmi: Refactor protocol device creation") Reported-by: Sashiko Link: https://patch.msgid.link/20260722173521.2184378-2-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_scmi: Add multiple protocols registration support

2026-09-14T11:29:22+00:00

[ Upstream commit 2858f6e5f06440d6b9e9c3f57bc68915344830a9 ] Add the capability for a SCMI driver to register to the core SCMI stack with multiple SCMI protocols. In such a case the SCMI driver probe function will end up being called once for each registered protocol which have been also found as implemented on the platform. This is especially useful in testing scenarios. Signed-off-by: Cristian Marussi Link: https://lore.kernel.org/r/20231221151129.325749-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla Stable-dep-of: 9f7cd6a62aa7 ("firmware: arm_scmi: Unrequest devices if driver registration fails") Signed-off-by: Sasha Levin

firmware: arm_scmi: Fix requested device removal race

2026-09-14T11:29:19+00:00

[ Upstream commit 2c4097e6c4aed276c5e9ec2ab331ab397ea780bf ] scmi_protocol_device_unrequest() drops scmi_requested_devices_mtx while notifying listeners but continues to retain the per-protocol list head. When two SCMI drivers for the same protocol unregister concurrently, one thread can remove the final request and free the list head while the other is running its notifier. The latter then dereferences the freed list head after reacquiring the mutex and can free it a second time. Complete the list and IDR updates, including freeing an empty list head, before dropping the mutex. Keep the blocking notifier outside the critical section and retain only the detached request across the callback. Fixes: d3cd7c525fd2 ("firmware: arm_scmi: Refactor protocol device creation") Reported-by: Sashiko Link: https://patch.msgid.link/20260722095250.2011630-1-sudeep.holla@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_scmi: Drop handle on protocol bind failures

2026-09-14T11:29:12+00:00

[ Upstream commit e3a5c30d233ca5d3e799a80da806554c703bda13 ] The SCMI bus notifier acquires an SCMI handle when the driver core emits BUS_NOTIFY_BIND_DRIVER, before invoking the protocol driver probe callback. The protocol probe path only checks whether sdev->handle is set. If device_link_add() fails after the handle has been acquired, the protocol device can still bind with a valid handle but without the dependency link to the SCMI parent. A concurrent parent unbind can then miss the child and tear down the SCMI instance while the child still holds a handle into it. If the protocol driver probe later fails, for example with -EPROBE_DEFER, the driver core emits BUS_NOTIFY_DRIVER_NOT_BOUND rather than BUS_NOTIFY_UNBOUND_DRIVER. The SCMI notifier only released the handle on BUS_NOTIFY_UNBOUND_DRIVER, so each failed protocol-device bind leaked the SCMI instance users refcount and left sdev->handle set after the failed probe. Make the link helper report failure and drop the acquired handle if the link cannot be created. Also handle BUS_NOTIFY_DRIVER_NOT_BOUND in the same cleanup path used for unbind so failed probes balance the earlier BUS_NOTIFY_BIND_DRIVER acquisition. Fixes: 971fc0665f13 ("firmware: arm_scmi: Move handle get/set helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-10-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_scmi: Protect device request lookup with RCU

2026-09-14T11:29:12+00:00

[ Upstream commit e6a0e7a49d83e4fa4e1db68d74f99282eb97aa49 ] The SCMI device request notifier looks up protocol OF nodes from the active_protocols IDR. The IDR lookup can run concurrently with protocol activation while probe is still registering protocols and creating their SCMI devices. Wrap the lookup in an RCU read-side critical section as required by the IDR API for lockless readers. Fixes: 53b8c25df708 ("firmware: arm_scmi: Add common notifier helpers") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-9-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_scmi: Use channel ID for transport teardown

2026-09-14T11:29:12+00:00

[ Upstream commit a71a3d4d8a6e9e399fd988c0e6da47a6ee21c99e ] SCMI protocols can share the BASE transport channel when firmware does not describe a dedicated channel for the protocol. In that case multiple IDR entries can point at the same scmi_chan_info, whose owning transport device was created with cinfo->id. scmi_chan_destroy() used the IDR iterator key when destroying the transport device. If an alias entry is visited before the owning channel entry, the lookup can miss the device because the iterator key does not match the protocol ID used when the transport device was created. The code then clears cinfo->dev, so the later owning entry skips teardown and leaks the transport device. Destroy the transport device using cinfo->id, which is the protocol ID that owns the channel and was used when creating the transport device. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-8-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_scmi: Reject out of range DT protocol IDs

2026-09-14T11:29:12+00:00

[ Upstream commit 59407ccb52130f2c81f4b3cbe4f14114afceb54f ] SCMI protocol IDs carried in message headers are limited by MSG_PROTOCOL_ID_MASK. The DT parsing paths noticed protocol IDs outside that range, but only logged an error and then kept processing the invalid value. That lets a malformed 32-bit DT reg value reach helpers which take a u8 protocol ID, where it can be truncated and/or treated as a different protocol. For channel setup, two different out-of-range values can also be used as distinct IDR keys while aliasing the generated SCMI protocol identity. Skip DT protocol nodes whose reg value does not fit the SCMI protocol ID field before setting up channels or creating protocol devices. Fixes: 05a2801d8b90 ("firmware: arm_scmi: Use dedicated devices to initialize channels") Reported-by: Sashiko Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-7-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin