Hi Greg,
Here is the backport of 3f29770723fe ("ipsec: check return value of
skb_to_sgvec always") for the 3.18, 4.4, and 4.9 trees, fixing the
warnings generated by 48a1df65334b ("skbuff: return -EMSGSIZE in
skb_to_sgvec to prevent overflow").
Let me know if there are any issues! First time using git send-email...
Nathan
The backport of 48a1df65334b ("skbuff: return -EMSGSIZE in skb_to_sgvec
to prevent overflow") was missing three supplemental commits:
3f29770723fe ("ipsec: check return value of skb_to_sgvec always")
89a5ea996625 ("rxrpc: check return value of skb_to_sgvec always")
e2fcad58fd23 ("virtio_net: check return value of skb_to_sgvec always")
I already sent the first one, this thread contains the other two for
3.18, 4.4, and 4.9. There is an additional patch because these trees do
not contain f6b10209b90d ("virtio-net: switch to use build_skb() for
small buffer"), which removed another call to skb_to_sgvec, which was
before f6b10209b90d. If you feel it should be squashed in f6b10209b90d,
please by all means feel free to do so. I was not 100% confident on if
the dev_kfree_skb call was necessary in the error path so I hope one of
the authors can comment on that.
Thanks!
Nathan
This is a note to let you know that I've just added the patch titled
xfrm: fix state migration copy replay sequence numbers
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfrm-fix-state-migration-copy-replay-sequence-numbers.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 13:58:07 CEST 2018
From: Antony Antony <antony(a)phenome.org>
Date: Fri, 19 May 2017 12:47:00 +0200
Subject: xfrm: fix state migration copy replay sequence numbers
From: Antony Antony <antony(a)phenome.org>
[ Upstream commit a486cd23661c9387fb076c3f6ae8b2aa9d20d54a ]
During xfrm migration copy replay and preplay sequence numbers
from the previous state.
Here is a tcpdump output showing the problem.
10.0.10.46 is running vanilla kernel, is the IKE/IPsec responder.
After the migration it sent wrong sequence number, reset to 1.
The migration is from 10.0.0.52 to 10.0.0.53.
IP 10.0.0.52.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7cf), length 136
IP 10.0.10.46.4500 > 10.0.0.52.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x7cf), length 136
IP 10.0.0.52.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d0), length 136
IP 10.0.10.46.4500 > 10.0.0.52.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x7d0), length 136
IP 10.0.0.53.4500 > 10.0.10.46.4500: NONESP-encap: isakmp: child_sa inf2[I]
IP 10.0.10.46.4500 > 10.0.0.53.4500: NONESP-encap: isakmp: child_sa inf2[R]
IP 10.0.0.53.4500 > 10.0.10.46.4500: NONESP-encap: isakmp: child_sa inf2[I]
IP 10.0.10.46.4500 > 10.0.0.53.4500: NONESP-encap: isakmp: child_sa inf2[R]
IP 10.0.0.53.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d1), length 136
NOTE: next sequence is wrong 0x1
IP 10.0.10.46.4500 > 10.0.0.53.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x1), length 136
IP 10.0.0.53.4500 > 10.0.10.46.4500: UDP-encap: ESP(spi=0x43ef462d,seq=0x7d2), length 136
IP 10.0.10.46.4500 > 10.0.0.53.4500: UDP-encap: ESP(spi=0xca1c282d,seq=0x2), length 136
Signed-off-by: Antony Antony <antony(a)phenome.org>
Reviewed-by: Richard Guy Briggs <rgb(a)tricolour.ca>
Signed-off-by: Steffen Klassert <steffen.klassert(a)secunet.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/xfrm/xfrm_state.c | 2 ++
1 file changed, 2 insertions(+)
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1208,6 +1208,8 @@ static struct xfrm_state *xfrm_state_clo
x->curlft.add_time = orig->curlft.add_time;
x->km.state = orig->km.state;
x->km.seq = orig->km.seq;
+ x->replay = orig->replay;
+ x->preplay = orig->preplay;
return x;
Patches currently in stable-queue which might be from antony(a)phenome.org are
queue-3.18/xfrm-fix-state-migration-copy-replay-sequence-numbers.patch
This is a note to let you know that I've just added the patch titled
xen: avoid type warning in xchg_xen_ulong
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xen-avoid-type-warning-in-xchg_xen_ulong.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 13:58:07 CEST 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 8 Jun 2017 10:53:10 +0200
Subject: xen: avoid type warning in xchg_xen_ulong
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 9cc91f212111cdcbefa02dcdb7dd443f224bf52c ]
The improved type-checking version of container_of() triggers a warning for
xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t
contains a signed value:
drivers/xen/events/events_2l.c: In function 'evtchn_2l_handle_events':
drivers/xen/events/events_2l.c:187:1020: error: call to '__compiletime_assert_187' declared with attribute error: pointer type mismatch in container_of()
This adds a cast to work around the warning.
Cc: Ian Abbott <abbotti(a)mev.co.uk>
Fixes: 85323a991d40 ("xen: arm: mandate EABI and use generic atomic operations.")
Fixes: daa2ac80834d ("kernel.h: handle pointers to arrays better in container_of()")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Stefano Stabellini <sstabellini(a)kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini(a)kernel.org>
Acked-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/include/asm/xen/events.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -16,7 +16,7 @@ static inline int xen_irqs_disabled(stru
return raw_irqs_disabled_flags(regs->ARM_cpsr);
}
-#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((ptr), \
+#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((long long*)(ptr),\
atomic64_t, \
counter), (val))
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-3.18/xen-avoid-type-warning-in-xchg_xen_ulong.patch
This is a note to let you know that I've just added the patch titled
x86/tsc: Provide 'tsc=unstable' boot parameter
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-tsc-provide-tsc-unstable-boot-parameter.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 13:58:07 CEST 2018
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Thu, 13 Apr 2017 14:56:44 +0200
Subject: x86/tsc: Provide 'tsc=unstable' boot parameter
From: Peter Zijlstra <peterz(a)infradead.org>
[ Upstream commit 8309f86cd41e8714526867177facf7a316d9be53 ]
Since the clocksource watchdog will only detect broken TSC after the
fact, all TSC based clocks will likely have observed non-continuous
values before/when switching away from TSC.
Therefore only thing to fully avoid random clock movement when your
BIOS randomly mucks with TSC values from SMI handlers is reporting the
TSC as unstable at boot.
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Mike Galbraith <efault(a)gmx.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-kernel(a)vger.kernel.org
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/tsc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -356,6 +356,8 @@ static int __init tsc_setup(char *str)
tsc_clocksource_reliable = 1;
if (!strncmp(str, "noirqtime", 9))
no_sched_irq_time = 1;
+ if (!strcmp(str, "unstable"))
+ mark_tsc_unstable("boot parameter");
return 1;
}
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-3.18/perf-core-correct-event-creation-with-perf_format_group.patch
queue-3.18/x86-tsc-provide-tsc-unstable-boot-parameter.patch
This is a note to let you know that I've just added the patch titled
wl1251: check return from call to wl1251_acx_arp_ip_filter
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 13:58:07 CEST 2018
From: Colin Ian King <colin.king(a)canonical.com>
Date: Tue, 26 Dec 2017 17:33:18 +0000
Subject: wl1251: check return from call to wl1251_acx_arp_ip_filter
From: Colin Ian King <colin.king(a)canonical.com>
[ Upstream commit ac1181c60822292176ab96912208ec9f9819faf8 ]
Currently the less than zero error check on ret is incorrect
as it is checking a far earlier ret assignment rather than the
return from the call to wl1251_acx_arp_ip_filter. Fix this by
adding in the missing assginment.
Detected by CoverityScan, CID#1164835 ("Logically dead code")
Fixes: 204cc5c44fb6 ("wl1251: implement hardware ARP filtering")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ti/wl1251/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -1200,8 +1200,7 @@ static void wl1251_op_bss_info_changed(s
WARN_ON(wl->bss_type != BSS_TYPE_STA_BSS);
enable = bss_conf->arp_addr_cnt == 1 && bss_conf->assoc;
- wl1251_acx_arp_ip_filter(wl, enable, addr);
-
+ ret = wl1251_acx_arp_ip_filter(wl, enable, addr);
if (ret < 0)
goto out_sleep;
}
Patches currently in stable-queue which might be from colin.king(a)canonical.com are
queue-3.18/wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch
queue-3.18/netxen_nic-set-rcode-to-the-return-status-from-the-call-to-netxen_issue_cmd.patch
queue-3.18/btrfs-fix-incorrect-error-return-ret-being-passed-to-mapping_set_error.patch
queue-3.18/ath5k-fix-memory-leak-on-buf-on-failed-eeprom-read.patch
This is a note to let you know that I've just added the patch titled
vmxnet3: ensure that adapter is in proper state during force_close
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
vmxnet3-ensure-that-adapter-is-in-proper-state-during-force_close.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 13:58:07 CEST 2018
From: Neil Horman <nhorman(a)tuxdriver.com>
Date: Fri, 12 May 2017 12:00:01 -0400
Subject: vmxnet3: ensure that adapter is in proper state during force_close
From: Neil Horman <nhorman(a)tuxdriver.com>
[ Upstream commit 1c4d5f51a812a82de97beee24f48ed05c65ebda5 ]
There are several paths in vmxnet3, where settings changes cause the
adapter to be brought down and back up (vmxnet3_set_ringparam among
them). Should part of the reset operation fail, these paths call
vmxnet3_force_close, which enables all napi instances prior to calling
dev_close (with the expectation that vmxnet3_close will then properly
disable them again). However, vmxnet3_force_close neglects to clear
VMXNET3_STATE_BIT_QUIESCED prior to calling dev_close. As a result
vmxnet3_quiesce_dev (called from vmxnet3_close), returns early, and
leaves all the napi instances in a enabled state while the device itself
is closed. If a device in this state is activated again, napi_enable
will be called on already enabled napi_instances, leading to a BUG halt.
The fix is to simply enausre that the QUIESCED bit is cleared in
vmxnet3_force_close to allow quesence to be completed properly on close.
Signed-off-by: Neil Horman <nhorman(a)tuxdriver.com>
CC: Shrikrishna Khare <skhare(a)vmware.com>
CC: "VMware, Inc." <pv-drivers(a)vmware.com>
CC: "David S. Miller" <davem(a)davemloft.net>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2648,6 +2648,11 @@ vmxnet3_force_close(struct vmxnet3_adapt
/* we need to enable NAPI, otherwise dev_close will deadlock */
for (i = 0; i < adapter->num_rx_queues; i++)
napi_enable(&adapter->rx_queue[i].napi);
+ /*
+ * Need to clear the quiesce bit to ensure that vmxnet3_close
+ * can quiesce the device properly
+ */
+ clear_bit(VMXNET3_STATE_BIT_QUIESCED, &adapter->state);
dev_close(adapter->netdev);
}
Patches currently in stable-queue which might be from nhorman(a)tuxdriver.com are
queue-3.18/vmxnet3-ensure-that-adapter-is-in-proper-state-during-force_close.patch
This is a note to let you know that I've just added the patch titled
vxlan: dont migrate permanent fdb entries during learn
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
vxlan-dont-migrate-permanent-fdb-entries-during-learn.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Tue Apr 10 13:58:07 CEST 2018
From: Roopa Prabhu <roopa(a)cumulusnetworks.com>
Date: Sun, 11 Jun 2017 16:32:50 -0700
Subject: vxlan: dont migrate permanent fdb entries during learn
From: Roopa Prabhu <roopa(a)cumulusnetworks.com>
[ Upstream commit e0090a9e979de5202c7d16c635dea2f005221073 ]
This patch fixes vxlan_snoop to not move permanent fdb entries
on learn events. This is consistent with the bridge fdb
handling of permanent entries.
Fixes: 26a41ae60438 ("vxlan: only migrate dynamic FDB entries")
Signed-off-by: Roopa Prabhu <roopa(a)cumulusnetworks.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -985,7 +985,7 @@ static bool vxlan_snoop(struct net_devic
return false;
/* Don't migrate static entries, drop packets */
- if (f->state & NUD_NOARP)
+ if (f->state & (NUD_PERMANENT | NUD_NOARP))
return true;
if (net_ratelimit())
Patches currently in stable-queue which might be from roopa(a)cumulusnetworks.com are
queue-3.18/vxlan-dont-migrate-permanent-fdb-entries-during-learn.patch
This is a note to let you know that I've just added the patch titled
virtio_net: check return value of skb_to_sgvec always
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
virtio_net-check-return-value-of-skb_to_sgvec-always.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e2fcad58fd230f635a74e4e983c6f4ea893642d2 Mon Sep 17 00:00:00 2001
From: "Jason A. Donenfeld" <Jason(a)zx2c4.com>
Date: Sun, 4 Jun 2017 04:16:26 +0200
Subject: virtio_net: check return value of skb_to_sgvec always
From: Jason A. Donenfeld <Jason(a)zx2c4.com>
commit e2fcad58fd230f635a74e4e983c6f4ea893642d2 upstream.
Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Cc: "Michael S. Tsirkin" <mst(a)redhat.com>
Cc: Jason Wang <jasowang(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
[natechancellor: backport to 3.18]
Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/virtio_net.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -854,7 +854,7 @@ static int xmit_skb(struct send_queue *s
struct skb_vnet_hdr *hdr;
const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
struct virtnet_info *vi = sq->vq->vdev->priv;
- unsigned num_sg;
+ int num_sg;
unsigned hdr_len;
bool can_push;
@@ -906,11 +906,16 @@ static int xmit_skb(struct send_queue *s
if (can_push) {
__skb_push(skb, hdr_len);
num_sg = skb_to_sgvec(skb, sq->sg, 0, skb->len);
+ if (unlikely(num_sg < 0))
+ return num_sg;
/* Pull header back to avoid skew in tx bytes calculations. */
__skb_pull(skb, hdr_len);
} else {
sg_set_buf(sq->sg, hdr, hdr_len);
- num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
+ num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len);
+ if (unlikely(num_sg < 0))
+ return num_sg;
+ num_sg++;
}
return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC);
}
Patches currently in stable-queue which might be from Jason(a)zx2c4.com are
queue-3.18/ipsec-check-return-value-of-skb_to_sgvec-always.patch
queue-3.18/skbuff-return-emsgsize-in-skb_to_sgvec-to-prevent-overflow.patch
queue-3.18/rxrpc-check-return-value-of-skb_to_sgvec-always.patch
queue-3.18/virtio_net-check-return-value-of-skb_to_sgvec-always.patch
queue-3.18/virtio_net-check-return-value-of-skb_to_sgvec-in-one-more-location.patch