fastrpc: fix use-after-free in close_domain_session during session teardown

[Jianping (Jianping-Li)]

close_domain_session() iterated over the per-domain handle lists (nql, rql and ql) using QLIST_NEXTSAFE_FOR_ALL, which caches the next node (pnn) up front. Inside the loop body the list mutex is dropped to issue the remote close:

pthread_mutex_unlock(&hlist[domain].lmut);
remote_handle64_close(hi->local);
pthread_mutex_lock(&hlist[domain].lmut);

NEXTSAFE only guarantees that freeing the current node (pn) is safe; it does not protect the cached next node (pnn) across the unlock window. While the lock is dropped, the cascaded cleanup inside the remote close path and the concurrently exiting listener thread can unlink and free the node pnn points to. On the next iteration pn = pnn dereferences a dangling pointer, leading to a use-after-free crash:

close_domain_session
remote_session_control (req=7, FASTRPC_SESSION_CLOSE)
Program terminated with signal SIGSEGV
pnn = 0xaaa1b7150f3d   /* poisoned next pointer */

This only reproduces on targets that support status notifications: the FASTRPC_SESSION_CLOSE path in the test app is gated by status_notif_capability, so targets without notification support never enter close_domain_session and are unaffected.

Replace the NEXTSAFE traversal with a pop-based loop that re-reads the list head under the lock on every iteration and unlinks the node with QList_Pop before dropping the mutex. The node is off the list before the remote close runs, so neither the close cascade nor the listener thread can free a node we still reference, eliminating the dangling next pointer. Apply the same fix to all three lists (nql, rql, ql).

[github-actions]

qualcomm/fastrpc.triage This pull request has been marked as stale due to 30 days of inactivity.