queue_new(): if calloc fails, abort (CID #57918)

Coverity complains about a 'Dereference before null check' on *queue.
So, push the NULL check further up, but also, instead of handling a calloc
failure as error, rather abort the program.
---
 gtp/queue.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

Hi Neels

On Thu, Apr 14, 2016 at 04:38:42PM +0200, Neels Hofmeyr wrote:
> Coverity complains about a 'Dereference before null check' on *queue.
> So, push the NULL check further up, 

No question here.

> but also, instead of handling a calloc failure as error, rather abort
> the program.

I think that's a much more fundamental question.  Should we really abort
the program in this case?  If so, why only in case of queue allocation
failures, but not in general at all memory allocation failures?  And if
that's the case, wrapping calloc() / malloc() and other dynamic memory
allocation calls with a function that contains the abort() (or an
OSMO_ASSERT() on the result) might be more applicable?

On Sat, Apr 16, 2016 at 01:37:41PM +0200, Harald Welte wrote:
> Hi Neels
> 
> On Thu, Apr 14, 2016 at 04:38:42PM +0200, Neels Hofmeyr wrote:
> > Coverity complains about a 'Dereference before null check' on *queue.
> > So, push the NULL check further up, 
> 
> No question here.
> 
> > but also, instead of handling a calloc failure as error, rather abort
> > the program.
> 
> I think that's a much more fundamental question.  Should we really abort
> the program in this case?

In an in-person discussion with Holger on some other code way back some day, he
recommended to abort() on allocation failure. Might not be applicable here, of
course.

> If so, why only in case of queue allocation
> failures, but not in general at all memory allocation failures?  And if
> that's the case, wrapping calloc() / malloc() and other dynamic memory
> allocation calls with a function that contains the abort() (or an
> OSMO_ASSERT() on the result) might be more applicable?

Yes, I would agree with that.

(BTW, the only reason I didn't OSMO_ASSERT() was that there is no other use of
OSMO_ASSERT() anywhere else in OpenGGSN.)

How should we handle this, I'd prefer not to spend time on that now. Commit the
patch with `return EOF' instead of abort()ing, as the old code suggests? I
don't know about that, EOF doesn't seem applicable at all.

~Neels

> On 18 Apr 2016, at 12:56, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote:
> 
> 
> (BTW, the only reason I didn't OSMO_ASSERT() was that there is no other use of
> OSMO_ASSERT() anywhere else in OpenGGSN.)

the GGSN has not used libosmocore before, so there will be many firsts.

> 
> How should we handle this, I'd prefer not to spend time on that now. Commit the
> patch with `return EOF' instead of abort()ing, as the old code suggests? I
> don't know about that, EOF doesn't seem applicable at all.

return EOF then. For commit messages we used to put "Fixes: CID#1234" at the bottom of the commit message.

kind regards
	holger

On Fri, Apr 22, 2016 at 03:39:20PM +0200, Holger Freyther wrote:
> return EOF then. For commit messages we used to put "Fixes: CID#1234" at the bottom of the commit message.

submitting a new patch with subject "queue_new(): fix NULL dereference on allocation failure"

~Neels