strace seg with select and -ve nfds
dvlasenk at redhat.com
Tue Nov 5 15:19:31 UTC 2013
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)" and "umoven(args)" below.
>> + * Instead of args, use nfds for fd count, fdsize for array lengths.
>> + */
>> and use nfds in those two places where we incorrectly use arg now.
>> 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:(
More information about the Strace-devel