From b5934a2c332a13758f82c47e6b69c5771573588e Mon Sep 17 00:00:00 2001 From: Peter Putz Date: Wed, 11 Nov 2020 12:21:01 +0100 Subject: [PATCH] PPP: Fix null-deref when processing wrong packet This happens during quick reconnect of LTE ppp session. When processing an input packet containing only zero's, the pppos state machine assumes these are control fields, so doesn't allocate any pbuf for data. So if the `PPP_FLAG` comes (start of another valid packet) in this state and the `FCS` is valid (which is valid as long as only zero characters are being received) we de-reference `pppos->in_tail` in pppos.c:544. Picked from espressif/esp-lwip@537c69d5 Patch posted https://savannah.nongnu.org/patch/?10179 Ref IDF-4847 --- src/netif/ppp/pppos.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/netif/ppp/pppos.c b/src/netif/ppp/pppos.c index dff02554..78a8d271 100644 --- a/src/netif/ppp/pppos.c +++ b/src/netif/ppp/pppos.c @@ -531,6 +531,12 @@ pppos_input(ppp_pcb *ppp, u8_t *s, int l) /* Note: If you get lots of these, check for UART frame errors or try different baud rate */ LINK_STATS_INC(link.chkerr); pppos_input_drop(pppos); + } else if (!pppos->in_tail) { + PPPDEBUG(LOG_INFO, + ("pppos_input[%d]: Dropping null in_tail\n", + ppp->netif->num)); + LINK_STATS_INC(link.drop); + pppos_input_drop(pppos); /* Otherwise it's a good packet so pass it on. */ } else { struct pbuf *inp;