[MDEV-27476] heap-use-after-free in buf_pool_t::is_block_field() Created: 2022-01-12 Updated: 2022-02-21 Resolved: 2022-01-12 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.5.5, 10.6, 10.7, 10.8 |
| Fix Version/s: | 10.5.14, 10.6.6, 10.7.2, 10.8.1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Marko Mäkelä | Assignee: | Marko Mäkelä |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | ASAN, debug, rr-profile-analyzed | ||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
mleich found a race condition between buffer pool resizing and an update of the adaptive hash index, while testing
The function is being called as part of a debug assertion there, so this particular failure only affects debug builds. The culprit (found by setting a hardware watchpoint on the AddressSanitizer reported poison byte and executing reverse-continue in rr) is buffer pool resizing:
During the time of this, the thread that is going to fail is already executing that function:
Most invocations of buf_pool_t::is_uncompressed() are in debug assertions, and this faulty debug assertion was introduced in 10.6.
The calls to buf_pool.is_uncompressed() outside assertions seem to be protected correctly by buf_pool.page_hash latch. Those are in Block_hint::buffer_fix_block_if_still_valid() and buf_page_get_low(). The failing debug assertion was added in A similar assertion had been added to mtr_t::modify() already in This bug only affects debug builds during buffer pool resizing, possibly only when running with ASAN. |
| Comments |
| Comment by Matthias Leich [ 2022-01-12 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|