Skip to content
  1. Mar 14, 2013
  2. Mar 13, 2013
  3. Mar 12, 2013
    • Al Viro's avatar
      vfs: fix pipe counter breakage · a930d879
      Al Viro authored
      
      
      If you open a pipe for neither read nor write, the pipe code will not
      add any usage counters to the pipe, causing the 'struct pipe_inode_info"
      to be potentially released early.
      
      That doesn't normally matter, since you cannot actually use the pipe,
      but the pipe release code - particularly fasync handling - still expects
      the actual pipe infrastructure to all be there.  And rather than adding
      NULL pointer checks, let's just disallow this case, the same way we
      already do for the named pipe ("fifo") case.
      
      This is ancient going back to pre-2.4 days, and until trinity, nobody
      naver noticed.
      
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a930d879
    • Arnd Bergmann's avatar
      ARM: spear3xx: Use correct pl080 header file · 27f423fe
      Arnd Bergmann authored
      
      
      The definitions have move around recently, causing build errors
      in spear3xx for all configurations:
      
      spear3xx.c:47:5: error: 'PL080_BSIZE_16' undeclared here (not in a function)
      spear3xx.c:47:23: error: 'PL080_CONTROL_SB_SIZE_SHIFT' undeclared here (not in a function)
      spear3xx.c:48:22: error: 'PL080_CONTROL_DB_SIZE_SHIFT' undeclared here (not in a function)
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Alessandro Rubini <rubini@gnudd.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      27f423fe
    • David Howells's avatar
      keys: fix race with concurrent install_user_keyrings() · 0da9dfdd
      David Howells authored
      
      
      This fixes CVE-2013-1792.
      
      There is a race in install_user_keyrings() that can cause a NULL pointer
      dereference when called concurrently for the same user if the uid and
      uid-session keyrings are not yet created.  It might be possible for an
      unprivileged user to trigger this by calling keyctl() from userspace in
      parallel immediately after logging in.
      
      Assume that we have two threads both executing lookup_user_key(), both
      looking for KEY_SPEC_USER_SESSION_KEYRING.
      
      	THREAD A			THREAD B
      	===============================	===============================
      					==>call install_user_keyrings();
      	if (!cred->user->session_keyring)
      	==>call install_user_keyrings()
      					...
      					user->uid_keyring = uid_keyring;
      	if (user->uid_keyring)
      		return 0;
      	<==
      	key = cred->user->session_keyring [== NULL]
      					user->session_keyring = session_keyring;
      	atomic_inc(&key->usage); [oops]
      
      At the point thread A dereferences cred->user->session_keyring, thread B
      hasn't updated user->session_keyring yet, but thread A assumes it is
      populated because install_user_keyrings() returned ok.
      
      The race window is really small but can be exploited if, for example,
      thread B is interrupted or preempted after initializing uid_keyring, but
      before doing setting session_keyring.
      
      This couldn't be reproduced on a stock kernel.  However, after placing
      systemtap probe on 'user->session_keyring = session_keyring;' that
      introduced some delay, the kernel could be crashed reliably.
      
      Fix this by checking both pointers before deciding whether to return.
      Alternatively, the test could be done away with entirely as it is checked
      inside the mutex - but since the mutex is global, that may not be the best
      way.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Reported-by: default avatarMateusz Guzik <mguzik@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      0da9dfdd
    • Sage Weil's avatar
      libceph: fix decoding of pgids · d6c0dd6b
      Sage Weil authored
      In 4f6a7e5e
      
       we effectively dropped support
      for the legacy encoding for the OSDMap and incremental.  However, we didn't
      fix the decoding for the pgid.
      
      Signed-off-by: default avatarSage Weil <sage@inktank.com>
      Reviewed-by: default avatarYehuda Sadeh <yehuda@inktank.com>
      d6c0dd6b
    • Padmavathi Venna's avatar
      Arm: socfpga: pl330: Add #dma-cells for generic dma binding support · 0d8abbfd
      Padmavathi Venna authored
      
      
      This patch adds #dma-cells property to PL330 DMA controller nodes for
      supporting generic dma dt bindings on SOCFPGA platform. #dma-channels
      and #dma-requests are not required now but added in advance.
      
      Signed-off-by: default avatarPadmavathi Venna <padma.v@samsung.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      0d8abbfd
    • Arnd Bergmann's avatar
      Merge tag 'mvebu_fixes_for_v3.9' of git://git.infradead.org/users/jcooper/linux into fixes · 75461523
      Arnd Bergmann authored
      mvebu fixes for v3.9 from Jason Cooper <jason@lakedaemon.net>:
      
      The first four patches:
      
        89c58c19 rtc: rtc-mv: Add support for clk to avoid lockups
        de88747f gpio: mvebu: Add clk support to prevent lockup
        7bf5b408 ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
        93fff4ce ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency
      
      are Cc'd to stable since they were held over from the previous merge window.
      
      The rest are a small collection of fixes and a couple of devicetree conversion
      catchups.
      
      * tag 'mvebu_fixes_for_v3.9' of git://git.infradead.org/users/jcooper/linux
      
      :
        arm: mach-orion5x: fix typo in compatible string of a .dts file
        arm: mvebu: fix address-cells in mpic DT node
        arm: plat-orion: fix address decoding when > 4GB is used
        arm: mvebu: Reduce reg-io-width with UARTs
        ARM: Dove: add RTC device node
        arm: mvebu: enable the USB ports on Armada 370 Reference Design board
        ARM: dove: drop "select COMMON_CLK_DOVE"
        rtc: rtc-mv: Add support for clk to avoid lockups
        gpio: mvebu: Add clk support to prevent lockup
        ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
        ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      75461523
    • Arnd Bergmann's avatar
      Merge tag 'imx-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes · 769aca03
      Arnd Bergmann authored
      From Shawn Guo <shawn.guo@linaro.org>:
      
      The 2nd take of imx fixes for 3.9:
       - Fix pll1_sys clk initial status
       - Fix a typo in imx DEBUG_LL Kconfig
      
      * tag 'imx-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6
      
      :
        ARM: imx: fix typo "DEBUG_IMX50_IMX53_UART"
        ARM: imx: pll1_sys should be an initial on clk
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      769aca03
    • Arnd Bergmann's avatar
      Merge tag 'mxs-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes · fc77b0e9
      Arnd Bergmann authored
      From Shawn Guo <shawn.guo@linaro.org>:
      
      The 2nd mxs fixes for 3.9:
       - Fix an error caused by incorrect conflict resolution when
         applying the patch
      
      * tag 'mxs-fixes-3.9-2' of git://git.linaro.org/people/shawnguo/linux-2.6
      
      :
        ARM: mxs: cfa10049: Fix fb initialisation function
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      fc77b0e9
    • Maxime Ripard's avatar
      ARM: multiplatform: Sort the max gpio numbers. · 2a6ad871
      Maxime Ripard authored
      
      
      When building a multiplatform kernel, we could end up with a smaller
      number of GPIOs than the one required by the platform the kernel was
      running on.
      
      Sort the max GPIO number by descending order so that we always take the
      highest number required.
      
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      2a6ad871