Re: pkg/50995: sigsegv in recv()

[David Holland <dholland-pbugs%netbsd.org@localhost>]

The following reply was made to PR pkg/50995; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/50995: sigsegv in recv()
Date: Sun, 3 Apr 2016 03:24:34 +0000

 On Fri, Apr 01, 2016 at 08:20:01AM +0000, Patrick Welche wrote:
  >  Looking at the coredump:
  >  
  >  fd.sck = 256
  >  
  >          fd_set fdSet;
  >          FD_ZERO(&fdSet);  // clear the set
  >          FD_SET(sck, &fdSet);  // add fd to the set
  >          timeval t;  // timeval struct
  >          t.tv_sec = 0;
  >          t.tv_usec = 0;  
  >  
  >          if (selectEINTR(sck + 1, &fdSet, NULL, NULL, &t) < 1) {
  >                  return false;
  >          }
  >  
  >  so the number-of-fds argument is 257
  >  
  >  src/sys/sys/fd_set.h:
  >  
  >  /*
  >   * Select uses bit fields of file descriptors.  These macros manipulate
  >   * such bit fields.  Note: FD_SETSIZE may be defined by the user.
  >   */
  >  
  >  #ifndef FD_SETSIZE
  >  #define FD_SETSIZE      256
  >  #endif
  >  
  >  so you have a hole in one! (I don't see FD_SETSIZE defined by the user...)
  >  
  >  (How can this trash the stack?)
 
 An out-of-range FD_SET will scribble outside of the fd_set, and since
 the one here is on the stack, whatever's next on the stack gets a
 present.
 
 The path of least resistance is #define FD_SETSIZE 512 (before
 including anything) but rewriting to use poll is probably a better
 choice. Especially for selecting on a single fd like this.
 
 (while changing FD_SETSIZE is a traditional interface, it's probably
 not very portable)
 
 Does the package have a viable upstream?
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost