netdev - Re: [PATCH] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv

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:   Sat, 3 Jun 2017 18:46:11 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Franky Lin <franky.lin@...adcom.com>
Cc:     "Peter S. Housel" <housel@....org>,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Kalle Valo <kvalo@...eaurora.org>,
        Christian Daudt <csd@...adcom.com>,
        Pieter-Paul Giesberts <pieter-paul.giesberts@...adcom.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" 
        <linux-wireless@...r.kernel.org>,
        "open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER" 
        <brcm80211-dev-list.pdl@...adcom.com>,
        "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain

On Fri, Jun 2, 2017 at 9:52 PM, Franky Lin <franky.lin@...adcom.com> wrote:
> On Fri, Jun 2, 2017 at 10:22 AM, Peter S. Housel <housel@....org> wrote:

>>                 err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
>>                                          glom_skb);
>> -               if (err) {
>> -                       brcmu_pkt_buf_free_skb(glom_skb);
>> -                       goto done;
>> -               }

> What about
>         if (!err) {
>             skb_queue_walk(pktq, skb) {
>                 memcpy(skb->data, glom_skb->data, skb->len);
>                 skb_pull(glom_skb, skb->len);
>             }
>         }
>         brcmu_pkt_buf_free_skb(glom_skb);
>
> Then no goto is needed.

For my point of view it has two subtle inconveniences:
1. Not so usual pattern in use if (!ret)
2. Less error prone in case someone decides to expand the code and
missed ! or something else there.

Since both makes an approach less error prone I wouldn't suggest doing
that as I commented in new version.

-- 
With Best Regards,
Andy Shevchenko