This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/10352] New: no protection against using fd_set with fd>1024
- From: "kees at outflux dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 30 Jun 2009 20:06:25 -0000
- Subject: [Bug libc/10352] New: no protection against using fd_set with fd>1024
- Reply-to: sourceware-bugzilla at sourceware dot org
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.