netdev - Re: Null pointer dereference in tg3_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:   Tue, 28 Mar 2017 11:53:05 -0700
From:   Michael Chan <michael.chan@...adcom.com>
To:     Salam Noureddine <noureddine@...sta.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        "michael.chan@...adcom.com" <mchan@...adcom.com>,
        "prashant.sreedharan@...adcom.com" <prashant@...adcom.com>,
        Siva Reddy Kallam <siva.kallam@...adcom.com>
Subject: Re: Null pointer dereference in tg3_poll_work running linux-3.4

On Tue, Mar 28, 2017 at 11:32 AM, Salam Noureddine
<noureddine@...sta.com> wrote:
> Hi,
>
> We've seen a very rare kernel panic in tg3_poll_work on hardware
> running linux-3.4.
> I haven't seen any upstream patches that seem to fix this issue in the
> tg3 driver.
> The disassembly shows that the panic is happening in tg3_rx which is
> inlined into
> tg3_poll_work. In the code below, the "data" pointer seem to be Null,

The data pointer is derived from the opaque value in the receive
descriptor.  When the hardware completes a receive packet, the opaque
value is returned so that the driver can retrieve the proper entry in
the ring and locate the "data" pointer for the buffer.

I don't remember any bug fixes related to this logic.  One possibility
is that there is DMA corruption and we are getting a bad opaque value.
If you have the core dump, it will be useful to look at the receive
completion ring.   These opaque values are simple index values and
should be in sequence.