Re: Coverity: can_rx_offload_irq_offload_timestamp(): Resource leaks

[Kees Cook <keescook@chromium.org>]

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