kernel/linux.git/drivers/firmware, branch v7.0.13

firmware: samsung: acpm: Fix mailbox channel leak on probe error

2026-06-19T11:48:05+00:00

commit b66829b17f6385cc9ffbcbe2476d532d2e3121ad upstream. Sashiko identified the leak at [1]. The ACPM driver allocates hardware mailbox channels using `mbox_request_channel()` during `acpm_channels_init()`. However, the driver lacked a `.remove` callback and did not free these channels on subsequent error paths inside `acpm_probe()`. Additionally, if `acpm_achan_alloc_cmds()` failed during the channel initialization loop, the function returned immediately, bypassing the manual cleanup and permanently leaking any channels successfully requested in previous loop iterations. Fix this by modifying `acpm_free_mbox_chans()` to match the `devres` action signature and registering it via `devm_add_action_or_reset()`. Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260420-acpm-tmu-v3-0-3dc8e93f0b26%40linaro.org [1] Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-2-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman

firmware: stratix10-rsu: Fix NULL deref on rsu_send_msg() timeout in probe

2026-06-19T11:47:57+00:00

commit bfd2eb9bba548a8f63c3339bb1fb9a2031a42d86 upstream. rsu_send_msg() can return -ETIMEDOUT when wait_for_completion_interruptible_timeout() fires while the SMC call is still pending. In stratix10_rsu_probe(), the error paths for COMMAND_RSU_DCMF_VERSION, COMMAND_RSU_DCMF_STATUS, COMMAND_RSU_MAX_RETRY and COMMAND_RSU_GET_SPT_TABLE call stratix10_svc_free_channel() - which sets chan->scl to NULL - but then fall through and queue the next request on the same channel. The next svc kthread that runs will dereference pdata->chan->scl in its receive callback path, triggering a NULL pointer dereference identical to the one fixed by commit c45f7263100c ("firmware: stratix10-rsu: Fix NULL pointer dereference when RSU is disabled") for the COMMAND_RSU_STATUS path. Apply the same cleanup pattern to the remaining failure paths: remove the async client, free the channel, and return early so no further messages are queued on a channel whose scl has been cleared. While at it, clean up stratix10_rsu_probe() in two ways without changing behavior: - Drop redundant zero-initialization of fields already cleared by devm_kzalloc(): client.receive_cb, status.* and spt0/1_address (INVALID_SPT_ADDRESS is 0x0). - Replace five identical 3-line error-cleanup blocks (stratix10_svc_remove_async_client() + stratix10_svc_free_channel() + return ret) with goto labels (remove_async_client, free_channel), matching the standard kernel resource-unwinding pattern and making it easier to extend the probe sequence without forgetting matching cleanup. Also move init_completion() next to mutex_init() so sync-primitive initialization is grouped before anything that could trigger a callback. Fixes: 15847537b623 ("firmware: stratix10-rsu: Migrate RSU driver to use stratix10 asynchronous framework.") Cc: stable@kernel.org Assisted-by: Claude:claude-4.7-opus-high Cursor Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman

firmware: stratix10-svc: Return -EOPNOTSUPP when ATF async unsupported

2026-06-19T11:47:56+00:00

commit 3e529f57931417120fab700afeef6e49553250d5 upstream. Add a 'supported' flag to struct stratix10_async_ctrl to indicate whether the secure firmware supports SIP SVC v3 asynchronous communication. When the ATF version check in stratix10_svc_async_init() fails, set supported=false and return -EOPNOTSUPP instead of -EINVAL. This allows callers to distinguish between "async not supported by this ATF version" (-EOPNOTSUPP) and "programming error / bad argument" (-EINVAL), and take appropriate action (e.g. fall back to synchronous V1 SMC path) rather than treating both as fatal. Also update stratix10_svc_add_async_client() to return -EOPNOTSUPP immediately when async is not supported, rather than -EINVAL from the !actrl->initialized check, so client drivers receive a consistent and meaningful error code. This patch is a prerequisite for the following fix and must be applied together with it to correctly restore functionality on old ATF versions. Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication") Cc: stable@vger.kernel.org Suggested-by: Anders Hedlund Signed-off-by: Mahesh Rao Signed-off-by: Muhammad Amirul Asyraf Mohamad Jamian Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman

firmware: stratix10-svc: Don't fail probe when async ops unsupported

2026-06-19T11:47:56+00:00

