diff options
| author | Ross Zwisler <ross.zwisler@linux.intel.com> | 2017-09-06 16:18:54 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2017-09-06 17:27:24 -0700 |
| commit | a2e050f5a9a9bd2b632d67bd06d87088e6a02dae (patch) | |
| tree | a7cc6d57eccb6b9e168c51ff5d1baf065f62dae7 /fs/dax.c | |
| parent | 527b19d0808e75fbba896beb2435c2b4d6bcd32a (diff) | |
| download | linux-a2e050f5a9a9bd2b632d67bd06d87088e6a02dae.tar.bz2 | |
dax: explain how read(2)/write(2) addresses are validated
Add a comment explaining how the user addresses provided to read(2) and
write(2) are validated in the DAX I/O path.
We call dax_copy_from_iter() or copy_to_iter() on these without calling
access_ok() first in the DAX code, and there was a concern that the user
might be able to read/write to arbitrary kernel addresses with this
path.
Link: http://lkml.kernel.org/r/20170816173615.10098-1-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/dax.c')
| -rw-r--r-- | fs/dax.c | 5 |
1 files changed, 5 insertions, 0 deletions
@@ -1004,6 +1004,11 @@ dax_iomap_actor(struct inode *inode, loff_t pos, loff_t length, void *data, if (map_len > end - pos) map_len = end - pos; + /* + * The userspace address for the memory copy has already been + * validated via access_ok() in either vfs_read() or + * vfs_write(), depending on which operation we are doing. + */ if (iov_iter_rw(iter) == WRITE) map_len = dax_copy_from_iter(dax_dev, pgoff, kaddr, map_len, iter); |