188281 2018-08-02 15:35:26 -0700 JSLock::ownerThread seems racy 2019-01-20 14:50:33 -0800 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build Unspecified Unspecified NEW InRadar P2 Normal --- 1 saam saam ap benjamin fpizlo ggaren gskachkov jfbastien keith_miller mark.lam msaboff rmorisset ticaiolima webkit-bug-importer ysuzuki oldest_to_newest 1447414 0 saam 2018-08-02 15:35:26 -0700 Specifically, the race I'm worried about is: ``` m_ownerThread = ...; // set to non null value some time long ago. T1: VMTraps signal sender thread. T2: VM main execution thread. T1: tmp1 = m_ownerThread.m_ptr; T2: tmp2 = m_ownerThread.m_ptr; T2: m_ownerThread.m_ptr = nullptr; T2: tmp2->deref(); // ref count going from 1->0 T2: ~(tmp2); T1: tmp1->ref(); // UAF ``` Would be helpful if somebody else looked to see if there are errors in my logic here. 1447417 1 saam 2018-08-02 15:43:20 -0700 (In reply to Saam Barati from comment #0) > Specifically, the race I'm worried about is: > > ``` > m_ownerThread = ...; // set to non null value some time long ago. > T1: VMTraps signal sender thread. > T2: VM main execution thread. > > T1: tmp1 = m_ownerThread.m_ptr; > T2: tmp2 = m_ownerThread.m_ptr; > T2: m_ownerThread.m_ptr = nullptr; > T2: tmp2->deref(); // ref count going from 1->0 > T2: ~(tmp2); > T1: tmp1->ref(); // UAF > ``` > > Would be helpful if somebody else looked to see if there are errors in my > logic here. actually, it'd look somewhat different, since we never null out that pointer, we just assign new pointers in, but race still holds I think: ``` m_ownerThread = ...; // set to non null a long time ago T1: VMTraps signal sender thread. T2: VM main execution thread. T1: tmp1 = m_ownerThread.m_ptr; T2: tmp2 = m_ownerThread.m_ptr; T2: m_ownerThread.m_ptr = some other ptr; T2: tmp2->deref(); // ref count going from 1->0 T2: ~(tmp2); T1: tmp1->ref(); // UAF ``` 1496407 2 webkit-bug-importer 2019-01-20 14:50:33 -0800 <rdar://problem/47417563>