netdev - Re: [PATCH] rtl8187: fix use after free on failure path in rtl8187_init

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] [day] [month] [year] [list]

Message-ID: <52240EA9.7010207@ispras.ru>
Date:	Mon, 02 Sep 2013 07:06:01 +0300
From:	Alexey Khoroshilov <khoroshilov@...ras.ru>
To:	htl10@...rs.sourceforge.net
CC:	larry.finger@...inger.net, linville@...driver.com,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, ldv-project@...uxtesting.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] rtl8187: fix use after free on failure path in rtl8187_init_urbs()

On 01.09.2013 10:51, Hin-Tak Leung wrote:
> ------------------------------
> On Sat, Aug 31, 2013 22:18 BST Alexey Khoroshilov wrote:
>
>> In case of __dev_alloc_skb() failure rtl8187_init_urbs()
>> calls usb_free_urb(entry) where 'entry' can points to urb
>> allocated at the previous iteration. That means refcnt will be
>> decremented incorrectly and the urb can be used after memory
>> deallocation.
>>
>> The patch fixes the issue and implements error handling of init_urbs
>> in rtl8187_start().
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signed-off-by: Alexey Khoroshilov <khoroshilov@...ras.ru>
>> ---
>> drivers/net/wireless/rtl818x/rtl8187/dev.c | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> index f49220e..e83d53c 100644
>> --- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> +++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> @@ -438,17 +438,16 @@ static int rtl8187_init_urbs(struct ieee80211_hw *dev)
>>          skb_queue_tail(&priv->rx_queue, skb);
>>          usb_anchor_urb(entry, &priv->anchored);
>>          ret = usb_submit_urb(entry, GFP_KERNEL);
>> +        usb_free_urb(entry);
>>          if (ret) {
>>              skb_unlink(skb, &priv->rx_queue);
>>              usb_unanchor_urb(entry);
>>              goto err;
>>          }
>> -        usb_free_urb(entry);
>>      }
>>      return ret;
>>
>> err:
>> -    usb_free_urb(entry);
>>      kfree_skb(skb);
>>      usb_kill_anchored_urbs(&priv->anchored);
>>      return ret;
> This part looks wrong - you free_urb(entry) then unanchor_urb(entry).
I do not see any problems here.
usb_free_urb() just decrements refcnt of the urb.
While usb_anchor_urb() and usb_unanchor_urb() increment and decrement it 
as well.
So actual memory deallocation will happen in usb_unanchor_urb().

>
>> @@ -956,8 +955,12 @@ static int rtl8187_start(struct ieee80211_hw *dev)
>>                    (RETRY_COUNT < 8  /* short retry limit */) |
>>                    (RETRY_COUNT < 0  /* long retry limit */) |
>>                    (7 < 21 /* MAX TX DMA */));
>> -        rtl8187_init_urbs(dev);
>> -        rtl8187b_init_status_urb(dev);
>> +        ret = rtl8187_init_urbs(dev);
>> +        if (ret)
>> +            goto rtl8187_start_exit;
>> +        ret = rtl8187b_init_status_urb(dev);
>> +        if (ret)
>> +            usb_kill_anchored_urbs(&priv->anchored);
>>          goto rtl8187_start_exit;
>>      }
>>
>> @@ -966,7 +969,9 @@ static int rtl8187_start(struct ieee80211_hw *dev)
>>      rtl818x_iowrite32(priv, &priv->map->MAR[0], ~0);
>>      rtl818x_iowrite32(priv, &priv->map->MAR[1], ~0);
>>
>> -    rtl8187_init_urbs(dev);
>> +    ret = rtl8187_init_urbs(dev);
>> +    if (ret)
>> +        goto rtl8187_start_exit;
>>
>>      reg = RTL818X_RX_CONF_ONLYERLPKT |
>>            RTL818X_RX_CONF_RX_AUTORESETPHY |
>> -- 
>> 1.8.1.2
>>
>
>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html