fix: Use Correct ptr Type to Avoid UAF

[whoisj]

This change changes the managed pointer type used to manage the lifecyle of the stub instance from unique to shared. This avoids the dereference of the oft used unique pointer reference after the unique pointer has been free / deallocated.

CI Pipeline ID: 46362355

[yinggeh]

Copyrights

[whoisj]

Copyrights

Good catch, thanks. Fixed up.

[mrpre]

@whoisj
Hi, can you confirm whether this patch is intended to fix the following crash pattern?

In our old python_backend version, Stub::GetOrCreateInstance() returns std::unique_ptr&. The main thread runs stub->RunCommand(), while the background health thread captures
&stub and calls stub.reset() when the parent process is detected dead.

Our core shows:

Thread 1:
__new_sem_wait_slow
-> Stub::PopMessage()
-> Stub::RunCommand()

The faulting instruction is lock add QWORD PTR [rbx], rax, with rbx == si_addr, si_code == SEGV_MAPERR. The address is the semaphore inside the shared memory message queue.

Another thread:

main::{lambda()#1}
-> Stub::~Stub()
-> SharedMemoryManager::~SharedMemoryManager()

So it looks like the health thread destroys Stub/SharedMemoryManager and unmaps shm while the main thread is still blocked in sem_wait on mq_shm_ptr_->sem_full.

Does this commit’s change from unique_ptr& to shared_ptr by value cover this exact use-after-free / use-after-unmap scenario?