Bug #3592
openrtl: Race Conditions
0%
Description
There appear to be a handful of race conditions in the rtl library.
1. _running is set false without a lock right before _buf_cond is notified; see http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n326
_buf_cond is never notified again, so on this line http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n343
there could be an infinite hang. _running is checked inside a lock, and then _buf_cond waited on. If _running is set false in between those statements, the wait will never return.
I've attempted to fix this in http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001835.html . The patch also locks around _buf_used, which is recommended in the face of unknown compiler optimizations and target platforms by https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf .
2. There is no lock shared between the write to the sample buffer at http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n304 and the read from it at http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n352 . When the overflow condition is hit, the buffer pointers will wrap, and corrupt data will be produced.
My approach to fixing this was to change how overflows are handled entirely in http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001832.html