1. 20 Feb, 2013 36 commits
  2. 06 Feb, 2013 4 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