Stack smashing due to types length mismatch while calling BGET funcs (amd64 GNU/Linux platform)

[leszekgrzegorek]

For 64bit platform based on GNU/Linux (amd64) at least one type length mismatch between BGET <-> lobaro has been found causing stack smashing. The problem is that BGET originally is based on basic types e.g. int, long, etc. and lobaro uses fixed size ones, e.g. int32_t, etc. When BGET-functions return values via pointers to lobaro funcs. they (may) overwrite the stack on platforms where length mismatch occurs - e.g. for GNU/Linux amd64 long is 64bit vs. int32_t (as according to spec. long has to be at least 32bit).

The following example of affected code is related to nget, nrel variables (int32_t vs. long) :

void _rom coap_mem_stats()
{
	bufsize curalloc, totfree, maxfree;
	int32_t nget, nrel;

	bstats(&curalloc, &totfree, &maxfree, &nget, &nrel);

void _rom bstats(curalloc, totfree, maxfree, nget, nrel)
	bufsize *curalloc, *totfree, *maxfree;
	long *nget, *nrel;
{
	struct bfhead *b = freelist.ql.flink;

	*nget = numget;
	*nrel = numrel;

Of course mentioned issue does not occur when we compile it for 32bit - there no such mismatch occurs because long data type is 32bit.

I think that either BGET original implementation should be rewritten to use fixed size data types or at least some caution in README.md added that 64bit platforms may not be fully supported.

[niondir]

I would prefer to use free and malloc from the API struct in future to allow users to supply their own implementations e.g. from stdlib.
I'm just don't have the time to implement the refactoring at the moment.