1. 12 Sep, 2019 1 commit
    • Eugene Syromiatnikov's avatar
      fork: block invalid exit signals with clone3() · a0eb9abd
      Eugene Syromiatnikov authored
      Previously, higher 32 bits of exit_signal fields were lost when copied
      to the kernel args structure (that uses int as a type for the respective
      field). Moreover, as Oleg has noted, exit_signal is used unchecked, so
      it has to be checked for sanity before use; for the legacy syscalls,
      applying CSIGNAL mask guarantees that it is at least non-negative;
      however, there's no such thing is done in clone3() code path, and that
      can break at least thread_group_leader.
      
      This commit adds a check to copy_clone_args_from_user() to verify that
      the exit signal is limited by CSIGNAL as with legacy clone() and that
      the signal is valid. With this we don't get the legacy clone behavior
      were an invalid signal could be handed down and would only be detected
      and ignored in do_notify_parent(). Users of clone3() will now get a
      proper error when they pass an invalid exit signal. Note, that this is
      not user-visible behavior since no kernel with clone3() has been
      released yet.
      
      The following program will cause a splat on a non-fixed clone3() version
      and will fail correctly on a fixed version:
      
       #define _GNU_SOURCE
       #include <linux/sched.h>
       #include <linux/types.h>
       #include <sched.h>
       #include <stdio.h>
       #include <stdlib.h>
       #include <sys/syscall.h>
       #include <sys/wait.h>
       #include <unistd.h>
      
       int main(int argc, char *argv[])
       {
              pid_t pid = -1;
              struct clone_args args = {0};
              args.exit_signal = -1;
      
              pid = syscall(__NR_clone3, &args, sizeof(struct clone_args));
              if (pid < 0)
                      exit(EXIT_FAILURE);
      
              if (pid == 0)
                      exit(EXIT_SUCCESS);
      
              wait(NULL);
      
              exit(EXIT_SUCCESS);
       }
      
      Fixes: 7f192e3c
      
       ("fork: add clone3")
      Reported-by: default avatarOleg Nesterov <oleg@redhat.com>
      Suggested-by: default avatarOleg Nesterov <oleg@redhat.com>
      Suggested-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Signed-off-by: default avatarEugene Syromiatnikov <esyr@redhat.com>
      Link: https://lore.kernel.org/r/4b38fa4ce420b119a4c6345f42fe3cec2de9b0b5.1568223594.git.esyr@redhat.com
      
      
      [christian.brauner@ubuntu.com: simplify check and rework commit message]
      Signed-off-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      a0eb9abd
  2. 08 Sep, 2019 4 commits
  3. 07 Sep, 2019 4 commits
  4. 06 Sep, 2019 17 commits
  5. 05 Sep, 2019 9 commits
  6. 04 Sep, 2019 5 commits
    • Al Viro's avatar
      configfs: provide exclusion between IO and removals · b0841eef
      Al Viro authored
      
      
      Make sure that attribute methods are not called after the item
      has been removed from the tree.  To do so, we
      	* at the point of no return in removals, grab ->frag_sem
      exclusive and mark the fragment dead.
      	* call the methods of attributes with ->frag_sem taken
      shared and only after having verified that the fragment is still
      alive.
      
      	The main benefit is for method instances - they are
      guaranteed that the objects they are accessing *and* all ancestors
      are still there.  Another win is that we don't need to bother
      with extra refcount on config_item when opening a file -
      the item will be alive for as long as it stays in the tree, and
      we won't touch it/attributes/any associated data after it's
      been removed from the tree.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      b0841eef
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-5.3-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs · 3b47fd5c
      Linus Torvalds authored
      Pull NFS client bugfix from Trond Myklebust:
       "Regression fix inode fileid checks in attribute revalidation code"
      
      * tag 'nfs-for-5.3-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
        NFS: Fix inode fileid checks in attribute revalidation code
      3b47fd5c
    • Ingo Molnar's avatar
      sched/core: Fix uclamp ABI bug, clean up and robustify sched_read_attr() ABI logic and code · 1251201c
      Ingo Molnar authored
      Thadeu Lima de Souza Cascardo reported that 'chrt' broke on recent kernels:
      
        $ chrt -p $$
        chrt: failed to get pid 26306's policy: Argument list too long
      
      and he has root-caused the bug to the following commit increasing sched_attr
      size and breaking sched_read_attr() into returning -EFBIG:
      
        a509a7cd
      
       ("sched/uclamp: Extend sched_setattr() to support utilization clamping")
      
      The other, bigger bug is that the whole sched_getattr() and sched_read_attr()
      logic of checking non-zero bits in new ABI components is arguably broken,
      and pretty much any extension of the ABI will spuriously break the ABI.
      That's way too fragile.
      
      Instead implement the perf syscall's extensible ABI instead, which we
      already implement on the sched_setattr() side:
      
       - if user-attributes have the same size as kernel attributes then the
         logic is unchanged.
      
       - if user-attributes are larger than the kernel knows about then simply
         skip the extra bits, but set attr->size to the (smaller) kernel size
         so that tooling can (in principle) handle older kernel as well.
      
       - if user-attributes are smaller than the kernel knows about then just
         copy whatever user-space can accept.
      
      Also clean up the whole logic:
      
       - Simplify the code flow - there's no need for 'ret' for example.
      
       - Standardize on 'kattr/uattr' and 'ksize/usize' naming to make sure we
         always know which side we are dealing with.
      
       - Why is it called 'read' when what it does is to copy to user? This
         code is so far away from VFS read() semantics that the naming is
         actively confusing. Name it sched_attr_copy_to_user() instead, which
         mirrors other copy_to_user() functionality.
      
       - Move the attr->size assignment from the head of sched_getattr() to the
         sched_attr_copy_to_user() function. Nothing else within the kernel
         should care about the size of the structure.
      
      With these fixes the sched_getattr() syscall now nicely supports an
      extensible ABI in both a forward and backward compatible fashion, and
      will also fix the chrt bug.
      
      As an added bonus the bogus -EFBIG return is removed as well, which as
      Thadeu noted should have been -E2BIG to begin with.
      Reported-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Tested-by: Dietmar Eggemann's avatarDietmar Eggemann <dietmar.eggemann@arm.com>
      Tested-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Acked-by: default avatarThadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Patrick Bellasi <patrick.bellasi@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: a509a7cd ("sched/uclamp: Extend sched_setattr() to support utilization clamping")
      Link: https://lkml.kernel.org/r/20190904075532.GA26751@gmail.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      1251201c
    • Arnd Bergmann's avatar
      Merge tag 'renesas-fixes-for-v5.3' of... · d9a2b63c
      Arnd Bergmann authored
      Merge tag 'renesas-fixes-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into arm/fixes
      
      Renesas ARM Based SoC Fixes for v5.3
      
      * R-Car D3 (r8a77995) based Draak Board
        - Correct backlight regulator name in device tree
      
      * tag 'renesas-fixes-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas
      
      :
        arm64: dts: renesas: r8a77995: draak: Fix backlight regulator name
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d9a2b63c
    • Gustavo Romero's avatar
      powerpc/tm: Fix restoring FP/VMX facility incorrectly on interrupts · a8318c13
      Gustavo Romero authored
      When in userspace and MSR FP=0 the hardware FP state is unrelated to
      the current process. This is extended for transactions where if tbegin
      is run with FP=0, the hardware checkpoint FP state will also be
      unrelated to the current process. Due to this, we need to ensure this
      hardware checkpoint is updated with the correct state before we enable
      FP for this process.
      
      Unfortunately we get this wrong when returning to a process from a
      hardware interrupt. A process that starts a transaction with FP=0 can
      take an interrupt. When the kernel returns back to that process, we
      change to FP=1 but with hardware checkpoint FP state not updated. If
      this transaction is then rolled back, the FP registers now contain the
      wrong state.
      
      The process looks like this:
         Userspace:                      Kernel
      
                     Start userspace
                      with MSR FP=0 TM=1
                        < -----
         ...
         tbegin
         bne
                     Hardware interrupt
                         ---- >
                                          <do_IRQ...>
                                          ....
                                          ret_from_except
                                            restore_math()
      				        /* sees FP=0 */
                                              restore_fp()
                                                tm_active_with_fp()
      					    /* sees FP=1 (Incorrect) */
                                                load_fp_state()
                                              FP = 0 -> 1
                        < -----
                     Return to userspace
                       with MSR TM=1 FP=1
                       with junk in the FP TM checkpoint
         TM rollback
         reads FP junk
      
      When returning from the hardware exception, tm_active_with_fp() is
      incorrectly making restore_fp() call load_fp_state() which is setting
      FP=1.
      
      The fix is to remove tm_active_with_fp().
      
      tm_active_with_fp() is attempting to handle the case where FP state
      has been changed inside a transaction. In this case the checkpointed
      and transactional FP state is different and hence we must restore the
      FP state (ie. we can't do lazy FP restore inside a transaction that's
      used FP). It's safe to remove tm_active_with_fp() as this case is
      handled by restore_tm_state(). restore_tm_state() detects if FP has
      been using inside a transaction and will set load_fp and call
      restore_math() to ensure the FP state (checkpoint and transaction) is
      restored.
      
      This is a data integrity problem for the current process as the FP
      registers are corrupted. It's also a security problem as the FP
      registers from one process may be leaked to another.
      
      Similarly for VMX.
      
      A simple testcase to replicate this will be posted to
      tools/testing/selftests/powerpc/tm/tm-poison.c
      
      This fixes CVE-2019-15031.
      
      Fixes: a7771176
      
       ("powerpc: Don't enable FP/Altivec if not checkpointed")
      Cc: stable@vger.kernel.org # 4.15+
      Signed-off-by: default avatarGustavo Romero <gromero@linux.ibm.com>
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20190904045529.23002-2-gromero@linux.vnet.ibm.com
      a8318c13