Subject: Re: brcmfmac: NULL pointer dereference during brcmf_detach() after
 firmware crash
To:     =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
        brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list@cypress.com
Cc:     Aaron Blair <aaron@aaronpb.me>
References: <b519e746-ddfd-421f-d897-7620d229e4b2@gmail.com>
From:   Arend Van Spriel <arend.vanspriel@broadcom.com>
Message-ID: <16ea722f-e08d-044f-216c-4ea745cc6344@broadcom.com>
Date:   Thu, 14 Feb 2019 23:36:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <b519e746-ddfd-421f-d897-7620d229e4b2@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On 2/14/2019 11:30 PM, Rafał Miłecki wrote:
> Hi,
> 
> I've just found a well reproducible brcmfmac crash (NULL pointer 
> dereference).
> 
> Steps:
> 1. Wait for or trigger a FullMAC firmware crash
> 2. Wait for some skb to get queued on a flowring
> 3. Call rmmod brcmfmac
> 
> Problem:
> There is a NULL pointer dereference in one of the brcmf_detach() calls.
> 
> Explanation:
> brcmf_detach() first frees all "ifp"s and then deletes flowrings. If any
> flowring has a skb it results in calling brcmf_txfinalize() which tries
> to access "ifp" (struct brcmf_if) which is a NULL.

Hi Rafał,

Thanks for diving in. That was my suspicion. Does it mean you are 
working on a patch or shall I take care of it.

Regards,
Arend