Problem with mangled caf files in CAFOpenArtRead() (storage/timecaf/caf.c bug?)

Xavier Roche roche at
Mon Dec 13 13:12:44 UTC 2004


As a followup to a problem we encountered 
with INN on a large spool, I discovered that there might be a problem in 
the CAFOpenArtRead() function.

OS: Digital alpha (Tru64 5.1)
INN version: 2.4.1

When a .CF file is truncated for any reason (in our case, probably a 
memory shortage that crashed INN), the .CF header apparently contains 
references (file offset) of messages that are beyond the file.

In our case, the file size was:
and the article offset was:

Problem: the 'lseek(fd, tocent.Offset, SEEK_SET) < 0)' (at caf.c:592) is 
successful (no error returned by the system - this is probably 'legal' 
to seek beyond a file boundary) and the mmap (at timecaf.c:463, 
'private->mmapbase = mmap(NULL, private->mmaplen, PROT_READ, MAP_SHARED, 
fd, tmpoff)') returns a pointer to the "ghost" area. BUT reading in this 
"ghost" area lead to a BUS error (process stopped with a 'Bus error 
(core dumped)' message)

The mapped memory region is alive in the system mmap table:

bash-2.01$ pmap 180210
flags       vaddr        size         off
  r--        10000        2000           0
  r--        12000        2000           0
  rw-        14000        2000           0
  rw-        16000      36e000           0
  r--       384000        6000      7b4000   <<<< THIS ONE
  rwx    11fff0000       10000           0

(the '0x7b4000' is the file offset, == 8077312, which is higher than the 
filesize, 8072404 bytes)

And nor the program or debugger can not read this zone:

(ladebug) 0x384000/10x
0x384000: Failed to read data.

I know that the file is probably truncated, but would it be possible to 
handle out-of-bound indexes with mmap() ?

I can provide more information (the session is still under debugger) if 
you wish.


More information about the inn-bugs mailing list