mirror of https://gerrit.osmocom.org/libosmocore
Vadim Yanitskiy
d76cc3704e
Coverity tells us that with the current logic it's possible (in theory) that we may dereference NULL pointer in osmo_soft_uart_flush_rx(). This is highly unlikely, because the Rx buffer gets allocated once when the Rx is enabled and remains even after the Rx gets disabled. The Rx flags cannot be anything than 0x00 before the Rx gets enabled. Even though this NULL pointer dereference is unlikely, the Rx flushing logic is still not entirely correct. As can be seen from the unit test output, the Rx callback of the application may be called with an empty msgb if the following conditions are both met: a) the osmo_soft_uart_flush_rx() is invoked manually, and b) a parity and/or a framing error has occurred previously. We should not be checking suart->rx.flags in osmo_soft_uart_flush_rx(), since this is already done in suart_rx_ch(), which is calling it. Removing this check also eliminates a theoretical possibility of the NULL pointer dereference, so we're killing two birds with one stone. - Do not check suart->rx.flags in osmo_soft_uart_flush_rx(). - Add a unit test for various flush()ing scenarios. Change-Id: I5179f5fd2361e4e96ac9bf48e80b99e53a7e4712 Fixes: CID#336545 |
||
|---|---|---|
| .. | ||
| codec | ||
| coding | ||
| core | ||
| ctrl | ||
| gb | ||
| gsm | ||
| isdn | ||
| pseudotalloc | ||
| sim | ||
| usb | ||
| vty | ||
| Makefile.am | ||