1. 30 Apr, 2014 13 commits
  2. 09 Apr, 2014 19 commits
  3. 01 Apr, 2014 8 commits
    • Ben Hutchings's avatar
      Linux 3.2.56 · e08e9457
      Ben Hutchings authored
      e08e9457
    • Bjorn Helgaas's avatar
      PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled · f41b3d0b
      Bjorn Helgaas authored
      commit 3cdeb713 upstream.
      
      Andreas reported that after 1f42db78 ("PCI: Enable INTx if BIOS left
      them disabled"), pciehp surprise removal stopped working.
      
      This happens because pci_reenable_device() on the hotplug bridge (used in
      the pciehp_configure_device() path) clears the Interrupt Disable bit, which
      apparently breaks the bridge's MSI hotplug event reporting.
      
      Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
      which is used by both pci_enable_device() and pci_reenable_device().  But
      we use pci_reenable_device() after the driver may have enabled MSI or
      MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.
      
      This patch clears Interrupt Disable only when MSI/MSI-X has not been
      enabled.
      
      Fixes: 1f42db78 PCI: Enable INTx if BIOS left them disabled
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691Reported-and-tested-by: default avatarAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f41b3d0b
    • Konrad Rzeszutek Wilk's avatar
      intel_idle: Check cpu_idle_get_driver() for NULL before dereferencing it. · dcd8e204
      Konrad Rzeszutek Wilk authored
      commit 3735d524 upstream.
      
      If the machine is booted without any cpu_idle driver set
      (b/c disable_cpuidle() has been called) we should follow
      other users of cpu_idle API and check the return value
      for NULL before using it.
      Reported-and-tested-by: default avatarMark van Dijk <mark@internecto.net>
      Suggested-by: default avatarJan Beulich <JBeulich@suse.com>
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dcd8e204
    • Daniel Borkmann's avatar
      net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable · c7160985
      Daniel Borkmann authored
      [ Upstream commit ec0223ec ]
      
      RFC4895 introduced AUTH chunks for SCTP; during the SCTP
      handshake RANDOM; CHUNKS; HMAC-ALGO are negotiated (CHUNKS
      being optional though):
      
        ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
        <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
        -------------------- COOKIE-ECHO -------------------->
        <-------------------- COOKIE-ACK ---------------------
      
      A special case is when an endpoint requires COOKIE-ECHO
      chunks to be authenticated:
      
        ---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
        <------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
        ------------------ AUTH; COOKIE-ECHO ---------------->
        <-------------------- COOKIE-ACK ---------------------
      
      RFC4895, section 6.3. Receiving Authenticated Chunks says:
      
        The receiver MUST use the HMAC algorithm indicated in
        the HMAC Identifier field. If this algorithm was not
        specified by the receiver in the HMAC-ALGO parameter in
        the INIT or INIT-ACK chunk during association setup, the
        AUTH chunk and all the chunks after it MUST be discarded
        and an ERROR chunk SHOULD be sent with the error cause
        defined in Section 4.1. [...] If no endpoint pair shared
        key has been configured for that Shared Key Identifier,
        all authenticated chunks MUST be silently discarded. [...]
      
        When an endpoint requires COOKIE-ECHO chunks to be
        authenticated, some special procedures have to be followed
        because the reception of a COOKIE-ECHO chunk might result
        in the creation of an SCTP association. If a packet arrives
        containing an AUTH chunk as a first chunk, a COOKIE-ECHO
        chunk as the second chunk, and possibly more chunks after
        them, and the receiver does not have an STCB for that
        packet, then authentication is based on the contents of
        the COOKIE-ECHO chunk. In this situation, the receiver MUST
        authenticate the chunks in the packet by using the RANDOM
        parameters, CHUNKS parameters and HMAC_ALGO parameters
        obtained from the COOKIE-ECHO chunk, and possibly a local
        shared secret as inputs to the authentication procedure
        specified in Section 6.3. If authentication fails, then
        the packet is discarded. If the authentication is successful,
        the COOKIE-ECHO and all the chunks after the COOKIE-ECHO
        MUST be processed. If the receiver has an STCB, it MUST
        process the AUTH chunk as described above using the STCB
        from the existing association to authenticate the
        COOKIE-ECHO chunk and all the chunks after it. [...]
      
      Commit bbd0d598 introduced the possibility to receive
      and verification of AUTH chunk, including the edge case for
      authenticated COOKIE-ECHO. On reception of COOKIE-ECHO,
      the function sctp_sf_do_5_1D_ce() handles processing,
      unpacks and creates a new association if it passed sanity
      checks and also tests for authentication chunks being
      present. After a new association has been processed, it
      invokes sctp_process_init() on the new association and
      walks through the parameter list it received from the INIT
      chunk. It checks SCTP_PARAM_RANDOM, SCTP_PARAM_HMAC_ALGO
      and SCTP_PARAM_CHUNKS, and copies them into asoc->peer
      meta data (peer_random, peer_hmacs, peer_chunks) in case
      sysctl -w net.sctp.auth_enable=1 is set. If in INIT's
      SCTP_PARAM_SUPPORTED_EXT parameter SCTP_CID_AUTH is set,
      peer_random != NULL and peer_hmacs != NULL the peer is to be
      assumed asoc->peer.auth_capable=1, in any other case
      asoc->peer.auth_capable=0.
      
      Now, if in sctp_sf_do_5_1D_ce() chunk->auth_chunk is
      available, we set up a fake auth chunk and pass that on to
      sctp_sf_authenticate(), which at latest in
      sctp_auth_calculate_hmac() reliably dereferences a NULL pointer
      at position 0..0008 when setting up the crypto key in
      crypto_hash_setkey() by using asoc->asoc_shared_key that is
      NULL as condition key_id == asoc->active_key_id is true if
      the AUTH chunk was injected correctly from remote. This
      happens no matter what net.sctp.auth_enable sysctl says.
      
      The fix is to check for net->sctp.auth_enable and for
      asoc->peer.auth_capable before doing any operations like
      sctp_sf_authenticate() as no key is activated in
      sctp_auth_asoc_init_active_key() for each case.
      
      Now as RFC4895 section 6.3 states that if the used HMAC-ALGO
      passed from the INIT chunk was not used in the AUTH chunk, we
      SHOULD send an error; however in this case it would be better
      to just silently discard such a maliciously prepared handshake
      as we didn't even receive a parameter at all. Also, as our
      endpoint has no shared key configured, section 6.3 says that
      MUST silently discard, which we are doing from now onwards.
      
      Before calling sctp_sf_pdiscard(), we need not only to free
      the association, but also the chunk->auth_chunk skb, as
      commit bbd0d598 created a skb clone in that case.
      
      I have tested this locally by using netfilter's nfqueue and
      re-injecting packets into the local stack after maliciously
      modifying the INIT chunk (removing RANDOM; HMAC-ALGO param)
      and the SCTP packet containing the COOKIE_ECHO (injecting
      AUTH chunk before COOKIE_ECHO). Fixed with this patch applied.
      
      Fixes: bbd0d598 ("[SCTP]: Implement the receive and verification of AUTH chunk")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Vlad Yasevich <yasevich@gmail.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c7160985
    • Michael Chan's avatar
      tg3: Don't check undefined error bits in RXBD · 608532c1
      Michael Chan authored
      [ Upstream commit d7b95315 ]
      
      Redefine the RXD_ERR_MASK to include only relevant error bits. This fixes
      a customer reported issue of randomly dropping packets on the 5719.
      Signed-off-by: default avatarMichael Chan <mchan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      608532c1
    • Jason Wang's avatar
      virtio-net: alloc big buffers also when guest can receive UFO · ddc63f2b
      Jason Wang authored
      [ Upstream commit 0e7ede80 ]
      
      We should alloc big buffers also when guest can receive UFO
      packets to let the big packets fit into guest rx buffer.
      
      Fixes 5c516751
      (virtio-net: Allow UFO feature to be set and advertised.)
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Sridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ddc63f2b
    • Paul E. McKenney's avatar
      jiffies: Avoid undefined behavior from signed overflow · bc9664f1
      Paul E. McKenney authored
      commit 5a581b36 upstream.
      
      According to the C standard 3.4.3p3, overflow of a signed integer results
      in undefined behavior.  This commit therefore changes the definitions
      of time_after(), time_after_eq(), time_after64(), and time_after_eq64()
      to avoid this undefined behavior.  The trick is that the subtraction
      is done using unsigned arithmetic, which according to 6.2.5p9 cannot
      overflow because it is defined as modulo arithmetic.  This has the added
      (though admittedly quite small) benefit of shortening four lines of code
      by four characters each.
      
      Note that the C standard considers the cast from unsigned to
      signed to be implementation-defined, see 6.3.1.3p3.  However, on a
      two's-complement system, an implementation that defines anything other
      than a reinterpretation of the bits is free to come to me, and I will be
      happy to act as a witness for its being committed to an insane asylum.
      (Although I have nothing against saturating arithmetic or signals in some
      cases, these things really should not be the default when compiling an
      operating-system kernel.)
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Kevin Easton <kevin@guarana.org>
      [ paulmck: Included time_after64() and time_after_eq64(), as suggested
        by Eric Dumazet, also fixed commit message.]
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bc9664f1
    • Clemens Ladisch's avatar
      ALSA: oxygen: Xonar DG(X): modify DAC routing · 54a19ec5
      Clemens Ladisch authored
      commit 1f91ecc1 upstream.
      
      When selecting the audio output destinations (headphones, FP headphones,
      multichannel output), unnecessary I2S channels are digitally muted to
      avoid invalid signal levels on the other outputs.
      Signed-off-by: default avatarRoman Volkov <v1ron@mail.ru>
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      54a19ec5