yxscc opened a new issue, #812:
URL: https://github.com/apache/celix/issues/812
## Summary
In RSA SHM transport, when a client RPC times out or errors, the client
exception handler frees the shared `msgCtrl` and `msgBuffer`, but the server
thread may still be processing the same request and will lock/write to these
freed blocks → reproducible UAF/heap corruption.
## Component
- Files:
-
`bundles/remote_services/remote_service_admin_shm_v2/rsa_shm/src/rsa_shm_client.c`
(exception cleanup)
-
`bundles/remote_services/remote_service_admin_shm_v2/rsa_shm/src/rsa_shm_server.c`
(worker uses freed memory)
- Affected APIs: RSA SHM client/server message handling (not deprecated).
## Root Cause
- Client side: on timeout/unreplied request,
`rsaShmClientManager_receiveResponse` enqueues `exceptionMsg`, and
`rsaShmClientManager_exceptionMsgHandlerThread` later sets `msgState` to cancel
and frees both `msgBuffer` and `msgCtrl` without coordinating with the server.
- Server side: `rsaShmServer_msgHandlingWork` continues to
`pthread_mutex_lock(msgCtrl->lock)`, `memcpy` reply into `msgBuffer`, and
signals the same `msgCtrl`, assuming the shared memory is valid.
- There is no lifetime handshake or refcount between client timeout/cancel
and server completion; shared memory can be freed while still in use by the
server thread.
### Key code excerpts
```
340:371:bundles/remote_services/remote_service_admin_shm_v2/rsa_shm/src/rsa_shm_client.c
// on timeout, enqueue exception; later freed by handler
rsa_shm_exception_msg_t *exceptionMsg = malloc(...);
exceptionMsg->msgCtrl =
(rsa_shm_msg_control_t*)celix_steal_ptr(msgCtrlAlloc.ctrl);
exceptionMsg->msgBuffer = celix_steal_ptr(msgBodyAlloc.ptr);
celixThreadMutex_lock(&clientManager->exceptionMsgListMutex);
celix_arrayList_add(clientManager->exceptionMsgList, exceptionMsg);
celixThreadMutex_unlock(&clientManager->exceptionMsgListMutex);
600:614:bundles/remote_services/remote_service_admin_shm_v2/rsa_shm/src/rsa_shm_client.c
// exception handler frees shared memory
celix_arrayList_remove(clientManager->exceptionMsgList, exceptionMsg);
shmPool_free(clientManager->shmPool, exceptionMsg->msgBuffer);
rsa_shm_msg_control_alloc_t controlAlloc = {.ctrl = exceptionMsg->msgCtrl,
...};
rsaShmClientManager_destroyMsgControl(&controlAlloc);
```
```
198:234:bundles/remote_services/remote_service_admin_shm_v2/rsa_shm/src/rsa_shm_server.c
// server continues to use msgCtrl/msgBuffer
pthread_mutex_lock(&msgCtrl->lock);
...
memcpy(dest, src, bytes);
msgCtrl->msgState = REPLIED;
pthread_cond_signal(&msgCtrl->signal);
pthread_mutex_unlock(&msgCtrl->lock);
...
shmCache_releaseMemoryPtr(server->shmCache, msgBuffer);
shmCache_releaseMemoryPtr(server->shmCache, msgCtrl);
```
## Reproduction
1) Build the PoC (mirrors the real lifecycle) added at
`targets/celix/poc/rsa_shm_uaf_poc.c`:
```bash
cd /home/ConCord/targets/celix && gcc -pthread poc/rsa_shm_uaf_poc.c -o
poc/rsa_shm_uaf_poc
```
2) Run under Valgrind:
```bash
valgrind --error-exitcode=1
/home/ConCord/targets/celix/poc/rsa_shm_uaf_poc
```
3) Observed errors (trimmed):
- `Invalid read ... pthread_mutex_lock` on freed `msgCtrl`
- `Invalid write ... memset` on freed `msgBuffer`
- Additional UAF on `pthread_cond_signal` / `pthread_mutex_unlock`
The PoC reproduces the same lifecycle: client times out → frees shared
ctrl/buffer → server thread later locks/writes → UAF.
## Impact
- Remote crash of RSA SHM server worker threads.
- Potential memory corruption (server writes into freed/reused SHM).
- A malicious or slow server/client interaction can trigger this without
special privileges.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
