[Bug libc/10352] New: no protection against using fd_set with fd>1024

[kees at outflux dot net]

When a program using select() starts tracking file descriptors above 1024,
the fd_set vector (128 bytes) will overflow, writing to whatever is
beyond the vector, leading to stack/heap corruption.

This is a known, old, issue.  Examples:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1500
http://marc.info/?l=bugtraq&m=110660879328901

It is perfectly valid to use select() on a user-allocated vector that IS large
enough to handle the the fds being tracked, but it seems that glibc should take
some proactive measures to help applications that are not checking FD_SETSIZE.

It was pointed out that SSH, e.g. uses this to work around the issue:
fdset = (fd_set *)xcalloc(howmany(maxfd + 1, NFDBITS)

Some ideas could be to flag FD_ZERO as dangerous?  Or to check sizeof(...) on
select() inputs?

I would love to see a reasonable approach to protecting applications that aren't
prepared for RLIMIT_NOFILE to be >1024.  :)

Also being tracked here: https://bugs.launchpad.net/bugs/386558
Thanks!

-- 
           Summary: no protection against using fd_set with fd>1024
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: kees at outflux dot net
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10352

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.