commit 05900e83f51c597e0be6c2ca3f0e734097e3c96c
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Feb 26 20:01:33 2017 +0000

    Linux 3.2.86

commit cd3b9e464ca54547965df76463bdfb26e6712287
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 3 14:59:38 2017 -0800

    tcp: avoid infinite loop in tcp_splice_read()
    
    commit ccf7abb93af09ad0868ae9033d1ca8108bdaec82 upstream.
    
    Splicing from TCP socket is vulnerable when a packet with URG flag is
    received and stored into receive queue.
    
    __tcp_splice_read() returns 0, and sk_wait_data() immediately
    returns since there is the problematic skb in queue.
    
    This is a nice way to burn cpu (aka infinite loop) and trigger
    soft lockups.
    
    Again, this gem was found by syzkaller tool.
    
    Fixes: 9c55e01c0cc8 ("[TCP]: Splice receive support.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov  <dvyukov@google.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit fd75b79ea9c7cf89d5b95f9896c6b4dcdac8c4cb
Author: Andrey Konovalov <andreyknvl@google.com>
Date:   Thu Feb 16 17:22:46 2017 +0100

    dccp: fix freeing skb too early for IPV6_RECVPKTINFO
    
    commit 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 upstream.
    
    In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet
    is forcibly freed via __kfree_skb in dccp_rcv_state_process if
    dccp_v6_conn_request successfully returns.
    
    However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb
    is saved to ireq->pktopts and the ref count for skb is incremented in
    dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed
    in dccp_rcv_state_process.
    
    Fix by calling consume_skb instead of doing goto discard and therefore
    calling __kfree_skb.
    
    Similar fixes for TCP:
    
    fb7e2399ec17f1004c0e0ccfd17439f8759ede01 [TCP]: skb is unexpectedly freed.
    0aea76d35c9651d55bbaf746e7914e5f9ae5a25d tcp: SYN packets are now
    simply consumed
    
    Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit 70c3dd409057dfe3a5d3486a0600bba340aab664
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Jan 10 12:05:37 2017 +0100

    USB: serial: kl5kusb105: fix line-state error handling
    
    commit 146cc8a17a3b4996f6805ee5c080e7101277c410 upstream.
    
    The current implementation failed to detect short transfers when
    attempting to read the line state, and also, to make things worse,
    logged the content of the uninitialised heap transfer buffer.
    
    Fixes: abf492e7b3ae ("USB: kl5kusb105: fix DMA buffers on stack")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

commit b54f0df42fbd30cd1c6fdf4e72fd398b713a539e
Author: Jim Mattson <jmattson@google.com>
Date:   Mon Dec 12 11:01:37 2016 -0800

    kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)
    
    commit ef85b67385436ddc1998f45f1d6a210f935b3388 upstream.
    
    When L2 exits to L0 due to "exception or NMI", software exceptions
    (#BP and #OF) for which L1 has requested an intercept should be
    handled by L1 rather than L0. Previously, only hardware exceptions
    were forwarded to L1.
    
    Signed-off-by: Jim Mattson <jmattson@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    [bwh: Backported to 3.2: adjust context]
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>