aio-libs / multidict / 34942494927

87%

push

github

Fix a use-after-free race in the free-threaded lock-free read path (#1461)

## What do these changes do?

`_md_drain_retired()` decided a retired hash table was safe to free
based only on a coarse "no lock-free reader in flight" counter reading
zero, then asserted that the table's own, per-table reader count was
also zero and freed it regardless of the assert's outcome. Reproduced
locally (matching the ThreadSanitizer CI job's intermittent crash in
`test_setitem_update_thread_safety` exactly, same stack trace and
assert) that the coarse counter reaching zero does not reliably mean
every reader that incremented it has also reached its own per-table
exit: a reader can be preempted for a while after incrementing a
table's reader count and before decrementing it, with nothing bounding
that window relative to the coarse check. In a release build the
assert compiles out and the table is freed while still being read, a
genuine use-after-free.

The fix makes freeing decisions per table: a table whose own reader
count is still nonzero is pushed back onto the retired list instead of
freed, to be retried the next time a reader exits or a writer retires
another table.

## Are there changes in behavior for the user?

No.

## Is it a substantial burden for the maintainers to support this?

No, it is a self-contained fix to the existing retirement scheme with
no new API surface.

## Related issue number

No linked issue; found while investigating an intermittent
ThreadSanitizer CI crash on an unrelated PR.

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [x] Documentation reflects the changes
- [ ] If you provide code modification, please add yourself to
`CONTRIBUTORS.txt`
- [x] Add a new news fragment into the `CHANGES/` folder
- [x] `make doc-spelling` passes and any new technical words are added
to `docs/spelling_wordlist.txt`

<details>
<summary>Agent run details (optional, for reviewers)</summary>

Reproduced the or... (continued)

747 of 1494 branches covered (50.0%)

Branch coverage included in aggregate %.

22 of 22 new or added lines in 1 file covered. (100.0%)

6155 of 6422 relevant lines covered (95.84%)

1.92 hits per line