It is currently uint16_t for no good reason. We just hit the first bug caused by overrunning it (in iFC).
rdar://86602114
Created attachment 450153 [details] Patch
I went conservative in size but going with 32-bit is quite reasonable given we also do that in RefCounted.
Committed r288700 (246498@main): <https://commits.webkit.org/246498@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 450153 [details].
(In reply to Ryosuke Niwa from comment #3) > I went conservative in size but going with 32-bit is quite reasonable given > we also do that in RefCounted. An alternative would have been to just remove ASSERT(m_count) from decrement.
(In reply to Antti Koivisto from comment #5) > (In reply to Ryosuke Niwa from comment #3) > > I went conservative in size but going with 32-bit is quite reasonable given > > we also do that in RefCounted. > > An alternative would have been to just remove ASSERT(m_count) from decrement. I don't think that would have been quite safe. If m_count had overflowed, then it's also possible for m_count to become 0 every 2^16 decrements and bypass CanMakeCheckedPtrBase::~CanMakeCheckedPtrBase's release assert even when there are outstanding CheckedPtr or CheckedRef to it. If the creation of CanMakeCheckedPtr objects can be influenced by scripts, it's possible for a malicious web page to control how many decrements would happen to m_count to bypass the release assert, thereby triggering UAF down the line.
Right, that's why I thought this was a better approach. Overrunning 32 bits by allocating CheckedPtrs is probably not possible in practice.
(In reply to Antti Koivisto from comment #7) > Right, that's why I thought this was a better approach. Overrunning 32 bits > by allocating CheckedPtrs is probably not possible in practice. Right.