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

firmware: samsung: acpm: Fix missing LKMM barriers in sequence allocator

2026-06-27T10:07:38+00:00

[ Upstream commit bf296f83a3ddab1ab875edc4e8862cb10553064f ] Sashiko identified memory ordering races in [1]. The ACPM driver uses a globally shared 'bitmap_seqnum' to track available sequence numbers. Even though threads now strictly free their own sequence numbers, the allocation and freeing of these bits across concurrent threads are effectively lockless operations and require explicit LKMM memory barriers. Previously, the driver used plain bitwise operators (test_bit, set_bit, clear_bit), which lack ordering guarantees. This creates two race conditions on weakly ordered architectures like ARM64: 1. Polling Release Violation: The polling thread copies its payload and calls clear_bit(). Without a release barrier, the CPU can reorder the memory operations, making the cleared bit globally visible before the payload reads have fully completed. 2. TX Acquire Violation: The TX thread loops on test_bit(), calls set_bit(), and then wipes the payload buffer via memset(). Without an acquire barrier, the CPU can speculatively execute the memset() before the bit is safely and formally claimed. If these reorderings overlap, a new TX thread can claim the sequence number and overwrite the buffer while the original polling thread is still actively reading from it. Fix this by upgrading the bitwise operators. Wrap the TX allocation in test_and_set_bit_lock() to establish formal LKMM Acquire semantics, and pair it with clear_bit_unlock() in the polling path to enforce Release semantics. Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260423-acpm-fixes-sashiko-reports-v1-0-2217b790925e%40linaro.org [1] Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-6-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

firmware: samsung: acpm: Fix false timeouts and Use-After-Free in polling

2026-06-27T10:07:38+00:00

[ Upstream commit c889b146478885344a220dd468e5a08de088cbc5 ] Sashiko identified severe races in the polling state machine [1]. In the ACPM driver's polling mode, threads waited for responses by monitoring the globally shared 'bitmap_seqnum'. This caused false timeouts because if a thread processed its response and freed the sequence number, a concurrent TX thread could immediately reallocate it before the polling thread woke up. Additionally, the driver suffered from a cross-thread Use-After-Free (UAF) preemption race. Previously, acpm_get_rx() cleared the sequence number of whichever RX message it drained from the hardware queue. This meant Thread A could globally free Thread B's sequence slot while Thread B was asleep. A new Thread C could then steal the slot, overwrite the buffer, and leave Thread B to wake up to corrupted state or a timeout. Fix this by rewriting the polling state machine: 1. Decouple polling from the global allocator by introducing a per-slot 'completed' flag, synchronized via smp_store_release() and smp_load_acquire(). 2. Strip acpm_get_saved_rx() out of acpm_get_rx() to make it a pure queue-draining function. Introduce a 'native_match' boolean argument which evaluates to true only if the thread natively processed its own sequence number during the call. This explicitly informs the polling loop whether it must retrieve its payload from the cross-thread cache. 3. Centralize the cache fallback and sequence number free (clear_bit) inside the polling loop. Crucially, the free operation now strictly targets the thread's own TX sequence number (xfer->txd[0]), rather than the drained RX sequence number. This enforces strict ownership: a thread only ever frees its own allocated sequence slot, and only at the exact moment it completes its poll, eliminating the UAF window. Furthermore, explicitly guard the 'native_match' assignment with an if (rx_seqnum == tx_seqnum) check, even for zero-length (no payload) responses. While an unguarded assignment wouldn't crash (because the cache fallback acpm_get_saved_rx() safely returns early on zero-length transfers) doing so would "lie" to the state machine. If a thread drained the queue and found another thread's zero-length message, setting native_match = true would falsely convince the polling loop that it natively handled its own response. Maintaining a rigorous state machine requires that native_match is only set when a thread explicitly processes its own sequence number. Cc: stable@vger.kernel.org Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Closes: https://sashiko.dev/#/patchset/20260429-acpm-fixes-sashiko-reports-v3-0-47cf74ab09ad%40linaro.org [1] Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-5-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

firmware: samsung: acpm: Fix cross-thread RX length corruption

2026-06-27T10:07:38+00:00

[ Upstream commit f133bd4b5daf71bccdde0ad1a4f47fac76a6bfb1 ] Sashiko identified a cross-thread RX length corruption bug when reviewing the thermal addition to ACPM [1]. When multiple threads concurrently send IPC requests, the ACPM polling mechanism can encounter responses belonging to other threads. To drain the queue, the driver saves these concurrent responses into an internal cache (`rx_data->cmd`) to be retrieved later by the owning thread. Previously, the driver incorrectly used `xfer->rxcnt` (the expected receive length of the *current* polling thread) when copying data for *other* threads into this cache. If the threads expected responses of different lengths, this resulted in buffer underflows (leading to reads of uninitialized memory) or potential buffer overflows. Fix this by replacing the boolean `response` flag in `struct acpm_rx_data` with `rxcnt`, caching the exact expected receive length for each specific transaction during transfer preparation. Use this cached length when saving concurrent responses. Consequently, ensure that `xfer->rxcnt` is explicitly zeroed in driver helpers (e.g., `acpm_dvfs_set_xfer`) for fire-and-forget messages to prevent uninitialized stack garbage from being interpreted as a massive expected receive length. 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] Reported-by: Titouan Ameline de Cadeville Closes: https://lore.kernel.org/r/20260426210255.73674-1-titouan.ameline@gmail.com/ Signed-off-by: Tudor Ambarus Link: https://patch.msgid.link/20260505-acpm-fixes-sashiko-reports-v5-1-43b5ee7f1674@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

firmware: exynos-acpm: Count acpm_xfer buffers with __counted_by_ptr

2026-06-27T10:07:38+00:00

[ Upstream commit 951b8eee0581bbf39e7b0464d679eee8cb9da3e0 ] Use __counted_by_ptr() attribute on the acpm_xfer buffers so UBSAN will validate runtime that we do not pass over the buffer size, thus making code safer. Usage of __counted_by_ptr() (or actually __counted_by()) requires that counter is initialized before counted array. Tested-by: Tudor Ambarus Reviewed-by: Tudor Ambarus Signed-off-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20260219-firmare-acpm-counted-v2-3-e1f7389237d3@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski Stable-dep-of: f133bd4b5daf ("firmware: samsung: acpm: Fix cross-thread RX length corruption") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

firmware: exynos-acpm: Count number of commands in acpm_xfer

2026-06-27T10:07:38+00:00

[ Upstream commit 00808ae2e679a97dccc5cf0ee4474ba1e2e8a21a ] Struct acpm_xfer holds two buffers with u32 commands - rxd and txd - and counts their size by rxlen and txlen. "len" suffix is here ambiguous, so could mean length of the buffer or length of commands, and these are not the same since each command is u32. Rename these to rxcnt and txcnt, and change their usage to count the number of commands in each buffer. This will have a benefit of allowing to use __counted_by_ptr later. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Tudor Ambarus Link: https://patch.msgid.link/20260219-firmare-acpm-counted-v2-2-e1f7389237d3@oss.qualcomm.com Signed-off-by: Krzysztof Kozlowski Stable-dep-of: f133bd4b5daf ("firmware: samsung: acpm: Fix cross-thread RX length corruption") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

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