1. 04 Jul, 2019 3 commits
    • Jann Horn's avatar
      ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME · 6994eefb
      Jann Horn authored
      Fix two issues:
      
      When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU
      reference to the parent's objective credentials, then give that pointer
      to get_cred().  However, the object lifetime rules for things like
      struct cred do not permit unconditionally turning an RCU reference into
      a stable reference.
      
      PTRACE_TRACEME records the parent's credentials as if the parent was
      acting as the subject, but that's not the case.  If a malicious
      unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
      at a later point, the parent process becomes attacker-controlled
      (because it drops privileges and calls execve()), the attacker ends up
      with control over two processes with a privileged ptrace relationship,
      which can be abused to ptrace a suid binary and obtain root privileges.
      
      Fix both of these by always recording the credentials of the process
      that is requesting the creation of the ptrace relationship:
      current_cred() can't change under us, and current is the proper subject
      for access control.
      
      This change is theoretically userspace-visible, but I am not aware of
      any code that it will actually break.
      
      Fixes: 64b875f7 ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
      Signed-off-by: default avatarJann Horn <jannh@google.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6994eefb
    • Linus Torvalds's avatar
      Merge tag 'trace-v5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 550d1f5b
      Linus Torvalds authored
      Pull tracing fixes from Steven Rostedt:
       "This includes three fixes:
      
         - Fix a deadlock from a previous fix to keep module loading and
           function tracing text modifications from stepping on each other
           (this has a few patches to help document the issue in comments)
      
         - Fix a crash when the snapshot buffer gets out of sync with the main
           ring buffer
      
         - Fix a memory leak when reading the memory logs"
      
      * tag 'trace-v5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        ftrace/x86: Anotate text_mutex split between ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare()
        tracing/snapshot: Resize spare buffer if size changed
        tracing: Fix memory leak in tracing_err_log_open()
        ftrace/x86: Add a comment to why we take text_mutex in ftrace_arch_code_modify_prepare()
        ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()
      550d1f5b
    • Linus Torvalds's avatar
      Merge tag 'gpio-v5.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · 179c96d9
      Linus Torvalds authored
      Pull GPIO fix from Linus Walleij:
       "A single fixup for the SPI CS gpios that regressed in the current
        kernel cycle"
      
      * tag 'gpio-v5.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        gpio/spi: Fix spi-gpio regression on active high CS
      179c96d9
  2. 03 Jul, 2019 4 commits
  3. 02 Jul, 2019 2 commits
    • Linus Walleij's avatar
      gpio/spi: Fix spi-gpio regression on active high CS · fbbf145a
      Linus Walleij authored
      I ran into an intriguing bug caused by
      commit ""spi: gpio: Don't request CS GPIO in DT use-case"
      affecting all SPI GPIO devices with an active high
      chip select line.
      
      The commit switches the CS gpio handling over to the GPIO
      core, which will parse and handle "cs-gpios" from the OF
      node without even calling down to the driver to get the
      job done.
      
      However the GPIO core handles the standard bindings in
      Documentation/devicetree/bindings/spi/spi-controller.yaml
      that specifies that active high CS needs to be specified
      using "spi-cs-high" in the DT node.
      
      The code in drivers/spi/spi-gpio.c never respected this
      and never tried to inspect subnodes to see if they contained
      "spi-cs-high" like the gpiolib OF quirks does. Instead the
      only way to get an active high CS was to tag it in the
      device tree using the flags cell such as
      cs-gpios = <&gpio 4 GPIO_ACTIVE_HIGH>;
      
      This alters the quirks to not inspect the subnodes of SPI
      masters on "spi-gpio" for the standard attribute "spi-cs-high",
      making old device trees work as expected.
      
      This semantic is a bit ambigous, but just allowing the
      flags on the GPIO descriptor to modify polarity is what
      the kernel at large mostly uses so let's encourage that.
      
      Fixes: 249e2632 ("spi: gpio: Don't request CS GPIO in DT use-case")
      Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-spi@vger.kernel.org
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      fbbf145a
    • Jiri Kosina's avatar
      ftrace/x86: Anotate text_mutex split between... · 074376ac
      Jiri Kosina authored
      ftrace/x86: Anotate text_mutex split between ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare()
      
      ftrace_arch_code_modify_prepare() is acquiring text_mutex, while the
      corresponding release is happening in ftrace_arch_code_modify_post_process().
      
      This has already been documented in the code, but let's also make the fact
      that this is intentional clear to the semantic analysis tools such as sparse.
      
      Link: http://lkml.kernel.org/r/nycvar.YFH.7.76.1906292321170.27227@cbobk.fhfr.pm
      
      Fixes: 39611265 ("ftrace/x86: Add a comment to why we take text_mutex in ftrace_arch_code_modify_prepare()")
      Fixes: d5b844a2 ("ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()")
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      074376ac
  4. 01 Jul, 2019 1 commit
    • Christian Brauner's avatar
      fork: return proper negative error code · 28dd29c0
      Christian Brauner authored
      Make sure to return a proper negative error code from copy_process()
      when anon_inode_getfile() fails with CLONE_PIDFD.
      Otherwise _do_fork() will not detect an error and get_task_pid() will
      operator on a nonsensical pointer:
      
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dbc2c
      R13: 00007ffc15fbb0ff R14: 00007ff07e47e9c0 R15: 0000000000000000
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 7990 Comm: syz-executor290 Not tainted 5.2.0-rc6+ #9
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
      RIP: 0010:get_task_pid+0xe1/0x210 kernel/pid.c:372
      Code: 89 ff e8 62 27 5f 00 49 8b 07 44 89 f1 4c 8d bc c8 90 01 00 00 eb 0c
      e8 0d fe 25 00 49 81 c7 38 05 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 18 00 74
      08 4c 89 ff e8 31 27 5f 00 4d 8b 37 e8 f9 47 12 00
      RSP: 0018:ffff88808a4a7d78 EFLAGS: 00010203
      RAX: 00000000000000a7 RBX: dffffc0000000000 RCX: ffff888088180600
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
      RBP: ffff88808a4a7d90 R08: ffffffff814fb3a8 R09: ffffed1015d66bf8
      R10: ffffed1015d66bf8 R11: 1ffff11015d66bf7 R12: 0000000000041ffc
      R13: 1ffff11011494fbc R14: 0000000000000000 R15: 000000000000053d
      FS:  00007ff07e47e700(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004b5100 CR3: 0000000094df2000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        _do_fork+0x1b9/0x5f0 kernel/fork.c:2360
        __do_sys_clone kernel/fork.c:2454 [inline]
        __se_sys_clone kernel/fork.c:2448 [inline]
        __x64_sys_clone+0xc1/0xd0 kernel/fork.c:2448
        do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Link: https://lore.kernel.org/lkml/000000000000e0dc0d058c9e7142@google.com
      Reported-and-tested-by: syzbot+002e636502bc4b64eb5c@syzkaller.appspotmail.com
      Fixes: 6fd2fe49 ("copy_process(): don't use ksys_close() on cleanups")
      Cc: Jann Horn <jannh@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarChristian Brauner <christian@brauner.io>
      28dd29c0
  5. 30 Jun, 2019 3 commits
  6. 29 Jun, 2019 27 commits