commit 05900e83f51c597e0be6c2ca3f0e734097e3c96c Author: Ben Hutchings Date: Sun Feb 26 20:01:33 2017 +0000 Linux 3.2.86 commit cd3b9e464ca54547965df76463bdfb26e6712287 Author: Eric Dumazet 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 Reported-by: Dmitry Vyukov Cc: Willy Tarreau Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit fd75b79ea9c7cf89d5b95f9896c6b4dcdac8c4cb Author: Andrey Konovalov 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 Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 70c3dd409057dfe3a5d3486a0600bba340aab664 Author: Johan Hovold 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 Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit b54f0df42fbd30cd1c6fdf4e72fd398b713a539e Author: Jim Mattson 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 Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings