Thread: Another link from Microsoft about bug in fread

  1. #1
    "I Win!" by U. Lose vart's Avatar
    Join Date
    Oct 2006
    Rishon LeZion, Israel

    Another link from Microsoft about bug in fread

    04/15/2008: "A bug in fread() could lead to a buffer overflow vulnerability"
    I see it as a bug in using fread, not fread itself...

    And as result will say do not strcpy buffer read by fread - use the return value to determine how many chars should be copied...
    To be or not to be == true

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Nope, it's a bug in fread. A specification bug, maybe. It trashes parts of the buffer that lie beyond the index returned as the number of characters written. A programmer who expected the buffer beyond this index to be unmodified would be caught by this.
    Also, this behaves differently from an fread that is implemented exactly as the standard says, so the as-if rule is violated, and the function is in violation of the specification.

    For reference, the standard says that fread is implemented to have an effect equivalent to this function:
    size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream)
      int m, s, c;
      for(m = 0; m < nmemb; ++m) {
        unsigned char *p = (unsigned char*)ptr;
        p += m * size;
        for(s = 0; s < size; ++s) {
          c = fgetc(stream);
          if(c == EOF) {
            return (m * size) + s;
          p[s] = (unsigned char)c;
      return nmemb * size;
    Note that, since fgetc() does the line ending conversion, this cannot possibly write beyond the index it returns.

    The conclusions the blogger draws are incorrect, however. It's not a buffer overflow bug, because the function won't write beyond the end of the buffer as you indicate it. Neither is there any danger of you overflowing the buffer if - as is necessary, because fread() never gives nul-termination - you passed a shorter length to fread than indicated and nulled the stuff beyond out. The danger there is is reading garbage.
    Also, he says not to trust the return value. This is wrong. It's the return value you have to trust. What you can't trust is the state of the buffer beyond the index of this return value.

    Another error of the blogger: CRLF pairs are converted to LFs, not CRs.
    Last edited by CornedBee; 05-06-2008 at 04:23 AM.
    All the buzzt!

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #3
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    United States
    I'm bemused how he attempts to prove a point about "buffer overruns" and yet he uses strcpy. Given the conclusion he drew, he wouldn't have considered copying just bytesread bytes, but it would have made the issue go away. Meh.
    Last edited by whiteflags; 05-06-2008 at 11:58 AM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. problem with fread and fwrite? bug?
    By moonlord in forum C Programming
    Replies: 17
    Last Post: 08-21-2005, 09:31 AM
  2. Microsoft Product Activiation loopholes
    By Liger86 in forum A Brief History of
    Replies: 4
    Last Post: 07-08-2005, 05:20 PM
  3. Is Linux More Secure Than Windows?
    By xErath in forum A Brief History of
    Replies: 69
    Last Post: 06-29-2005, 07:13 PM
  4. Apps that act "differently" in XP SP2
    By Stan100 in forum Tech Board
    Replies: 6
    Last Post: 08-16-2004, 10:38 PM
  5. destructor with a link list
    By Bones in forum C++ Programming
    Replies: 1
    Last Post: 09-24-2003, 12:01 PM
Website Security Test