[BusyBox] insmod with uClibc mystery bugs

[Erik Andersen]

On Tue Apr 24, 2001 at 12:48:33PM -0700, Larry Doolittle wrote:
> I scanned busybox insmod for memory allocation problems,
> in particular buffer underruns.  I didn't find any.
> Maybe Richard (or anyone else with insmod problems)
> could try again with dmalloc.
> 
> What happens in old_get_kernel_symbols if get_kernel_syms(NULL)
> returns zero?

Looks like we end up with an xmalloc(0).  uClibc doesn't like it when that
happens (SuS2 states that for malloc, "If size is 0, either a null pointer or a
unique pointer that can be successfully passed to free() will be returned.".
uClibc returns NULL here.  On the other hand, glibc seems to take the unique
pointer option.  

Regardless, ending up with an xmalloc(0) is sloppy.  I'll change 
insmod.c to do 'if (nks <= 0) ' instead to avoid the issue.

> In new_get_kernel_symbols, would it be worth checking for a
> double-fault on query_module?  Something like
> 	if (errno == ENOSPC && bufsize == 256) {

i.e. so we only pass the goto once?   Hmm.   I suppose there is a potential
race where an evil process might be insmoding a new module between sucessive
query_module() calls, which could keep up looping and reallocing memory
forever.  But realistically, eventually the xrealloc() would fail and we would
exit, or the evil process would stop insmoding, so then the next time around
the loop, query_module() would succeed.  So I think it should be safe as is.

> I did find some code that needed improvement, patch attached.

Thanks.  Applied.

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--