From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9627 invoked by alias); 30 Jun 2009 20:06:38 -0000 Received: (qmail 9583 invoked by uid 48); 30 Jun 2009 20:06:25 -0000 Date: Tue, 30 Jun 2009 20:06:00 -0000 From: "kees at outflux dot net" To: glibc-bugs@sources.redhat.com Message-ID: <20090630200620.10352.kees@outflux.net> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/10352] New: no protection against using fd_set with fd>1024 X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00118.txt.bz2 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.