diff options
| author | fabient <fabient@FreeBSD.org> | 2015-11-25 14:45:43 +0000 |
|---|---|---|
| committer | fabient <fabient@FreeBSD.org> | 2015-11-25 14:45:43 +0000 |
| commit | b02d40ddcda08b51a49e5667e6808f5dc5ec0472 (patch) | |
| tree | 34498588e0b12ad9d0d71fb53fa31bb31bf205f9 /lib/libc/stdlib/abs.c | |
| parent | c562eaf30bc2bbf7e4e7ca69b5f9410e847e2ef9 (diff) | |
| download | FreeBSD-src-b02d40ddcda08b51a49e5667e6808f5dc5ec0472.zip FreeBSD-src-b02d40ddcda08b51a49e5667e6808f5dc5ec0472.tar.gz | |
The r241129 description was wrong that the scenario is possible
only for read locks on pcbs. The same race can happen with write
lock semantics as well.
The race scenario:
- Two threads (1 and 2) locate pcb with writer semantics (INPLOOKUP_WLOCKPCB)
and do in_pcbref() on it.
- 1 and 2 both drop the inp hash lock.
- Another thread (3) grabs the inp hash lock. Then it runs in_pcbfree(),
which wlocks the pcb. They must happen faster than 1 or 2 come INP_WLOCK()!
- 1 and 2 congest in INP_WLOCK().
- 3 does in_pcbremlists(), drops hash lock, and runs in_pcbrele_wlocked(),
which doesn't free the pcb due to two references on it.
Then it unlocks the pcb.
- 1 (or 2) gets wlock on the pcb, runs in_pcbrele_wlocked(), which doesn't
report inp as freed, due to 2 (or 1) still helding extra reference on it.
The thread tries to do smth with a disconnected pcb and crashes.
Submitted by: emeric.poupon@stormshield.eu
Reviewed by: gleb@
MFC after: 1 week
Sponsored by: Stormshield
Tested by: Cassiano Peixoto, Stormshield
Diffstat (limited to 'lib/libc/stdlib/abs.c')
0 files changed, 0 insertions, 0 deletions
