Jones: system call abuse

In SANE I fed just slightly unexpected values into the buffer size parameters, finding (as I expected given the mysterious crashes reported) that several backends wrongly assumed they would be asked for buffers that were at least a certain size, or were a multiple of some small integer like 4 even though the specification does not require this.

Last time I looked my test code still lives in the SANE command line tools, hopefully new driver authors are testing their code with it.

For LADSPA I wrote a tool named 'demolition' which sees what happens when legal but extraordinary values are fed into a LADSPA audio plugin, either as parameters or as audio data. It judges which values will be considered extraordinary in part by examining the plugin's built-in metadata. A compliant plugin should at worst run very slowly (and a watchdog timer moves on to the next test in this case) but often they crash or exhibit other undesirable behaviour.

sanitise.c -> get_interesting_value:
i = rand() & 20;
...
switch (i) {
case 0: return 0x00000001;
...
case 20: return 0xffffffffffffffff;

So I think that should have been rand() % 21...

sanitise.c -> get_address:
i = rand() % 2
...
switch (i) {
case 0: return KERNEL_ADDR;
...
case 2: return get_interesting_value();

So that probably should be rand() % 3

That's not to mention how horrible rand() is at actually being random, especially
in the lower two bits of output. Between those bugs it really reduces the number
of addresses that are tried. I notice that random() is used other places but
srandom() isn't ever called (though srand() is called twice).

I also wonder if address space randomization makes this less useful -- how
often does it fail to reproduce the same crash or misbehavior because memory
has shifted around?

I suppose I should send a patch instead of complaining.

-Ross