4.19-stable patches

added patches:
	ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch
	seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch
	udp-using-datalen-to-cap-max-gso-segments.patch

diff --git a/queue-4.19/ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch b/queue-4.19/ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch
new file mode 100644 (file)
index 0000000..830ef1a
--- /dev/null
+++ b/queue-4.19/ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch
@@ -0,0 +1,35 @@
+From 9292f8f9a2ac42eb320bced7153aa2e63d8cc13a Mon Sep 17 00:00:00 2001
+From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
+Date: Mon, 29 Nov 2021 14:19:52 -0500
+Subject: IB/hfi1: Correct guard on eager buffer deallocation
+
+From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
+
+commit 9292f8f9a2ac42eb320bced7153aa2e63d8cc13a upstream.
+
+The code tests the dma address which legitimately can be 0.
+
+The code should test the kernel logical address to avoid leaking eager
+buffer allocations that happen to map to a dma address of 0.
+
+Fixes: 60368186fd85 ("IB/hfi1: Fix user-space buffers mapping with IOMMU enabled")
+Link: https://lore.kernel.org/r/20211129191952.101968.17137.stgit@awfm-01.cornelisnetworks.com
+Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/hfi1/init.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/hfi1/init.c
++++ b/drivers/infiniband/hw/hfi1/init.c
+@@ -1146,7 +1146,7 @@ void hfi1_free_ctxtdata(struct hfi1_devd
+       rcd->egrbufs.rcvtids = NULL;
+ 
+       for (e = 0; e < rcd->egrbufs.alloced; e++) {
+-              if (rcd->egrbufs.buffers[e].dma)
++              if (rcd->egrbufs.buffers[e].addr)
+                       dma_free_coherent(&dd->pcidev->dev,
+                                         rcd->egrbufs.buffers[e].len,
+                                         rcd->egrbufs.buffers[e].addr,

diff --git a/queue-4.19/seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch b/queue-4.19/seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch
new file mode 100644 (file)
index 0000000..d87aadd
--- /dev/null
+++ b/queue-4.19/seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch
@@ -0,0 +1,63 @@
+From ae68d93354e5bf5191ee673982251864ea24dd5c Mon Sep 17 00:00:00 2001
+From: Andrea Mayer <andrea.mayer@uniroma2.it>
+Date: Wed, 8 Dec 2021 20:54:09 +0100
+Subject: seg6: fix the iif in the IPv6 socket control block
+
+From: Andrea Mayer <andrea.mayer@uniroma2.it>
+
+commit ae68d93354e5bf5191ee673982251864ea24dd5c upstream.
+
+When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving
+interface index into the IPv4 socket control block (v5.16-rc4,
+net/ipv4/ip_input.c line 510):
+
+    IPCB(skb)->iif = skb->skb_iif;
+
+If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH
+header, the seg6_do_srh_encap(...) performs the required encapsulation.
+In this case, the seg6_do_srh_encap function clears the IPv6 socket control
+block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):
+
+    memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
+
+The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear
+IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29).
+
+Since the IPv6 socket control block and the IPv4 socket control block share
+the same memory area (skb->cb), the receiving interface index info is lost
+(IP6CB(skb)->iif is set to zero).
+
+As a side effect, that condition triggers a NULL pointer dereference if
+commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig
+netdev") is applied.
+
+To fix that issue, we set the IP6CB(skb)->iif with the index of the
+receiving interface once again.
+
+Fixes: ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation")
+Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://lore.kernel.org/r/20211208195409.12169-1-andrea.mayer@uniroma2.it
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/seg6_iptunnel.c |    8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/net/ipv6/seg6_iptunnel.c
++++ b/net/ipv6/seg6_iptunnel.c
+@@ -148,6 +148,14 @@ int seg6_do_srh_encap(struct sk_buff *sk
+               hdr->hop_limit = ip6_dst_hoplimit(skb_dst(skb));
+ 
+               memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
++
++              /* the control block has been erased, so we have to set the
++               * iif once again.
++               * We read the receiving interface index directly from the
++               * skb->skb_iif as it is done in the IPv4 receiving path (i.e.:
++               * ip_rcv_core(...)).
++               */
++              IP6CB(skb)->iif = skb->skb_iif;
+       }
+ 
+       hdr->nexthdr = NEXTHDR_ROUTING;

diff --git a/queue-4.19/series b/queue-4.19/series
index 630ba7000c26b679e41ee50152802b0bfb1709e3..e140b37905f781bd09572ed8968f037f4227c01f 100644 (file)
--- a/queue-4.19/series
+++ b/queue-4.19/series
@@ -17,3 +17,6 @@ bpf-fix-the-off-by-two-error-in-range-markings.patch
 ice-ignore-dropped-packets-during-init.patch
 bonding-make-tx_rebalance_counter-an-atomic.patch
 nfp-fix-memory-leak-in-nfp_cpp_area_cache_add.patch
+seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch
+udp-using-datalen-to-cap-max-gso-segments.patch
+ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch

diff --git a/queue-4.19/udp-using-datalen-to-cap-max-gso-segments.patch b/queue-4.19/udp-using-datalen-to-cap-max-gso-segments.patch
new file mode 100644 (file)
index 0000000..1037e6c
--- /dev/null
+++ b/queue-4.19/udp-using-datalen-to-cap-max-gso-segments.patch
@@ -0,0 +1,41 @@
+From 158390e45612ef0fde160af0826f1740c36daf21 Mon Sep 17 00:00:00 2001
+From: Jianguo Wu <wujianguo@chinatelecom.cn>
+Date: Wed, 8 Dec 2021 18:03:33 +0800
+Subject: udp: using datalen to cap max gso segments
+
+From: Jianguo Wu <wujianguo@chinatelecom.cn>
+
+commit 158390e45612ef0fde160af0826f1740c36daf21 upstream.
+
+The max number of UDP gso segments is intended to cap to UDP_MAX_SEGMENTS,
+this is checked in udp_send_skb():
+
+    if (skb->len > cork->gso_size * UDP_MAX_SEGMENTS) {
+        kfree_skb(skb);
+        return -EINVAL;
+    }
+
+skb->len contains network and transport header len here, we should use
+only data len instead.
+
+Fixes: bec1f6f69736 ("udp: generate gso with UDP_SEGMENT")
+Signed-off-by: Jianguo Wu <wujianguo@chinatelecom.cn>
+Reviewed-by: Willem de Bruijn <willemb@google.com>
+Link: https://lore.kernel.org/r/900742e5-81fb-30dc-6e0b-375c6cdd7982@163.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/udp.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ipv4/udp.c
++++ b/net/ipv4/udp.c
+@@ -798,7 +798,7 @@ static int udp_send_skb(struct sk_buff *
+                       kfree_skb(skb);
+                       return -EINVAL;
+               }
+-              if (skb->len > cork->gso_size * UDP_MAX_SEGMENTS) {
++              if (datalen > cork->gso_size * UDP_MAX_SEGMENTS) {
+                       kfree_skb(skb);
+                       return -EINVAL;
+               }