Coverity: can_rx_offload_irq_offload_timestamp(): Resource leaks

Coverity: can_rx_offload_irq_offload_timestamp(): Resource leaks

[coverity-bot]

Hello!

This is an experimental automated report about issues detected by Coverity
from a scan of next-20191108 as part of the linux-next weekly scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan

You're getting this email because you were associated with the identified
lines of code (noted below) that were touched by recent commits:

c2a9f74c9d18 ("can: rx-offload: can_rx_offload_irq_offload_timestamp(): continue on error")

Coverity reported the following:

*** CID 1487846:  Resource leaks  (RESOURCE_LEAK)
/drivers/net/can/rx-offload.c: 219 in can_rx_offload_irq_offload_timestamp()
213
214     		if (!(pending & BIT_ULL(i)))
215     			continue;
216
217     		skb = can_rx_offload_offload_one(offload, i);
218     		if (IS_ERR_OR_NULL(skb))
vvv     CID 1487846:  Resource leaks  (RESOURCE_LEAK)
vvv     Variable "skb" going out of scope leaks the storage it points to.
219     			continue;
220
221     		__skb_queue_add_sort(&skb_queue, skb, can_rx_offload_compare);
222     	}
223
224     	if (!skb_queue_empty(&skb_queue)) {

If this is a false positive, please let us know so we can mark it as
such, or teach the Coverity rules to be smarter. If not, please make
sure fixes get into linux-next. :) For patches fixing this, please
include these lines (but double-check the "Fixes" first):

Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
Addresses-Coverity-ID: 1487846 ("Resource leaks")
Fixes: c2a9f74c9d18 ("can: rx-offload: can_rx_offload_irq_offload_timestamp(): continue on error")


Thanks for your attention!

-- 
Coverity-bot

Re: Coverity: can_rx_offload_irq_offload_timestamp(): Resource leaks

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 2162 bytes --]

On 11/12/19 2:35 AM, coverity-bot wrote:
> Hello!
> 
> This is an experimental automated report about issues detected by Coverity
> from a scan of next-20191108 as part of the linux-next weekly scan project:
> https://scan.coverity.com/projects/linux-next-weekly-scan
> 
> You're getting this email because you were associated with the identified
> lines of code (noted below) that were touched by recent commits:
> 
> c2a9f74c9d18 ("can: rx-offload: can_rx_offload_irq_offload_timestamp(): continue on error")
> 
> Coverity reported the following:
> 
> *** CID 1487846:  Resource leaks  (RESOURCE_LEAK)
> /drivers/net/can/rx-offload.c: 219 in can_rx_offload_irq_offload_timestamp()
> 213
> 214     		if (!(pending & BIT_ULL(i)))
> 215     			continue;
> 216
> 217     		skb = can_rx_offload_offload_one(offload, i);
> 218     		if (IS_ERR_OR_NULL(skb))
> vvv     CID 1487846:  Resource leaks  (RESOURCE_LEAK)
> vvv     Variable "skb" going out of scope leaks the storage it points to.
> 219     			continue;
> 220
> 221     		__skb_queue_add_sort(&skb_queue, skb, can_rx_offload_compare);
> 222     	}
> 223
> 224     	if (!skb_queue_empty(&skb_queue)) {
> 
> If this is a false positive, please let us know so we can mark it as
> such, or teach the Coverity rules to be smarter. If not, please make
> sure fixes get into linux-next. :) For patches fixing this, please
> include these lines (but double-check the "Fixes" first):
> 
> Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
> Addresses-Coverity-ID: 1487846 ("Resource leaks")
> Fixes: c2a9f74c9d18 ("can: rx-offload: can_rx_offload_irq_offload_timestamp(): continue on error")

This is a false positive:

>> 218     		if (IS_ERR_OR_NULL(skb))
>> 219     			continue;

since skb is either NULL or an error pointer not a pointer to a valid
skb object.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Coverity: can_rx_offload_irq_offload_timestamp(): Resource leaks

[Kees Cook]

On Tue, Nov 12, 2019 at 09:09:13AM +0100, Marc Kleine-Budde wrote:
> On 11/12/19 2:35 AM, coverity-bot wrote:
> > Hello!
> > 
> > This is an experimental automated report about issues detected by Coverity
> > from a scan of next-20191108 as part of the linux-next weekly scan project:
> > https://scan.coverity.com/projects/linux-next-weekly-scan
> > 
> > You're getting this email because you were associated with the identified
> > lines of code (noted below) that were touched by recent commits:
> > 
> > c2a9f74c9d18 ("can: rx-offload: can_rx_offload_irq_offload_timestamp(): continue on error")
> > 
> > Coverity reported the following:
> > 
> > *** CID 1487846:  Resource leaks  (RESOURCE_LEAK)
> > /drivers/net/can/rx-offload.c: 219 in can_rx_offload_irq_offload_timestamp()
> > 213
> > 214     		if (!(pending & BIT_ULL(i)))
> > 215     			continue;
> > 216
> > 217     		skb = can_rx_offload_offload_one(offload, i);
> > 218     		if (IS_ERR_OR_NULL(skb))
> > vvv     CID 1487846:  Resource leaks  (RESOURCE_LEAK)
> > vvv     Variable "skb" going out of scope leaks the storage it points to.
> > 219     			continue;
> > 220
> > 221     		__skb_queue_add_sort(&skb_queue, skb, can_rx_offload_compare);
> > 222     	}
> > 223
> > 224     	if (!skb_queue_empty(&skb_queue)) {
> > 
> > If this is a false positive, please let us know so we can mark it as
> > such, or teach the Coverity rules to be smarter. If not, please make
> > sure fixes get into linux-next. :) For patches fixing this, please
> > include these lines (but double-check the "Fixes" first):
> > 
> > Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
> > Addresses-Coverity-ID: 1487846 ("Resource leaks")
> > Fixes: c2a9f74c9d18 ("can: rx-offload: can_rx_offload_irq_offload_timestamp(): continue on error")
> 
> This is a false positive:
> 
> >> 218     		if (IS_ERR_OR_NULL(skb))
> >> 219     			continue;
> 
> since skb is either NULL or an error pointer not a pointer to a valid
> skb object.

Wow, yes, that certainly is! :) I will see if can find a way to teach
Coverity that the ERR span of "pointer" values do not count as
"allocated".

Thanks for taking a look at this!

-- 
Kees Cook