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

@@ -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;