Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Aug 2013 00:36:01 +0200
From: Hannes Frederic Sowa <>
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.



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.