Re: [PATCH] Security fix for 2.1.111, 2.0.x forwardport

Linus Torvalds (
Sun, 26 Jul 1998 13:52:50 -0700 (PDT)

On Sun, 26 Jul 1998, Chris Evans wrote:
> I'd like to again express my strong concerns that 2.2.0 will be
> substantially _less_ stable than 2.0.x, unless we get a few more people to
> look over the later 2.0.x patches and forward port all the fixes.

I was hoping that people who knew that they had fixed problems in 2.0.x
would you check that the 2.1.x tree is ok, like you did. "Distributed
checking". Often trying to forward-port fixes is hard simply because the
thing it fixes in 2.0.x may be done differently in 2.1.x.

However, this particular patch is an incomplete fix to the problem, even
on 2.0.x.

> + /* cevans - whoops another append-only file flaw */
> + if (IS_APPEND(file->f_dentry->d_inode) &&
> + (prot & PROT_WRITE))
> + return -EACCES;

The PROT_WRITE thing is ephemeral, and you can overcome this security fix
by just originally mapping it with PROT_NONE and then later doing a
"mprotect(PROT_WRITE)" on the area.

The proper (and now in my 2.1 tree) fix is to have

/* Make sure we don't allow writing to an append-only file.. */
if (IS_APPEND(file->f_dentry->d_inode) && (file->f_mode & 2))
return -EACCES;

which means that not only is it not a writable mapping now, it can never
become a writable mapping because the file descriptor was not writable.

Alternatively you could add another test to mprotect(), but I think it's
better to just completely disallow a shared mapping of a append-only file
descriptor that was opened with write mode. Anybody trying to do that
looks suspicious anyway.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at