14 Apr
2016
14 Apr
'16
2:38 p.m.
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(-)
diff --git a/gtp/queue.c b/gtp/queue.c
index 7c971b0..707b522 100644
--- a/gtp/queue.c
+++ b/gtp/queue.c
@@ -127,16 +127,15 @@ int queue_new(struct queue_t **queue)
if (QUEUE_DEBUG)
printf("queue_new\n");
*queue = calloc(1, sizeof(struct queue_t));
+ if (!(*queue))
+ abort();
(*queue)->next = 0;
(*queue)->first = -1;
(*queue)->last = -1;
if (QUEUE_DEBUG)
queue_print(*queue);
- if (*queue)
- return 0;
- else
- return EOF;
+ return 0;
}
/*! \brief Deallocates queue structure */
--
2.1.4
16 Apr
16 Apr
11:37 a.m.
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?
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
18 Apr
18 Apr
10:56 a.m.
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:
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.
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?
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
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
22 Apr
22 Apr
1:39 p.m.
On 18 Apr 2016, at 12:56, Neels Hofmeyr
<nhofmeyr(a)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
25 Apr
25 Apr
11:01 a.m.
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
2984
days inactive
2995
days old
4 comments
3 participants
participants (3)
-
Harald Welte -
Holger Freyther -
Neels Hofmeyr