strace seg with select and -ve nfds

[Denys Vlasenko]

On 11/05/2013 01:33 PM, Dr. David Alan Gilbert wrote:
> * Denys Vlasenko (dvlasenk at redhat.com) wrote:
>> I propose to do simply this:
>>
>> +       nfds = fdsize;
>>         fdsize = (((fdsize + 7) / 8) + sizeof(long)-1) & -sizeof(long);
>> +       /* We had bugs a-la "while (j < args[0])" and "umoven(args[0])" below.
>> +        * Instead of args[0], use nfds for fd count, fdsize for array lengths.
>> +        */
>>
>> and use nfds in those two places where we incorrectly use arg[0] now.
> 
>>> Thoughts?
>>
>> I applied a slightly simplified version of your fix to strace git, please try it.
> 
> That still fails (this is FORTIFY detecting the fail).

Please elaborate. You get a warning about access to fd_set->[__]fds_bits
array past its declared bounds? How it looks? Does strace abort or what?


> I can see two things potentially; the simple one is that the types are still
> wrong so that the -1 starts out as 2^32-1 and goes through the route of being
> corrected to be 1024*1024 rather than 0.

Okay, let's do this.

> However, the other thing I think is being caught here is that fortify is 
> catching FD_ISSET on a value greater than the size of the fd_set,
> so the added test below causes it to hit that failure - I guess the
> only solution there is not to use FD_ISSET or to cap at max-fds rather than
> the arbitrary 1024*1024 ?

There can be legitimate programs which use select() in excess of glibc-imposed
artificial limit on bit array sizes.

> (I guess you could argue that's a false positive from fortify, but there
> again I think it is an illegal use of FD_ISSET).

Do you see a reasonably portable way to check FD_ISSET?

On the related note, how are we doing in "stracing 32-bit app
with 64-bit strace on a big-endian machine" case?
In that case, sizeof(long) is important...
I dread to think about that:(

-- 
vda