[PATCH 3.2 0/4] 3.2.86-rc1 review

[PATCH 3.2 0/4] 3.2.86-rc1 review

[Ben Hutchings]

This is the start of the stable review cycle for the 3.2.86 release.
There are 4 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Feb 26 12:07:01 UTC 2017.
Anything received after that time might be too late.

A combined patch relative to 3.2.85 will be posted as an additional
response to this.  A shortlog and diffstat can be found below.

Ben.

-------------

Andrey Konovalov (1):
      dccp: fix freeing skb too early for IPV6_RECVPKTINFO
         [5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4]

Eric Dumazet (1):
      tcp: avoid infinite loop in tcp_splice_read()
         [ccf7abb93af09ad0868ae9033d1ca8108bdaec82]

Jim Mattson (1):
      kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)
         [ef85b67385436ddc1998f45f1d6a210f935b3388]

Johan Hovold (1):
      USB: serial: kl5kusb105: fix line-state error handling
         [146cc8a17a3b4996f6805ee5c080e7101277c410]

 Makefile                        |  4 ++--
 arch/x86/kvm/vmx.c              | 11 +++++------
 drivers/usb/serial/kl5kusb105.c |  9 +++++----
 net/dccp/input.c                |  3 ++-
 net/ipv4/tcp.c                  |  6 ++++++
 5 files changed, 20 insertions(+), 13 deletions(-)

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.

[PATCH 3.2 2/4] USB: serial: kl5kusb105: fix line-state error handling

[Ben Hutchings]

3.2.86-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Johan Hovold <johan@kernel.org>

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>
---
 drivers/usb/serial/kl5kusb105.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/usb/serial/kl5kusb105.c
+++ b/drivers/usb/serial/kl5kusb105.c
@@ -209,10 +209,11 @@ static int klsi_105_get_line_state(struc
 			     status_buf, KLSI_STATUSBUF_LEN,
 			     10000
 			     );
-	if (rc < 0)
-		dev_err(&port->dev, "Reading line status failed (error = %d)\n",
-			rc);
-	else {
+	if (rc != KLSI_STATUSBUF_LEN) {
+		dev_err(&port->dev, "reading line status failed: %d\n", rc);
+		if (rc >= 0)
+			rc = -EIO;
+	} else {
 		status = get_unaligned_le16(status_buf);
 
 		dev_info(&port->serial->dev->dev, "read status %x %x",

[PATCH 3.2 1/4] kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)

[Ben Hutchings]

3.2.86-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Jim Mattson <jmattson@google.com>

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>
---
 arch/x86/kvm/vmx.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -876,10 +876,10 @@ static inline bool nested_cpu_has_virtua
 	return vmcs12->pin_based_vm_exec_control & PIN_BASED_VIRTUAL_NMIS;
 }
 
-static inline bool is_exception(u32 intr_info)
+static inline bool is_nmi(u32 intr_info)
 {
 	return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VALID_MASK))
-		== (INTR_TYPE_HARD_EXCEPTION | INTR_INFO_VALID_MASK);
+		== (INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK);
 }
 
 static void nested_vmx_vmexit(struct kvm_vcpu *vcpu);
@@ -4225,7 +4225,7 @@ static int handle_exception(struct kvm_v
 		return 0;
 	}
 
-	if ((intr_info & INTR_INFO_INTR_TYPE_MASK) == INTR_TYPE_NMI_INTR)
+	if (is_nmi(intr_info))
 		return 1;  /* already handled by vmx_vcpu_run() */
 
 	if (is_no_device(intr_info)) {
@@ -5773,7 +5773,7 @@ static bool nested_vmx_exit_handled(stru
 
 	switch (exit_reason) {
 	case EXIT_REASON_EXCEPTION_NMI:
-		if (!is_exception(intr_info))
+		if (is_nmi(intr_info))
 			return 0;
 		else if (is_page_fault(intr_info))
 			return enable_ept;
@@ -5973,8 +5973,7 @@ static void vmx_complete_atomic_exit(str
 		kvm_machine_check();
 
 	/* We need to handle NMIs before interrupts are enabled */
-	if ((exit_intr_info & INTR_INFO_INTR_TYPE_MASK) == INTR_TYPE_NMI_INTR &&
-	    (exit_intr_info & INTR_INFO_VALID_MASK)) {
+	if (is_nmi(exit_intr_info)) {
 		kvm_before_handle_nmi(&vmx->vcpu);
 		asm("int $2");
 		kvm_after_handle_nmi(&vmx->vcpu);

[PATCH 3.2 4/4] tcp: avoid infinite loop in tcp_splice_read()

[Ben Hutchings]

3.2.86-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Eric Dumazet <edumazet@google.com>

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>
---
 net/ipv4/tcp.c | 6 ++++++
 1 file changed, 6 insertions(+)

--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -659,6 +659,12 @@ ssize_t tcp_splice_read(struct socket *s
 				ret = -EAGAIN;
 				break;
 			}
+			/* if __tcp_splice_read() got nothing while we have
+			 * an skb in receive queue, we do not want to loop.
+			 * This might happen with URG data.
+			 */
+			if (!skb_queue_empty(&sk->sk_receive_queue))
+				break;
 			sk_wait_data(sk, &timeo);
 			if (signal_pending(current)) {
 				ret = sock_intr_errno(timeo);

[PATCH 3.2 3/4] dccp: fix freeing skb too early for IPV6_RECVPKTINFO

[Ben Hutchings]

3.2.86-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Andrey Konovalov <andreyknvl@google.com>

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>
---
 net/dccp/input.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -606,7 +606,8 @@ int dccp_rcv_state_process(struct sock *
 			if (inet_csk(sk)->icsk_af_ops->conn_request(sk,
 								    skb) < 0)
 				return 1;
-			goto discard;
+			consume_skb(skb);
+			return 0;
 		}
 		if (dh->dccph_type == DCCP_PKT_RESET)
 			goto discard;

Re: [PATCH 3.2 0/4] 3.2.86-rc1 review

[Guenter Roeck]

On 02/24/2017 04:07 AM, Ben Hutchings wrote:
> This is the start of the stable review cycle for the 3.2.86 release.
> There are 4 patches in this series, which will be posted as responses
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Feb 26 12:07:01 UTC 2017.
> Anything received after that time might be too late.
>

Build results:
	total: 89 pass: 89 fail: 0
Qemu test results:
	total: 69 pass: 69 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 3.2 0/4] 3.2.86-rc1 review

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On Fri, 2017-02-24 at 08:18 -0800, Guenter Roeck wrote:
> On 02/24/2017 04:07 AM, Ben Hutchings wrote:
> > This is the start of the stable review cycle for the 3.2.86 release.
> > There are 4 patches in this series, which will be posted as responses
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Feb 26 12:07:01 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
> 	total: 89 pass: 89 fail: 0
> Qemu test results:
> 	total: 69 pass: 69 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing!

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]