1. 26 Oct, 2016 33 commits
  2. 27 Apr, 2016 7 commits
    • Zefan Li's avatar
      Linux 3.4.112 · 343a5fbe
      Zefan Li authored
      343a5fbe
    • Andy Lutomirski's avatar
      x86/iopl/64: Properly context-switch IOPL on Xen PV · 97e0c908
      Andy Lutomirski authored
      commit b7a58459 upstream.
      
      On Xen PV, regs->flags doesn't reliably reflect IOPL and the
      exit-to-userspace code doesn't change IOPL.  We need to context
      switch it manually.
      
      I'm doing this without going through paravirt because this is
      specific to Xen PV.  After the dust settles, we can merge this with
      the 32-bit code, tidy up the iopl syscall implementation, and remove
      the set_iopl pvop entirely.
      
      Fixes XSA-171.
      Reviewewd-by: default avatarJan Beulich <JBeulich@suse.com>
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Andrew Cooper <andrew.cooper3@citrix.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [ kamal: backport to 3.19-stable: no X86_FEATURE_XENPV so just call
        xen_pv_domain() directly ]
      Acked-by: Andy Lutomirski <luto <at> kernel.org>
      Signed-off-by: Kamal Mostafa <kamal <at> canonical.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      97e0c908
    • Christophe Leroy's avatar
      splice: sendfile() at once fails for big files · 0765dbc5
      Christophe Leroy authored
      commit 0ff28d9f upstream.
      
      Using sendfile with below small program to get MD5 sums of some files,
      it appear that big files (over 64kbytes with 4k pages system) get a
      wrong MD5 sum while small files get the correct sum.
      This program uses sendfile() to send a file to an AF_ALG socket
      for hashing.
      
      /* md5sum2.c */
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <string.h>
      #include <fcntl.h>
      #include <sys/socket.h>
      #include <sys/stat.h>
      #include <sys/types.h>
      #include <linux/if_alg.h>
      
      int main(int argc, char **argv)
      {
      	int sk = socket(AF_ALG, SOCK_SEQPACKET, 0);
      	struct stat st;
      	struct sockaddr_alg sa = {
      		.salg_family = AF_ALG,
      		.salg_type = "hash",
      		.salg_name = "md5",
      	};
      	int n;
      
      	bind(sk, (struct sockaddr*)&sa, sizeof(sa));
      
      	for (n = 1; n < argc; n++) {
      		int size;
      		int offset = 0;
      		char buf[4096];
      		int fd;
      		int sko;
      		int i;
      
      		fd = open(argv[n], O_RDONLY);
      		sko = accept(sk, NULL, 0);
      		fstat(fd, &st);
      		size = st.st_size;
      		sendfile(sko, fd, &offset, size);
      		size = read(sko, buf, sizeof(buf));
      		for (i = 0; i < size; i++)
      			printf("%2.2x", buf[i]);
      		printf("  %s\n", argv[n]);
      		close(fd);
      		close(sko);
      	}
      	exit(0);
      }
      
      Test below is done using official linux patch files. First result is
      with a software based md5sum. Second result is with the program above.
      
      root@vgoip:~# ls -l patch-3.6.*
      -rw-r--r--    1 root     root         64011 Aug 24 12:01 patch-3.6.2.gz
      -rw-r--r--    1 root     root         94131 Aug 24 12:01 patch-3.6.3.gz
      
      root@vgoip:~# md5sum patch-3.6.*
      b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
      c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz
      
      root@vgoip:~# ./md5sum2 patch-3.6.*
      b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
      5fd77b24e68bb24dcc72d6e57c64790e  patch-3.6.3.gz
      
      After investivation, it appears that sendfile() sends the files by blocks
      of 64kbytes (16 times PAGE_SIZE). The problem is that at the end of each
      block, the SPLICE_F_MORE flag is missing, therefore the hashing operation
      is reset as if it was the end of the file.
      
      This patch adds SPLICE_F_MORE to the flags when more data is pending.
      
      With the patch applied, we get the correct sums:
      
      root@vgoip:~# md5sum patch-3.6.*
      b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
      c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz
      
      root@vgoip:~# ./md5sum2 patch-3.6.*
      b3ffb9848196846f31b2ff133d2d6443  patch-3.6.2.gz
      c5e8f687878457db77cb7158c38a7e43  patch-3.6.3.gz
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      0765dbc5
    • Ben Hutchings's avatar
      pipe: Fix buffer offset after partially failed read · b381fbc5
      Ben Hutchings authored
      Quoting the RHEL advisory:
      
      > It was found that the fix for CVE-2015-1805 incorrectly kept buffer
      > offset and buffer length in sync on a failed atomic read, potentially
      > resulting in a pipe buffer state corruption. A local, unprivileged user
      > could use this flaw to crash the system or leak kernel memory to user
      > space. (CVE-2016-0774, Moderate)
      
      The same flawed fix was applied to stable branches from 2.6.32.y to
      3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
      We need to give pipe_iov_copy_to_user() a separate offset variable
      and only update the buffer offset if it succeeds.
      
      References: https://rhn.redhat.com/errata/RHSA-2016-0103.htmlSigned-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Cc: Jeffrey Vander Stoep <jeffv@google.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      b381fbc5
    • Ben Hutchings's avatar
      usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message · e08cc94c
      Ben Hutchings authored
      commit 5377adb0 upstream.
      
      usb_parse_ss_endpoint_companion() now decodes the burst multiplier
      correctly in order to check that it's <= 3, but still uses the wrong
      expression if warning that it's > 3.
      
      Fixes: ff30cbc8 ("usb: Use the USB_SS_MULT() macro to get the ...")
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      e08cc94c
    • Nate Dailey's avatar
      raid1: include bio_end_io_list in nr_queued to prevent freeze_array hang · 9237baa5
      Nate Dailey authored
      commit ccfc7bf1 upstream.
      
      If raid1d is handling a mix of read and write errors, handle_read_error's
      call to freeze_array can get stuck.
      
      This can happen because, though the bio_end_io_list is initially drained,
      writes can be added to it via handle_write_finished as the retry_list
      is processed. These writes contribute to nr_pending but are not included
      in nr_queued.
      
      If a later entry on the retry_list triggers a call to handle_read_error,
      freeze array hangs waiting for nr_pending == nr_queued+extra. The writes
      on the bio_end_io_list aren't included in nr_queued so the condition will
      never be satisfied.
      
      To prevent the hang, include bio_end_io_list writes in nr_queued.
      
      There's probably a better way to handle decrementing nr_queued, but this
      seemed like the safest way to avoid breaking surrounding code.
      
      I'm happy to supply the script I used to repro this hang.
      
      Fixes: 55ce74d4(md/raid1: ensure device failure recorded before write request returns.)
      Signed-off-by: default avatarNate Dailey <nate.dailey@stratus.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      9237baa5
    • Dāvis Mosāns's avatar
      mvsas: Fix NULL pointer dereference in mvs_slot_task_free · 4b7e6b74
      Dāvis Mosāns authored
      commit 22805217 upstream.
      
      When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays
      NULL but it's later used in mvs_abort_task as slot which is passed
      to mvs_slot_task_free causing NULL pointer dereference.
      
      Just return from mvs_slot_task_free when passed with NULL slot.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891Signed-off-by: default avatarDāvis Mosāns <davispuh@gmail.com>
      Reviewed-by: default avatarTomas Henzl <thenzl@redhat.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
      Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
      4b7e6b74