home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 23640 < prev    next >
Encoding:
Text File  |  1993-01-11  |  1.7 KB  |  37 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!paladin.american.edu!gatech!emory!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!noc.msc.net!news.stolaf.edu!news.stolaf.edu!johnsonm
  3. From: johnsonm@amcl6.StOlaf.edu (Michael K Johnson)
  4. Subject: Re: PATCH: procps - avoid buffer overruns
  5. In-Reply-To: jaggy@purplet.demon.co.uk's message of Sun, 10 Jan 1993 13:19:00 +0000
  6. Message-ID: <JOHNSONM.93Jan11113310@amcl6.StOlaf.edu>
  7. Lines: 22
  8. Sender: news@news.stolaf.edu
  9. Reply-To: johnsonm@stolaf.edu
  10. Organization: St. Olaf College, Northfield, MN USA
  11. References: <33.2B50D630@purplet.demon.co.uk>
  12. Date: Mon, 11 Jan 1993 17:33:12 GMT
  13. Lines: 22
  14.  
  15.  
  16. In article <33.2B50D630@purplet.demon.co.uk> jaggy@purplet.demon.co.uk (Mike Jagdis) writes:
  17.  
  18.      Incidentally, I seem to remember that you said the problem wouldn't exist 
  19.    in the new version because the buffer used was the same size as a kernel 
  20.    page. Can you guarantee that the maximum length of the argument line will 
  21.    always be limited like this? Surely it would be better to limit the length 
  22.    of the copy to the size of buffer we are copying to? What? Me? Trust? Nah...
  23.  
  24. Yes, I can *guarantee* that the line will never be longer than 4096
  25. bytes.  Here's why:  In the kernel, you can never grab more than 4096
  26. contiguous bytes, and this is one using either kmalloc or (if you
  27. don't want the overhead and do want 4096 bytes) directly with
  28. get_free_page().  In the proc filesystem, get_free_page() is used to
  29. get 1 page to store everthing for that one file in, so the file cannot
  30. exceed 4096 bytes in length.
  31.  
  32. That said, my next version of procps will be a little safer in that
  33. area, but I'll do it a different way, I think...
  34.  
  35. michaelkjohnson
  36.  
  37.