home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / linux / 23567 < prev    next >
Encoding:
Text File  |  1993-01-11  |  1.5 KB  |  39 lines
  1. Newsgroups: comp.os.linux
  2. From: jaggy@purplet.demon.co.uk (Mike Jagdis)
  3. Path: sparky!uunet!pipex!demon!purplet!jaggy
  4. Subject: Re: PATCH: procps - avoid buffer overruns
  5. Organization: FidoNet node 2:252/305 - The Purple Tentacle, Reading
  6. Date: Sun, 10 Jan 1993 13:19:00 +0000
  7. Message-ID: <33.2B50D630@purplet.demon.co.uk>
  8. Sender: usenet@demon.co.uk
  9. Lines: 28
  10.  
  11. * In message <1993Jan9.070311.26248@news.stolaf.edu>,
  12.   Michael K. Johnson said:
  13.  
  14. MJ> This patch is to an old procps.  The new procps fixes this
  15. MJ> bug, as well as several others.
  16.  
  17. Guess I must have missed an announcment somewhere along the line then...
  18.  
  19. MJ> Before posting patches like this, it would be
  20. MJ> nice to offer them to the author,
  21.  
  22. I did :-). I never claimed it was an official patch. Just something that 
  23. stops annoying core dumps...
  24.  
  25. MJ> and to check the ftp site (hint hint hint).
  26.  
  27. Well, I picked the archive I have up from tsx-11 on 1st Jan and it's 9601 
  28. bytes long. After your mail to me I looked on tsx-11 again. The procps.tar.Z 
  29. in BETA/procps is dated 29th Dec and is 9601 bytes long. What am I missing?
  30.  
  31.   Incidentally, I seem to remember that you said the problem wouldn't exist 
  32. in the new version because the buffer used was the same size as a kernel 
  33. page. Can you guarantee that the maximum length of the argument line will 
  34. always be limited like this? Surely it would be better to limit the length 
  35. of the copy to the size of buffer we are copying to? What? Me? Trust? Nah...
  36.  
  37.                                 Mike  
  38.  
  39.