lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 31 Aug 2006 21:25:14 -0700 From: Vadim Lobanov <vlobanov@...akeasy.net> To: Willy Tarreau <w@....eu> Cc: Chris Snook <csnook@...hat.com>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 2.4.33.2] enforce RLIMIT_NOFILE in poll() On Thursday 31 August 2006 20:48, Willy Tarreau wrote: > Hi Chris, > > On Thu, Aug 31, 2006 at 09:06:55PM -0400, Chris Snook wrote: > > From: Chris Snook <csnook@...hat.com> > > > > POSIX states that poll() shall fail with EINVAL if nfds > OPEN_MAX. In > > this context, POSIX is referring to sysconf(OPEN_MAX), which is the value > > of current->rlim[RLIMIT_NOFILE].rlim_cur, not the compile-time constant > > which happens to be named OPEN_MAX. The current code will permit polling > > up to 1024 file descriptors even if RLIMIT_NOFILE is less than 1024, > > which POSIX forbids. The current code also breaks polling greater than > > 1024 file descriptors if the process has less than 1024 valid > > descriptors, even if RLIMIT_NOFILE > 1024. While it is silly to poll > > duplicate or invalid file descriptors, POSIX permits this, and it worked > > circa 2.4.18, and currently works up to 1024. This patch directly checks > > the RLIMIT_NOFILE value, and permits exactly what POSIX suggests, no > > more, no less. > > While I understand that it was a bug before, I fear that it could break > existing apps. Are you aware of some apps which do not work as expected > because of this bug ? If not, I'd prefer to wait for some feedback from > 2.6 with this fix before applying it (or maybe you're already using it > in RHEL with success ?). I submitted a similar but different patch for this very same issue against the 2.6 kernel. It's currently residing in the -mm tree. Andrew Morton is somewhat reticent (and understandably so) to push it quickly into the vanilla tree; but, for what it's worth, I've yet to hear -- either directly or indirectly -- of any application breakages caused by this fix. > Thanks, > Willy > > > Signed-off-by: Chris Snook <csnook@...hat.com> > > --- > > > > diff -urNp linux-2.4.33.2-orig/fs/select.c > > linux-2.4.33.2-patch/fs/select.c --- > > linux-2.4.33.2-orig/fs/select.c 2006-08-22 16:13:54.000000000 -0400 +++ > > linux-2.4.33.2-patch/fs/select.c 2006-08-31 13:43:39.000000000 -0400 @@ > > -417,7 +417,7 @@ asmlinkage long sys_poll(struct pollfd * > > int nchunks, nleft; > > > > /* Do a sanity check on nfds ... */ > > - if (nfds > current->files->max_fdset && nfds > OPEN_MAX) > > + if (nfds > current->rlim[RLIMIT_NOFILE].rlim_cur) > > return -EINVAL; > > > > if (timeout) { > -- Vadim Lobanov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists