1. 06 Jul, 2019 17 commits
  2. 05 Jul, 2019 21 commits
  3. 04 Jul, 2019 2 commits
    • Linus Torvalds's avatar
      Merge tag 'sound-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound · c212ddae
      Linus Torvalds authored
      Pull sound fixes from Takashi Iwai:
       "Here are a collection of small fixes for:
      
         - A race with ASoC HD-audio registration
      
         - LINE6 usb-audio memory overwrite by malformed descriptor
      
         - FireWire MIDI handling
      
         - Missing cast for bit shifts in a few USB-audio quirks
      
         - The wrong function calls in minor OSS sequencer code paths
      
         - A couple of HD-audio quirks"
      
      * tag 'sound-5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
        ALSA: line6: Fix write on zero-sized buffer
        ALSA: hda: Fix widget_mutex incomplete protection
        ALSA: firewire-lib/fireworks: fix miss detection of received MIDI messages
        ALSA: seq: fix incorrect order of dest_client/dest_ports arguments
        ALSA: hda/realtek - Change front mic location for Lenovo M710q
        ALSA: usb-audio: fix sign unintended sign extension on left shifts
        ALSA: hda/realtek: Add quirks for several Clevo notebook barebones
      c212ddae
    • 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