Bug in C library sscanf()

Bug in C library sscanf()

Post by Anthony Shipm » Sat, 24 Oct 1992 13:32:15



I found the following bug in SCO Unix 3.2.* and I think it may be common
to many AT&T derived Unixes.  
=======================================

sscanf() calls _doscan() to read from a pretend file.  The file
uses the string as a buffer and a fake file descriptor of 60 (=_NFILE).  
Since _NFILE (for SCO UNIX) is 60 it assumes that fd 60 can never be open.

Then when fscanf() hits the end of the string it calls _filbuf() to read
into the buffer (which is the string) from fd 60.  This should fail with
an errno=9 and then _filbuf() sets EOF and it all terminates.

However in SCO Unix you can reconfigure the kernel to increase the number
of files per process to a recommended maximum of 150.  If you do this then
your program might have fd 60 open one day.  Then sscanf() will read from this
file overwriting your string.  The byte count to the read() in _filbuf()
is some undefined but large value so a lot of memory will be overwritten.  In
my case the string was on the stack so my stack was wiped.

In short if you configure your kernel to have NOFILES > _NFILE ie more than
the default then sscanf() is a time bomb in your code.

I noticed that Pyramid's OS has the same code in sscanf() and _filbuf().
HPUX however has a special flag to indicate pretend files for _doscan().

--

Computer Power Group, R&D
19 Cato St., East Hawthorn, Vic

--
Anthony Shipman                 "You've got to be taught before it's too late,
CP Software Export Pty Ltd,      Before you are six or seven or eight,
19 Cato St., East Hawthorn,      To hate all the people your relatives hate,
Melbourne, Australia, 3121       You've got to be carefully taught."  R&H

 
 
 

Bug in C library sscanf()

Post by Shane Bouslou » Sun, 25 Oct 1992 09:29:13


: sscanf() calls _doscan() to read from a pretend file...

You mean there are people who *still* use scanf()??? :-) :-)

: Anthony Shipman                 "You've got to be taught before it's too late,
: CP Software Export Pty Ltd,      Before you are six or seven or eight,
: 19 Cato St., East Hawthorn,      To hate all the people your relatives hate,
: Melbourne, Australia, 3121       You've got to be carefully taught."  R&H

-Shane

--
Shane Bouslough       | #include <stddisc.h>


 
 
 

1. Bug in sscanf() in Elf libraries!

Hello!
   I have found a bug in the Elf libraries for Linux.  I have seen it in Slackware 3.0
elf.  The bug is definitely *NOT* present in the a.out libraries.
   Where do I report this?  Is there a Linux bug list somewhere?  How do I go about
getting this fixed?
   The "%[" construct doesn't seem to always work as it should.  The program here will
produce the expected result under every OS I have tried (including Linux without Elf
libraries) but produces the wrong results under Slackware 3.0 Elf:

/* stest.c - Test of the sscanf() call. */

#include <stdio.h>

int  main(int argc, char *argv[])  {
  int  matches;
  char  str[10];

  str[0] = '\0';
  sscanf("x ]", "%[^] ]", str);
  printf("Matches = %d, string str = \"%s\".\n", matches, str);
  printf("str should be \"x\".\n");
  exit(0);
/* End of program. */

   Please will somebody let me know - Is this a known problem?  Is it fixed already in
later releases?

                                 http://www.hevanet.com/wms/

2. Cirrus GD5428 & 40 MB of RAM

3. Sscanf bug breaks xfig 2.1.6 and 2.1.7

4. Postgres95

5. hostid bug (?) related to questionnable sscanf() behavior

6. Do Linux and TokenRing Mix???

7. libc sscanf() "%n" format bug?

8. drivers/scsi/st.c: sugg bt?

9. Bug in sscanf on AIX 1.2.1

10. Unix Libraries Ins/Outs

11. libraries libraries libraries

12. Bugs in shared libraries (dlopen / dlclose)..

13. Possible bug in slackware 3.0's new libraries