1. 06 12月, 2012 3 次提交
  2. 30 11月, 2012 1 次提交
  3. 29 11月, 2012 1 次提交
  4. 28 11月, 2012 1 次提交
  5. 05 11月, 2012 1 次提交
  6. 03 11月, 2012 1 次提交
    • J
      cifs: fix potential buffer overrun in cifs.idmap handling code · 36960e44
      Jeff Layton 提交于
      The userspace cifs.idmap program generally works with the wbclient libs
      to generate binary SIDs in userspace. That program defines the struct
      that holds these values as having a max of 15 subauthorities. The kernel
      idmapping code however limits that value to 5.
      
      When the kernel copies those values around though, it doesn't sanity
      check the num_subauths value handed back from userspace or from the
      server. It's possible therefore for userspace to hand us back a bogus
      num_subauths value (or one that's valid, but greater than 5) that could
      cause the kernel to walk off the end of the cifs_sid->sub_auths array.
      
      Fix this by defining a new routine for copying sids and using that in
      all of the places that copy it. If we end up with a sid that's longer
      than expected then this approach will just lop off the "extra" subauths,
      but that's basically what the code does today already. Better approaches
      might be to fix this code to reject SIDs with >5 subauths, or fix it
      to handle the subauths array dynamically.
      
      At the same time, change the kernel to check the length of the data
      returned by userspace. If it's shorter than struct cifs_sid, reject it
      and return -EIO. If that happens we'll end up with fields that are
      basically uninitialized.
      
      Long term, it might make sense to redefine cifs_sid using a flexarray at
      the end, to allow for variable-length subauth lists, and teach the code
      to handle the case where the subauths array being passed in from
      userspace is shorter than 5 elements.
      
      Note too, that I don't consider this a security issue since you'd need
      a compromised cifs.idmap program. If you have that, you can do all sorts
      of nefarious stuff. Still, this is probably reasonable for stable.
      
      Cc: stable@kernel.org
      Reviewed-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      36960e44
  7. 09 10月, 2012 1 次提交
    • K
      mm: kill vma flag VM_CAN_NONLINEAR · 0b173bc4
      Konstantin Khlebnikov 提交于
      Move actual pte filling for non-linear file mappings into the new special
      vma operation: ->remap_pages().
      
      Filesystems must implement this method to get non-linear mapping support,
      if it uses filemap_fault() then generic_file_remap_pages() can be used.
      
      Now device drivers can implement this method and obtain nonlinear vma support.
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>	#arch/tile
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b173bc4
  8. 08 10月, 2012 4 次提交
    • D
      KEYS: Add payload preparsing opportunity prior to key instantiate or update · cf7f601c
      David Howells 提交于
      Give the key type the opportunity to preparse the payload prior to the
      instantiation and update routines being called.  This is done with the
      provision of two new key type operations:
      
      	int (*preparse)(struct key_preparsed_payload *prep);
      	void (*free_preparse)(struct key_preparsed_payload *prep);
      
      If the first operation is present, then it is called before key creation (in
      the add/update case) or before the key semaphore is taken (in the update and
      instantiate cases).  The second operation is called to clean up if the first
      was called.
      
      preparse() is given the opportunity to fill in the following structure:
      
      	struct key_preparsed_payload {
      		char		*description;
      		void		*type_data[2];
      		void		*payload;
      		const void	*data;
      		size_t		datalen;
      		size_t		quotalen;
      	};
      
      Before the preparser is called, the first three fields will have been cleared,
      the payload pointer and size will be stored in data and datalen and the default
      quota size from the key_type struct will be stored into quotalen.
      
      The preparser may parse the payload in any way it likes and may store data in
      the type_data[] and payload fields for use by the instantiate() and update()
      ops.
      
      The preparser may also propose a description for the key by attaching it as a
      string to the description field.  This can be used by passing a NULL or ""
      description to the add_key() system call or the key_create_or_update()
      function.  This cannot work with request_key() as that required the description
      to tell the upcall about the key to be created.
      
      This, for example permits keys that store PGP public keys to generate their own
      name from the user ID and public key fingerprint in the key.
      
      The instantiate() and update() operations are then modified to look like this:
      
      	int (*instantiate)(struct key *key, struct key_preparsed_payload *prep);
      	int (*update)(struct key *key, struct key_preparsed_payload *prep);
      
      and the new payload data is passed in *prep, whether or not it was preparsed.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      cf7f601c
    • J
      cifs: reinstate the forcegid option · 72bd481f
      Jeff Layton 提交于
      Apparently this was lost when we converted to the standard option
      parser in 8830d7e0
      
      Cc: Sachin Prabhu <sprabhu@redhat.com>
      Cc: stable@vger.kernel.org # v3.4+
      Reported-by: NGregory Lee Bartholomew <gregory.lee.bartholomew@gmail.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      72bd481f
    • F
      Convert properly UTF-8 to UTF-16 · fd3ba42c
      Frediano Ziglio 提交于
      wchar_t is currently 16bit so converting a utf8 encoded characters not
      in plane 0 (>= 0x10000) to wchar_t (that is calling char2uni) lead to a
      -EINVAL return. This patch detect utf8 in cifs_strtoUTF16 and add special
      code calling utf8s_to_utf16s.
      Signed-off-by: NFrediano Ziglio <frediano.ziglio@citrix.com>
      Acked-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      fd3ba42c
    • S
      [CIFS] WARN_ON_ONCE if kernel_sendmsg() returns -ENOSPC · b7a10626
      Steve French 提交于
      kernel_sendmsg() is less likely to return -ENOSPC and it might be
      a bug to do so. However, in the past there might have been cases
      where a -ENOSPC was returned from a low level driver.
      
      Add a WARN_ON_ONCE() to ensure that it is safe to assume that -ENOSPC
      is no longer returned. This -ENOSPC specific handling will be removed
      once we are sure it is no longer returned.
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSuresh Jayaraman <sjayaraman@suse.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      b7a10626
  9. 03 10月, 2012 1 次提交
  10. 02 10月, 2012 2 次提交
  11. 29 9月, 2012 1 次提交
  12. 27 9月, 2012 4 次提交
  13. 25 9月, 2012 19 次提交