1. 20 Feb, 2013 35 commits
  2. 06 Feb, 2013 5 commits
    • Ben Hutchings's avatar
      Linux 3.2.38 · 8eedd520
      Ben Hutchings authored
      8eedd520
    • Alexandre SIMON's avatar
      printk: fix buffer overflow when calling log_prefix function from call_console_drivers · fed286bd
      Alexandre SIMON authored
      This patch corrects a buffer overflow in kernels from 3.0 to 3.4 when calling
      log_prefix() function from call_console_drivers().
      
      This bug existed in previous releases but has been revealed with commit
      162a7e75 (2.6.39 => 3.0) that made changes
      about how to allocate memory for early printk buffer (use of memblock_alloc).
      It disappears with commit 7ff9554b (3.4 => 3.5)
      that does a refactoring of printk buffer management.
      
      In log_prefix(), the access to "p[0]", "p[1]", "p[2]" or
      "simple_strtoul(&p[1], &endp, 10)" may cause a buffer overflow as this
      function is called from call_console_drivers by passing "&LOG_BUF(cur_index)"
      where the index must be masked to do not exceed the buffer's boundary.
      
      The trick is to prepare in call_console_drivers() a buffer with the necessary
      data (PRI field of syslog message) to be safely evaluated in log_prefix().
      
      This patch can be applied to stable kernel branches 3.0.y, 3.2.y and 3.4.y.
      
      Without this patch, one can freeze a server running this loop from shell :
        $ export DUMMY=`cat /dev/urandom | tr -dc '12345AZERTYUIOPQSDFGHJKLMWXCVBNazertyuiopqsdfghjklmwxcvbn' | head -c255`
        $ while true do ; echo $DUMMY > /dev/kmsg ; done
      
      The "server freeze" depends on where memblock_alloc does allocate printk buffer :
      if the buffer overflow is inside another kernel allocation the problem may not
      be revealed, else the server may hangs up.
      Signed-off-by: default avatarAlexandre SIMON <Alexandre.Simon@univ-lorraine.fr>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      fed286bd
    • Matt Fleming's avatar
      x86, efi: Set runtime_version to the EFI spec revision · cccd7d46
      Matt Fleming authored
      commit 712ba9e9 upstream.
      
      efi.runtime_version is erroneously being set to the value of the
      vendor's firmware revision instead of that of the implemented EFI
      specification. We can't deduce which EFI functions are available based
      on the revision of the vendor's firmware since the version scheme is
      likely to be unique to each vendor.
      
      What we really need to know is the revision of the implemented EFI
      specification, which is available in the EFI System Table header.
      
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cccd7d46
    • Bart Westgeest's avatar
      staging: usbip: changed function return type to void · 7d02c8e7
      Bart Westgeest authored
      commit ac2b41ac upstream.
      
      The function usbip_pad_iso never returns anything but 0 (success).
      Signed-off-by: default avatarBart Westgeest <bart@elbrys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7d02c8e7
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix regression by disconnection-race-fix patch · 6d3e269c
      Takashi Iwai authored
      [NOTE: the regression below is found only in 3.2-3.4 stable trees, so
             there is no upstream commit corresponding to this patch]
      
      The recent fix for the race at disconnection of usb-audio devices
      (upstream commit 978520b7) triggers Oops when a device is unplugged
      while playing on 3.2 and 3.4 kernels.  The culprit is that the
      shutdown flag check was wrongly added around the urb deactivation code
      snippet.  The urb deactivation code has to be performed even after the
      device disconnected.  Otherwise it remains undead and pokes the wild
      access in the end.
      
      The regression fix is simply reverting the shutdown flag check in that
      code.
      Reported-and-tested-by: default avatarChris J Arges <christopherarges@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      6d3e269c