FROMLIST: misc: fastrpc: fix UAF and kernel panic during cleanup on process abort#1032
Open
Jianping-Li wants to merge 5 commits intoqualcomm-linux:tech/mm/fastrpcfrom
Open
FROMLIST: misc: fastrpc: fix UAF and kernel panic during cleanup on process abort#1032Jianping-Li wants to merge 5 commits intoqualcomm-linux:tech/mm/fastrpcfrom
Jianping-Li wants to merge 5 commits intoqualcomm-linux:tech/mm/fastrpcfrom
Conversation
…emory pool The initial buffer allocated for the Audio PD memory pool is never added to the pool because pageslen is set to 0. As a result, the buffer is not registered with Audio PD and is never used, causing a memory leak. Audio PD immediately falls back to allocating memory from the remote heap since the pool starts out empty. Fix this by setting pageslen to 1 so that the initially allocated buffer is correctly registered and becomes part of the Audio PD memory pool. Link: https://lore.kernel.org/all/20260409062617.1182-2-jianping.li@oss.qualcomm.com/ Fixes: 0871561 ("misc: fastrpc: Add support for audiopd") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
…tion fastrpc_req_munmap_impl() is called to unmap any buffer. The buffer is getting removed from the list after it is unmapped from DSP. This can create potential race conditions if any other thread removes the entry from list while unmap operation is ongoing. Remove the entry before calling unmap operation. Link: https://lore.kernel.org/all/20260409062617.1182-3-jianping.li@oss.qualcomm.com/ Fixes: 2419e55 ("misc: fastrpc: add mmap/unmap support") Cc: stable@kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
… in probe Allocating and freeing Audio PD memory from userspace is unsafe because the kernel cannot reliably determine when the DSP has finished using the memory. Userspace may free buffers while they are still in use by the DSP, and remote free requests cannot be safely trusted. Allocate the entire Audio PD reserved-memory region upfront during rpmsg probe and tie its lifetime to the rpmsg channel. This avoids userspace- controlled alloc/free and ensures memory is reclaimed only when the DSP shuts down. Link: https://lore.kernel.org/all/20260409062617.1182-4-jianping.li@oss.qualcomm.com/ Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Make fastrpc_buf_free() a no-op when passed a NULL pointer, allowing callers to avoid open-coded NULL checks. Link: https://lore.kernel.org/all/20260409062617.1182-5-jianping.li@oss.qualcomm.com/ Co-developed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
qcomlnxci
requested review from
a team,
Chennak-quic and
ekanshibu
and removed request for
a team
…rocess abort When a userspace FastRPC client is abruptly terminated, FastRPC cleanup paths can race with device and session teardown. This results in kernel panics in different release paths: - fastrpc_release() when using remote heap, originating from fastrpc_buf_free() - fastrpc_device_release() when using system heap, originating from fastrpc_free_map() In addition, fastrpc_map_put() may trigger refcount use-after-free due to concurrent cleanup without proper synchronization. The root cause is that buffer and map cleanup paths may access map and buf resources after the associated device or session has already been released. Fix this by: - Introducing mutex protection for map and buf lifetime - Serializing buffer and map cleanup against device teardown - Skipping buffer and map operations when the device is already gone These changes ensure cleanup paths are safe against unexpected process aborts and prevent use-after-free and kernel panic scenarios. Link: https://lore.kernel.org/all/20260427105310.4056-1-jianping.li@oss.qualcomm.com/ Fixes: c68cfb7 ("misc: fastrpc: Add support for context Invoke method") Cc: stable@kernel.org Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
Jianping-Li
force-pushed
the
fearure/hamoa_race
branch
from
c421f93 to
e7213c4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a userspace FastRPC client is abruptly terminated, FastRPC cleanup paths can race with device and session teardown.
This results in kernel panics in different release paths:
In addition, fastrpc_map_put() may trigger refcount use-after-free due to concurrent cleanup without proper synchronization.
The root cause is that buffer and map cleanup paths may access map and buf resources after the associated device or session has already been released.
Fix this by:
These changes ensure cleanup paths are safe against unexpected process aborts and prevent use-after-free and kernel panic scenarios.
Link: https://lore.kernel.org/all/20260427105310.4056-1-jianping.li@oss.qualcomm.com/
Fixes: c68cfb7 ("misc: fastrpc: Add support for context Invoke method")
Cc: stable@kernel.org
CRs-Fixed: 4456370