[PATCH 1/5] __fdelt_chk: Removed range check

[Florian Weimer]

On 05/06/2013 01:13 AM, Allan McRae wrote:
> Is there a simple way to check which software will crash with this
> change?  That way we can assess what is the probability thing will
> crash?  Perhaps that will give us an idea what the probability third
> party software will be affected?

If you get a crash in third-party software, it is actually a pretty good 
indication that the third-party software needs fixing, presumably 
switching it over to poll (or epoll in extreme cases).  What happens is 
that it passed a file descriptor beyond 1023 to select and its support 
macros, without increasing FD_SETSIZE.

Reverting the checks in glibc will not fix these programs.  The failure 
will just be less deterministic, as before, ranging from random crashes 
(or worse) to a degradation from polling to busy waiting at 100% CPU 
usage.  Therefore, examining crashes in this area is definitely useful.

There is another set of programs which uses questionable techniques to 
implement large fd_sets, without redefining FD_SETSIZE or supplying 
their own fd_set macros.  These programs are broken by the glibc check, 
and they worked reliable before (but they just were not portable).  But 
I believe that these crashes are in the minority, compared to the real 
problems that are uncovered.

That's why I think we should have these checks as part of 
_FORTIFY_SOURCE.  A way to opt out may make sense.  But the future 
really is poll/epoll.  (For a fixed number of descriptors, poll is 
actually easier to use than select.)

-- 
Florian Weimer / Red Hat Product Security Team