Re: truncate shows non zero data beyond the end of the inode with

Re: truncate shows non zero data beyond the end of the inode with

[linux]

> Could this "garbage" possibly be confidential data?
> I.e. one user repeatedly makes and mmaps a 1-byte file,
> extends it to 4k, and looks at the 4095 bytes of "garbage".
> Maybe he finds some "interesting stuff" when someone else's
> confidential file just got dropped from pagecache
> so he could mmap this 1-byte file?

No, it couldn't.  The sequence of operations is:

- char *p = mmap(1-byte file).  p[1] through p[4095] are guaranteed to be zero.
- Write to p[1] through p[4095].  If the file is flushed at this point,
  the extra bytes are guaranteed NOT to be written to disk.
- ftruncate() the file to 4096 bytes
- At this point, Linux may flush the non-zero bytes p[1]..p[4095] to disk.

*That* is the issue being complained about.  If you write to p[1] through
p[4095] *before* calling truncate(2) or ftruncate(2), it can get written
back to disk.

If you don't write past the EOF, it doesn't arise.

The only security issue is that, although you technically are guaranteed
access to the trailing partial page, so a correct program *could*
rely on it, it's more commonly evidence of a bug, and bugs often have
security implications.