1. 25 Apr, 2021 2 commits
  2. 24 Apr, 2021 3 commits
  3. 23 Apr, 2021 14 commits
  4. 22 Apr, 2021 7 commits
  5. 21 Apr, 2021 8 commits
  6. 20 Apr, 2021 5 commits
    • Linus Torvalds's avatar
      Merge tag 'trace-v5.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 1fe5501b
      Linus Torvalds authored
      Pull tracing fix from Steven Rostedt:
       "Fix tp_printk command line and trace events
      
        Masami added a wrapper to be able to unhash trace event pointers as
        they are only read by root anyway, and they can also be extracted by
        the raw trace data buffers. But this wrapper utilized the iterator to
        have a temporary buffer to manipulate the text with.
      
        tp_printk is a kernel command line option that will send the trace
        output of a trace event to the console on boot up (useful when the
        system crashes before finishing the boot). But the code used the same
        wrapper that Masami added, and its iterator did not have a buffer, and
        this caused the system to crash.
      
        Have the wrapper just print the trace event normally if the iterator
        has no temporary buffer"
      
      * tag 'trace-v5.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Fix checking event hash pointer logic when tp_printk is enabled
      1fe5501b
    • Serge E. Hallyn's avatar
      capabilities: require CAP_SETFCAP to map uid 0 · db2e718a
      Serge E. Hallyn authored
      cap_setfcap is required to create file capabilities.
      
      Since commit 8db6c34f ("Introduce v3 namespaced file capabilities"),
      a process running as uid 0 but without cap_setfcap is able to work
      around this as follows: unshare a new user namespace which maps parent
      uid 0 into the child namespace.
      
      While this task will not have new capabilities against the parent
      namespace, there is a loophole due to the way namespaced file
      capabilities are represented as xattrs.  File capabilities valid in
      userns 1 are distinguished from file capabilities valid in userns 2 by
      the kuid which underlies uid 0.  Therefore the restricted root process
      can unshare a new self-mapping namespace, add a namespaced file
      capability onto a file, then use that file capability in the parent
      namespace.
      
      To prevent that, do not allow mapping parent uid 0 if the process which
      opened the uid_map file does not have CAP_SETFCAP, which is the
      capability for setting file capabilities.
      
      As a further wrinkle: a task can unshare its user namespace, then open
      its uid_map file itself, and map (only) its own uid.  In this case we do
      not have the credential from before unshare, which was potentially more
      restricted.  So, when creating a user namespace, we record whether the
      creator had CAP_SETFCAP.  Then we can use that during map_write().
      
      With this patch:
      
      1. Unprivileged user can still unshare -Ur
      
         ubuntu@caps:~$ unshare -Ur
         root@caps:~# logout
      
      2. Root user can still unshare -Ur
      
         ubuntu@caps:~$ sudo bash
         root@caps:/home/ubuntu# unshare -Ur
         root@caps:/home/ubuntu# logout
      
      3. Root user without CAP_SETFCAP cannot unshare -Ur:
      
         root@caps:/home/ubuntu# /sbin/capsh --drop=cap_setfcap --
         root@caps:/home/ubuntu# /sbin/setcap cap_setfcap=p /sbin/setcap
         unable to set CAP_SETFCAP effective capability: Operation not permitted
         root@caps:/home/ubuntu# unshare -Ur
         unshare: write failed /proc/self/uid_map: Operation not permitted
      
      Note: an alternative solution would be to allow uid 0 mappings by
      processes without CAP_SETFCAP, but to prevent such a namespace from
      writing any file capabilities.  This approach can be seen at [1].
      
      Background history: commit 95ebabde ("capabilities: Don't allow
      writing ambiguous v3 file capabilities") tried to fix the issue by
      preventing v3 fscaps to be written to disk when the root uid would map
      to the same uid in nested user namespaces.  This led to regressions for
      various workloads.  For example, see [2].  Ultimately this is a valid
      use-case we have to support meaning we had to revert this change in
      3b0c2d3e ("Revert 95ebabde ("capabilities: Don't allow writing
      ambiguous v3 file capabilities")").
      
      Link: https://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git/log/?h=2021-04-15/setfcap-nsfscaps-v4 [1]
      Link: https://github.com/containers/buildah/issues/3071 [2]
      Signed-off-by: default avatarSerge Hallyn <serge@hallyn.com>
      Reviewed-by: default avatarAndrew G. Morgan <morgan@kernel.org>
      Tested-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      Reviewed-by: default avatarChristian Brauner <christian.brauner@ubuntu.com>
      Tested-by: default avatarGiuseppe Scrivano <gscrivan@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      db2e718a
    • Mike Galbraith's avatar
      x86/crash: Fix crash_setup_memmap_entries() out-of-bounds access · 5849cdf8
      Mike Galbraith authored
      Commit in Fixes: added support for kexec-ing a kernel on panic using a
      new system call. As part of it, it does prepare a memory map for the new
      kernel.
      
      However, while doing so, it wrongly accesses memory it has not
      allocated: it accesses the first element of the cmem->ranges[] array in
      memmap_exclude_ranges() but it has not allocated the memory for it in
      crash_setup_memmap_entries(). As KASAN reports:
      
        BUG: KASAN: vmalloc-out-of-bounds in crash_setup_memmap_entries+0x17e/0x3a0
        Write of size 8 at addr ffffc90000426008 by task kexec/1187
      
        (gdb) list *crash_setup_memmap_entries+0x17e
        0xffffffff8107cafe is in crash_setup_memmap_entries (arch/x86/kernel/crash.c:322).
        317                                      unsigned long long mend)
        318     {
        319             unsigned long start, end;
        320
        321             cmem->ranges[0].start = mstart;
        322             cmem->ranges[0].end = mend;
        323             cmem->nr_ranges = 1;
        324
        325             /* Exclude elf header region */
        326             start = image->arch.elf_load_addr;
        (gdb)
      
      Make sure the ranges array becomes a single element allocated.
      
       [ bp: Write a proper commit message. ]
      
      Fixes: dd5f7260 ("kexec: support for kexec on panic using new system call")
      Signed-off-by: default avatarMike Galbraith <efault@gmx.de>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarDave Young <dyoung@redhat.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/725fa3dc1da2737f0f6188a1a9701bead257ea9d.camel@gmx.de
      5849cdf8
    • Steven Rostedt (VMware)'s avatar
      tracing: Fix checking event hash pointer logic when tp_printk is enabled · 0e1e71d3
      Steven Rostedt (VMware) authored
      Pointers in events that are printed are unhashed if the flags allow it,
      and the logic to do so is called before processing the event output from
      the raw ring buffer. In most cases, this is done when a user reads one of
      the trace files.
      
      But if tp_printk is added on the kernel command line, this logic is done
      for trace events when they are triggered, and their output goes out via
      printk. The unhash logic (and even the validation of the output) did not
      support the tp_printk output, and would crash.
      
      Link: https://lore.kernel.org/linux-tegra/9835d9f1-8d3a-3440-c53f-516c2606ad07@nvidia.com/
      
      Fixes: efbbdaa2 ("tracing: Show real address for trace event arguments")
      Reported-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Tested-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      0e1e71d3
    • Rodrigo Vivi's avatar
      Merge tag 'gvt-fixes-2021-04-20' of https://github.com/intel/gvt-linux into drm-intel-fixes · 2d292995
      Rodrigo Vivi authored
      gvt-fixes-2021-04-20
      
      - Fix cmd parser regression on BDW (Zhenyu)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      From: Zhenyu Wang <zhenyuw@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210420023312.GL1551@zhen-hp.sh.intel.com
      2d292995
  7. 19 Apr, 2021 1 commit