Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 02 8月, 2014 22 次提交
  3. 22 5月, 2014 2 次提交
    • J
      cifs: fix potential races in cifs_revalidate_mapping · 4f73c7d3
      由 Jeff Layton 提交于 
      The handling of the CIFS_INO_INVALID_MAPPING flag is racy. It's possible
for two tasks to attempt to revalidate the mapping at the same time. The
first sees that CIFS_INO_INVALID_MAPPING is set. It clears the flag and
then calls invalidate_inode_pages2 to start shooting down the pagecache.

While that's going on, another task checks the flag and sees that it's
clear. It then ends up trusting the pagecache to satisfy a read when it
shouldn't.

Fix this by adding a bitlock to ensure that the clearing of the flag is
atomic with respect to the actual cache invalidation. Also, move the
other existing users of cifs_invalidate_mapping to use a new
cifs_zap_mapping() function that just sets the INVALID_MAPPING bit and
then uses the standard codepath to handle the invalidation.
Signed-off-by: NJeff Layton <jlayton@poochiereds.net>
Signed-off-by: NSteve French <smfrench@gmail.com>
      4f73c7d3
    • J
      cifs: convert booleans in cifsInodeInfo to a flags field · aff8d5ca
      由 Jeff Layton 提交于 
      In later patches, we'll need to have a bitlock, so go ahead and convert
these bools to use atomic bitops instead.

Also, clean up the initialization of the flags field. There's no need
to unset each bit individually just after it was zeroed on allocation.
Signed-off-by: NJeff Layton <jlayton@poochiereds.net>
Signed-off-by: NSteve French <smfrench@gmail.com>
      aff8d5ca
  5. 07 5月, 2014 5 次提交
  7. 17 4月, 2014 3 次提交
    • M
      cif: fix dead code · 1f80c0cc
      由 Michael Opdenacker 提交于 
      This issue was found by Coverity (CID 1202536)

This proposes a fix for a statement that creates dead code.
The "rc < 0" statement is within code that is run
with "rc > 0".

It seems like "err < 0" was meant to be used here.
This way, the error code is returned by the function.
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NSteve French <smfrench@gmail.com>
      1f80c0cc
    • J
      cifs: fix error handling cifs_user_readv · bae9f746
      由 Jeff Layton 提交于 
      Coverity says:

*** CID 1202537:  Dereference after null check  (FORWARD_NULL)
/fs/cifs/file.c: 2873 in cifs_user_readv()
2867     		cur_len = min_t(const size_t, len - total_read, cifs_sb->rsize);
2868     		npages = DIV_ROUND_UP(cur_len, PAGE_SIZE);
2869
2870     		/* allocate a readdata struct */
2871     		rdata = cifs_readdata_alloc(npages,
2872     					    cifs_uncached_readv_complete);
>>>     CID 1202537:  Dereference after null check  (FORWARD_NULL)
>>>     Comparing "rdata" to null implies that "rdata" might be null.
2873     		if (!rdata) {
2874     			rc = -ENOMEM;
2875     			goto error;
2876     		}
2877
2878     		rc = cifs_read_allocate_pages(rdata, npages);

...when we "goto error", rc will be non-zero, and then we end up trying
to do a kref_put on the rdata (which is NULL). Fix this by replacing
the "goto error" with a "break".

Reported-by: <scan-admin@coverity.com>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <smfrench@gmail.com>
      bae9f746
    • S
      cifs: Wait for writebacks to complete before attempting write. · c11f1df5
      由 Sachin Prabhu 提交于 
      Problem reported in Red Hat bz 1040329 for strict writes where we cache
only when we hold oplock and write direct to the server when we don't.

When we receive an oplock break, we first change the oplock value for
the inode in cifsInodeInfo->oplock to indicate that we no longer hold
the oplock before we enqueue a task to flush changes to the backing
device. Once we have completed flushing the changes, we return the
oplock to the server.

There are 2 ways here where we can have data corruption
1) While we flush changes to the backing device as part of the oplock
break, we can have processes write to the file. These writes check for
the oplock, find none and attempt to write directly to the server.
These direct writes made while we are flushing from cache could be
overwritten by data being flushed from the cache causing data
corruption.
2) While a thread runs in cifs_strict_writev, the machine could receive
and process an oplock break after the thread has checked the oplock and
found that it allows us to cache and before we have made changes to the
cache. In that case, we end up with a dirty page in cache when we
shouldn't have any. This will be flushed later and will overwrite all
subsequent writes to the part of the file represented by this page.

Before making any writes to the server, we need to confirm that we are
not in the process of flushing data to the server and if we are, we
should wait until the process is complete before we attempt the write.
We should also wait for existing writes to complete before we process
an oplock break request which changes oplock values.

We add a version specific  downgrade_oplock() operation to allow for
differences in the oplock values set for the different smb versions.

Cc: stable@vger.kernel.org
Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
Reviewed-by: NJeff Layton <jlayton@redhat.com>
Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: NSteve French <smfrench@gmail.com>
      c11f1df5
  9. 14 4月, 2014 1 次提交
  11. 12 4月, 2014 1 次提交
    • A
      cifs: fix the race in cifs_writev() · 19dfc1f5
      由 Al Viro 提交于 
      O_APPEND handling there hadn't been completely fixed by Pavel's
patch; it checks the right value, but it's racy - we can't really
do that until i_mutex has been taken.

Fix by switching to __generic_file_aio_write() (open-coding
generic_file_aio_write(), actually) and pulling mutex_lock() above
inode_size_read().

Cc: stable@vger.kernel.org
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      19dfc1f5
  13. 08 4月, 2014 1 次提交
  15. 02 4月, 2014 3 次提交
  17. 24 2月, 2014 1 次提交
  19. 15 2月, 2014 1 次提交
    • J
      cifs: ensure that uncached writes handle unmapped areas correctly · 5d81de8e
      由 Jeff Layton 提交于 
      It's possible for userland to pass down an iovec via writev() that has a
bogus user pointer in it. If that happens and we're doing an uncached
write, then we can end up getting less bytes than we expect from the
call to iov_iter_copy_from_user. This is CVE-2014-0069

cifs_iovec_write isn't set up to handle that situation however. It'll
blindly keep chugging through the page array and not filling those pages
with anything useful. Worse yet, we'll later end up with a negative
number in wdata->tailsz, which will confuse the sending routines and
cause an oops at the very least.

Fix this by having the copy phase of cifs_iovec_write stop copying data
in this situation and send the last write as a short one. At the same
time, we want to avoid sending a zero-length write to the server, so
break out of the loop and set rc to -EFAULT if that happens. This also
allows us to handle the case where no address in the iovec is valid.

[Note: Marking this for stable on v3.4+ kernels, but kernels as old as
       v2.6.38 may have a similar problem and may need similar fix]

Cc: <stable@vger.kernel.org> # v3.4+
Reviewed-by: NPavel Shilovsky <piastry@etersoft.ru>
Reported-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NSteve French <smfrench@gmail.com>
      5d81de8e