[tree] Fix TBasket out of bounds write of fEntryOffset#22797
Conversation
Following 15d2d71, fEntryOffset is (conditionally) allocated with a capacity of fNevBuf, i.e. the number of elements that are read into it. However, one code path in WriteBuffer() writes fEntryOffset up to one past the fNevBuf-th element, causing an OOB write. This was (usually) not happening prior to the aforementioned commit because fEntryOffset was allocated with a default capacity of 1000 (even though all elements past the fNevBuf-th were never initialized). To fix the OOB write, we now allocate one extra element when reading fEntryOffset from disk so that the WriteBuffer write is not OOB anymore.
|
thanks for these changes! Did the bug percolate to a released version? In that case I would suggest to open an issue, fix it with this PR and backport it. Otherwise, we can consider this a transient state in the main branch and be done with it... |
Test Results 23 files 23 suites 3d 17h 33m 6s ⏱️ For more details on these failures, see this check. Results for commit 78b0bc1. ♻️ This comment has been updated with latest results. |
The original PR was not backported but is scheduled to release with 6.40.04, so we should probably backport both that PR and this PR to 6.40 |
3 participants
Following 15d2d71, fEntryOffset is (conditionally) allocated with a capacity of fNevBuf, i.e. the number of elements that are read into it.
However, one code path in WriteBuffer() writes fEntryOffset up to one past the fNevBuf-th element, causing an OOB write.
This was (usually) not happening prior to the aforementioned commit because fEntryOffset was allocated with a default capacity of 1000 (even though all elements past the fNevBuf-th were never initialized).
To fix the OOB write, we now allocate one extra element when reading fEntryOffset from disk so that the WriteBuffer write is not OOB anymore.
Bug found by asan.