1. 17 Sep, 2010 7 commits
  2. 16 Sep, 2010 10 commits
  3. 15 Sep, 2010 20 commits
  4. 14 Sep, 2010 3 commits
    • Jeff Layton's avatar
      cifs: fix potential double put of TCP session reference · 460cf341
      Jeff Layton authored
      cifs_get_smb_ses must be called on a server pointer on which it holds an
      active reference. It first does a search for an existing SMB session. If
      it finds one, it'll put the server reference and then try to ensure that
      the negprot is done, etc.
      
      If it encounters an error at that point then it'll return an error.
      There's a potential problem here though. When cifs_get_smb_ses returns
      an error, the caller will also put the TCP server reference leading to a
      double-put.
      
      Fix this by having cifs_get_smb_ses only put the server reference if
      it found an existing session that it could use and isn't returning an
      error.
      
      Cc: stable@kernel.org
      Reviewed-by: default avatarSuresh Jayaraman <sjayaraman@suse.de>
      Signed-off-by: default avatarJeff Layton <jlayton@redhat.com>
      Signed-off-by: default avatarSteve French <sfrench@us.ibm.com>
      460cf341
    • Roland McGrath's avatar
      x86-64, compat: Retruncate rax after ia32 syscall entry tracing · eefdca04
      Roland McGrath authored
      In commit d4d67150, we reopened an old hole for a 64-bit ptracer touching a
      32-bit tracee in system call entry.  A %rax value set via ptrace at the
      entry tracing stop gets used whole as a 32-bit syscall number, while we
      only check the low 32 bits for validity.
      
      Fix it by truncating %rax back to 32 bits after syscall_trace_enter,
      in addition to testing the full 64 bits as has already been added.
      Reported-by: default avatarBen Hawkes <hawkes@sota.gen.nz>
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      eefdca04
    • H. Peter Anvin's avatar
      x86-64, compat: Test %rax for the syscall number, not %eax · 36d001c7
      H. Peter Anvin authored
      On 64 bits, we always, by necessity, jump through the system call
      table via %rax.  For 32-bit system calls, in theory the system call
      number is stored in %eax, and the code was testing %eax for a valid
      system call number.  At one point we loaded the stored value back from
      the stack to enforce zero-extension, but that was removed in checkin
      d4d67150.  An actual 32-bit process
      will not be able to introduce a non-zero-extended number, but it can
      happen via ptrace.
      
      Instead of re-introducing the zero-extension, test what we are
      actually going to use, i.e. %rax.  This only adds a handful of REX
      prefixes to the code.
      Reported-by: default avatarBen Hawkes <hawkes@sota.gen.nz>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@kernel.org>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      36d001c7