[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130820223601.GC20223@order.stressinduktion.org>
Date: Wed, 21 Aug 2013 00:36:01 +0200
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel: vfs_read()/vfs_write(): potential missing checks (or not?)
On Tue, Aug 20, 2013 at 07:58:49PM +0200, vladz wrote:
>
> [...]
>
> Looking at the kernel sources, the vfs_read(), vfs_write(), vfs_readv()
> and vfs_writev() functions checks the permissions of the file object
> (file->f_mode) before operating on file descriptor:
>
> $ cat -n linux-3.10.7/fs/read_write.c
> [...]
> 353 ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
> 354 {
> 355 ssize_t ret;
> 356
> 357 if (!(file->f_mode & FMODE_READ))
> 358 return -EBADF;
>
> I believe this is insufficient, the inode object should be checked too.
> So that if the file's permissions allow read/write operations, so we can
> perform reading/writing from/to the file descriptor. I've patched the
> concerned function to do so (cf. patch [3]).
This behavior is deliberatly chosen. If the inode is checked again, you
could just mmap the filedescriptor to memory and get away with that,
too. There are plans to implement a revoke-syscall. Maybe it will
be implemented for files, too (other operating systems only provide
revoke-Support for terminals, block or char devices). This shoud then
handle the teardown of memory mappings with some specified semantic, too.
Greetings,
Hannes
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
