1. 24 Mar, 2014 17 commits
    • Johannes Berg's avatar
      mac80211: clear sequence/fragment number in QoS-null frames · 30f754e9
      Johannes Berg authored
      commit 864a6040 upstream.
      
      Avoid leaking data by sending uninitialized memory and setting an
      invalid (non-zero) fragment number (the sequence number is ignored
      anyway) by setting the seq_ctrl field to zero.
      
      Fixes: 3f52b7e3 ("mac80211: mesh power save basics")
      Fixes: ce662b44 ("mac80211: send (QoS) Null if no buffered frames")
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30f754e9
    • Johannes Berg's avatar
      mac80211: fix association to 20/40 MHz VHT networks · c02d9a96
      Johannes Berg authored
      commit cb664981 upstream.
      
      When a VHT network uses 20 or 40 MHz as per the HT operation
      information, the channel center frequency segment 0 field in
      the VHT operation information is reserved, so ignore it.
      
      This fixes association with such networks when the AP puts 0
      into the field, previously we'd disconnect due to an invalid
      channel with the message
      wlan0: AP VHT information is invalid, disable VHT
      
      Fixes: f2d9d270 ("mac80211: support VHT association")
      Reported-by: default avatarTim Nelson <tim.l.nelson@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c02d9a96
    • Johannes Berg's avatar
      mac80211: don't validate unchanged AP bandwidth while tracking · e713fe3d
      Johannes Berg authored
      commit 963a1852 upstream.
      
      The MLME code in mac80211 must track whether or not the AP changed
      bandwidth, but if there's no change while tracking it shouldn't do
      anything, otherwise regulatory updates can make it impossible to
      connect to certain APs if the regulatory database doesn't match the
      information from the AP. See the precise scenario described in the
      code.
      
      This still leaves some possible problems with CSA or if the AP
      actually changed bandwidth, but those cases are less common and
      won't completely prevent using it.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=70881Reported-and-tested-by: default avatarNate Carlson <kernel@natecarlson.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e713fe3d
    • Emmanuel Grumbach's avatar
      mac80211: fix AP powersave TX vs. wakeup race · a7ee1a84
      Emmanuel Grumbach authored
      commit 1d147bfa upstream.
      
      There is a race between the TX path and the STA wakeup: while
      a station is sleeping, mac80211 buffers frames until it wakes
      up, then the frames are transmitted. However, the RX and TX
      path are concurrent, so the packet indicating wakeup can be
      processed while a packet is being transmitted.
      
      This can lead to a situation where the buffered frames list
      is emptied on the one side, while a frame is being added on
      the other side, as the station is still seen as sleeping in
      the TX path.
      
      As a result, the newly added frame will not be send anytime
      soon. It might be sent much later (and out of order) when the
      station goes to sleep and wakes up the next time.
      
      Additionally, it can lead to the crash below.
      
      Fix all this by synchronising both paths with a new lock.
      Both path are not fastpath since they handle PS situations.
      
      In a later patch we'll remove the extra skb queue locks to
      reduce locking overhead.
      
      BUG: unable to handle kernel
      NULL pointer dereference at 000000b0
      IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
      *pde = 00000000
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
      EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
      EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
      ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
      DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      DR6: ffff0ff0 DR7: 00000400
      Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
      iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
      Stack:
       e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
       ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
       ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
      Call Trace:
       [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
       [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
       [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
       [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
       [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
       [<c149ef70>] dev_hard_start_xmit+0x450/0x950
       [<c14b9aa9>] sch_direct_xmit+0xa9/0x250
       [<c14b9c9b>] __qdisc_run+0x4b/0x150
       [<c149f732>] dev_queue_xmit+0x2c2/0xca0
      Reported-by: default avatarYaara Rozenblum <yaara.rozenblum@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      [reword commit log, use a separate lock]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a7ee1a84
    • Felix Fietkau's avatar
      mac80211: send control port protocol frames to the VO queue · b59ed9d7
      Felix Fietkau authored
      commit 1bf4bbb4 upstream.
      
      Improves reliability of wifi connections with WPA, since authentication
      frames are prioritized over normal traffic and also typically exempt
      from aggregation.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b59ed9d7
    • Daniel Borkmann's avatar
      net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable · 892b46a6
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      892b46a6
    • Michael Chan's avatar
      tg3: Don't check undefined error bits in RXBD · e16d4982
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e16d4982
    • Hans Schillstrom's avatar
      ipv6: ipv6_find_hdr restore prev functionality · d1f7dd4e
      Hans Schillstrom authored
      [ Upstream commit accfe0e3 ]
      
      The commit 9195bb8e ("ipv6: improve
      ipv6_find_hdr() to skip empty routing headers") broke ipv6_find_hdr().
      
      When a target is specified like IPPROTO_ICMPV6 ipv6_find_hdr()
      returns -ENOENT when it's found, not the header as expected.
      
      A part of IPVS is broken and possible also nft_exthdr_eval().
      When target is -1 which it is most cases, it works.
      
      This patch exits the do while loop if the specific header is found
      so the nexthdr could be returned as expected.
      Reported-by: default avatarArt -kwaak- van Breemen <ard@telegraafnet.nl>
      Signed-off-by: default avatarHans Schillstrom <hans@schillstrom.com>
      CC:Ansis Atteka <aatteka@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1f7dd4e
    • Edward Cree's avatar
      sfc: check for NULL efx->ptp_data in efx_ptp_event · 43800d3e
      Edward Cree authored
      [ Upstream commit 8f355e5c ]
      
      If we receive a PTP event from the NIC when we haven't set up PTP state
      in the driver, we attempt to read through a NULL pointer efx->ptp_data,
      triggering a panic.
      Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
      Acked-by: default avatarShradha Shah <sshah@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43800d3e
    • Hannes Frederic Sowa's avatar
      ipv6: reuse ip6_frag_id from ip6_ufo_append_data · 150d6bdb
      Hannes Frederic Sowa authored
      [ Upstream commit 916e4cf4 ]
      
      Currently we generate a new fragmentation id on UFO segmentation. It
      is pretty hairy to identify the correct net namespace and dst there.
      Especially tunnels use IFF_XMIT_DST_RELEASE and thus have no skb_dst
      available at all.
      
      This causes unreliable or very predictable ipv6 fragmentation id
      generation while segmentation.
      
      Luckily we already have pregenerated the ip6_frag_id in
      ip6_ufo_append_data and can use it here.
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      150d6bdb
    • Jason Wang's avatar
      virtio-net: alloc big buffers also when guest can receive UFO · 73c99258
      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 avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73c99258
    • Duan Jiong's avatar
      neigh: recompute reachabletime before returning from neigh_periodic_work() · 913cfa94
      Duan Jiong authored
      [ Upstream commit feff9ab2 ]
      
      If the neigh table's entries is less than gc_thresh1, the function
      will return directly, and the reachabletime will not be recompute,
      so the reachabletime can be guessed.
      Signed-off-by: default avatarDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      913cfa94
    • Eric Dumazet's avatar
      net-tcp: fastopen: fix high order allocations · fe42b170
      Eric Dumazet authored
      [ Upstream commit f5ddcbbb ]
      
      This patch fixes two bugs in fastopen :
      
      1) The tcp_sendmsg(...,  @size) argument was ignored.
      
         Code was relying on user not fooling the kernel with iovec mismatches
      
      2) When MTU is about 64KB, tcp_send_syn_data() attempts order-5
      allocations, which are likely to fail when memory gets fragmented.
      
      Fixes: 783237e8 ("net-tcp: Fast Open client - sending SYN-data")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Tested-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe42b170
    • Alexandre Bounine's avatar
      rapidio/tsi721: fix tasklet termination in dma channel release · dabdb40f
      Alexandre Bounine authored
      commit 04379dff upstream.
      
      This patch is a modification of the patch originally proposed by
      Xiaotian Feng <xtfeng@gmail.com>: https://lkml.org/lkml/2012/11/5/413
      This new version disables DMA channel interrupts and ensures that the
      tasklet wil not be scheduled again before calling tasklet_kill().
      
      Unfortunately the updated patch was not released at that time due to
      planned rework of Tsi721 mport driver to use threaded interrupts (which
      has yet to happen).  Recently the issue was reported again:
      https://lkml.org/lkml/2014/2/19/762.
      
      Description from the original Xiaotian's patch:
      
       "Some drivers use tasklet_disable in device remove/release process,
        tasklet_disable will inc tasklet->count and return.  If the tasklet is
        not handled yet under some softirq pressure, the tasklet will be
        placed on the tasklet_vec, never have a chance to be excuted.  This
        might lead to a heavy loaded ksoftirqd, wakeup with pending_softirq,
        but tasklet is disabled.  tasklet_kill should be used in this case."
      
      This patch is applicable to kernel versions starting from v3.5.
      Signed-off-by: default avatarAlexandre Bounine <alexandre.bounine@idt.com>
      Cc: Matt Porter <mporter@kernel.crashing.org>
      Cc: Xiaotian Feng <xtfeng@gmail.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Mike Galbraith <bitbucket@online.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dabdb40f
    • George McCollister's avatar
      sched: Fix double normalization of vruntime · 84bb5b64
      George McCollister authored
      commit 791c9e02 upstream.
      
      dequeue_entity() is called when p->on_rq and sets se->on_rq = 0
      which appears to guarentee that the !se->on_rq condition is met.
      If the task has done set_current_state(TASK_INTERRUPTIBLE) without
      schedule() the second condition will be met and vruntime will be
      incorrectly adjusted twice.
      
      In certain cases this can result in the task's vruntime never increasing
      past the vruntime of other tasks on the CFS' run queue, starving them of
      CPU time.
      
      This patch changes switched_from_fair() to use !p->on_rq instead of
      !se->on_rq.
      
      I'm able to cause a task with a priority of 120 to starve all other
      tasks with the same priority on an ARM platform running 3.2.51-rt72
      PREEMPT RT by writing one character at time to a serial tty (16550 UART)
      in a tight loop. I'm also able to verify making this change corrects the
      problem on that platform and kernel version.
      Signed-off-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1392767811-28916-1-git-send-email-george.mccollister@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84bb5b64
    • Al Viro's avatar
      ocfs2 syncs the wrong range... · 52ed96fc
      Al Viro authored
      commit 1b56e989 upstream.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      52ed96fc
    • Jan Kara's avatar
      ocfs2: fix quota file corruption · 3e8e7736
      Jan Kara authored
      commit 15c34a76 upstream.
      
      Global quota files are accessed from different nodes.  Thus we cannot
      cache offset of quota structure in the quota file after we drop our node
      reference count to it because after that moment quota structure may be
      freed and reallocated elsewhere by a different node resulting in
      corruption of quota file.
      
      Fix the problem by clearing dq_off when we are releasing dquot structure.
      We also remove the DB_READ_B handling because it is useless -
      DQ_ACTIVE_B is set iff DQ_READ_B is set.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: Goldwyn Rodrigues <rgoldwyn@suse.de>
      Cc: Joel Becker <jlbec@evilplan.org>
      Reviewed-by: default avatarMark Fasheh <mfasheh@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e8e7736
  2. 07 Mar, 2014 23 commits