netdev - Re: [BUG] net: stmmac: Panic observed in stmmac_napi_poll

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 14 May 2021 23:49:27 +0200
From:   Michał Mirosław <mirq-linux@...e.qmqm.pl>
To:     Jon Hunter <jonathanh@...dia.com>
Cc:     Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        linux-tegra <linux-tegra@...r.kernel.org>,
        Thierry Reding <treding@...dia.com>
Subject: Re: [BUG] net: stmmac: Panic observed in stmmac_napi_poll_rx()

On Fri, May 14, 2021 at 03:24:58PM +0100, Jon Hunter wrote:
> Hello!
> 
> I have been looking into some random crashes that appear to stem from
> the stmmac_napi_poll_rx() function. There are two different panics I
> have observed which are ...
[...]
> The bug being triggered in skbuff.h is the following ...
> 
>  void *skb_pull(struct sk_buff *skb, unsigned int len);
>  static inline void *__skb_pull(struct sk_buff *skb, unsigned int len)
>  {
>          skb->len -= len;
>          BUG_ON(skb->len < skb->data_len);
>          return skb->data += len;
>  }
> 
> Looking into the above panic triggered in skbuff.h, when this occurs
> I have noticed that the value of skb->data_len is unusually large ...
> 
>  __skb_pull: len 1500 (14), data_len 4294967274
[...]

The big value looks suspiciously similar to (unsigned)-EINVAL.

> I then added some traces to stmmac_napi_poll_rx() and
> stmmac_rx_buf2_len() to trace the values of various various variables
> and when the problem occurs I see ...
> 
>  stmmac_napi_poll_rx: stmmac_rx: count 0, len 1518, buf1 66, buf2 1452
>  stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1518
>  stmmac_napi_poll_rx: stmmac_rx: count 1, len 1518, buf1 66, buf2 1452
>  stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 66, plen 1536
>  stmmac_napi_poll_rx: stmmac_rx: count 2, len 1602, buf1 66, buf2 1536
>  stmmac_napi_poll_rx: stmmac_rx_buf2_len: len 1602, plen 1518
>  stmmac_napi_poll_rx: stmmac_rx: count 2, len 1518, buf1 0, buf2 4294967212
>  stmmac_napi_poll_rx: stmmac_rx: dma_buf_sz 1536, buf1 0, buf2 4294967212

And this one to (unsigned)-EILSEQ.

> Note I added the above BUG_ON to trap unusually large buffers. Let
> me know if you have any thoughts.

Do above ring any bell?

Best Regards
Michał Mirosław