commit 371aa062219a0af108fb8992f0759d1bac1e8c91 upstream. When the ATF version is too old to support SIP SVC v3 asynchronous operations (e.g. ATF 2.5), stratix10_svc_async_init() returns -EOPNOTSUPP. The probe function currently treats any non-zero return as fatal and aborts, logging: stratix10-svc firmware:svc: Intel Service Layer Driver: ATF version \ is not compatible for async operation stratix10-svc firmware:svc: probe with driver stratix10-svc failed \ with error -95 This prevents the SVC driver from loading entirely, causing all dependent client drivers (hwmon, RSU, FCS) to also fail to probe even though they can operate correctly via the synchronous V1 SMC path. Fix this by treating -EOPNOTSUPP from stratix10_svc_async_init() as a non-fatal degraded condition. The driver loads in sync-only mode and logs: stratix10-svc firmware:svc: Intel Service Layer Driver Initialized \ (sync-only mode) Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Amirul Asyraf Mohamad Jamian Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman

firmware: arm_ffa: Fix sched-recv callback partition lookup

2026-06-01T15:54:34+00:00

[ Upstream commit a6848a50404eefb6f0b131c21881a2d8d21b31a9 ] ffa_sched_recv_cb_update() used list_for_each_entry_safe() to search for a matching partition and then tested the iterator against NULL. That is not a valid end-of-list check for circular lists and can fall through with an invalid pointer. Use a normal iterator and detect the not-found case correctly before touching the partition state. Fixes: be61da938576 ("firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-11-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Snapshot notifier callbacks under lock

2026-06-01T15:54:34+00:00

[ Upstream commit 38290b180a4d5746baed796d49f88d56d2f336cd ] Both notification handlers currently look up a notifier callback under notify_lock, drop the lock, and then dereference the returned notifier entry. A concurrent unregister can delete and free that entry in the gap, leaving the handler to dereference stale memory. Copy the callback pointer and callback data while notify_lock is still held and invoke the callback only after the lock is dropped. This keeps the existing callback execution model while removing the use-after-free window in both the framework and non-framework notification paths. Fixes: 285a5ea0f542 ("firmware: arm_ffa: Add support for handling framework notifications") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-10-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Align RxTx buffer size before mapping

2026-06-01T15:54:34+00:00

[ Upstream commit 0399e3f872ca3d78044bb715a73ea645806d2c7b ] Commit 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP") advertises PAGE_ALIGN(rxtx_bufsz) to firmware when mapping the buffers but the driver continues to stores the minimum FF-A buffer size in drv_info->rxtx_bufsz which is used elsewhere in the driver. Align the size before storing it so that the allocation, validation and FFA_RXTX_MAP all use the same buffer size. Fixes: 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP") Cc: Sebastian Ene Link: https://sashiko.dev/#/patchset/20260402113939.930221-1-sebastianene@google.com Reviewed-by: Sebastian Ene Link: https://patch.msgid.link/20260428-ffa_fixes-v2-9-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Validate framework notification message layout

2026-06-01T15:54:34+00:00

[ Upstream commit 4a1cc9e96b311d2609a6f963a5e35bd4ae730d97 ] Framework notifications carry an indirect message in the shared RX buffer. Validate the reported offset and size before using them, reject zero-length payloads, and ensure that any non-header payload starts at the UUID field rather than in the middle of the message header. Use the validated offset and size values for both kmemdup() and the UUID parsing path so malformed firmware data cannot drive an out-of-bounds read or an oversized allocation. Fixes: 285a5ea0f542 ("firmware: arm_ffa: Add support for handling framework notifications") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-8-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Keep framework RX release under lock

2026-06-01T15:54:34+00:00

[ Upstream commit 2af18f8e36b277730527cacc2256b1332f56aa28 ] The framework notification handler drops rx_lock before issuing FFA_RX_RELEASE, leaving a window where another RX-buffer user can start a new FF-A transaction before ownership has actually been returned to firmware. Move the FFA_RX_RELEASE calls so they execute while rx_lock is still held on both the kmemdup() failure path and the normal success path. While doing that, switch the handler to scoped_guard() to keep the critical section explicit. Fixes: 285a5ea0f542 ("firmware: arm_ffa: Add support for handling framework notifications") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-7-8595ae450034@kernel.org Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies

2026-06-01T15:54:34+00:00

[ Upstream commit 3974ea1938406f9bfa7c1f48d4e43533f447bb08 ] The register-based PARTITION_INFO_GET path trusted the firmware-provided indices when copying partition descriptors into the caller buffer. Reject inconsistent counts or index progressions so the copy loop cannot write past the allocated array. Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS") Link: https://patch.msgid.link/20260428-ffa_fixes-v2-6-8595ae450034@kernel.org (fixed cur_idx when exactly one descriptor in the first fragment) Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin