--- /dev/null
+From foo@baz Sat Oct 24 11:00:25 AM CEST 2020
+From: Eric Dumazet <edumazet@google.com>
+Date: Thu, 15 Oct 2020 11:42:00 -0700
+Subject: icmp: randomize the global rate limiter
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit b38e7819cae946e2edf869e604af1e65a5d241c5 ]
+
+Keyu Man reported that the ICMP rate limiter could be used
+by attackers to get useful signal. Details will be provided
+in an upcoming academic publication.
+
+Our solution is to add some noise, so that the attackers
+no longer can get help from the predictable token bucket limiter.
+
+Fixes: 4cdf507d5452 ("icmp: add a global rate limitation")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: Keyu Man <kman001@ucr.edu>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/networking/ip-sysctl.txt | 4 +++-
+ net/ipv4/icmp.c | 7 +++++--
+ 2 files changed, 8 insertions(+), 3 deletions(-)
+
+--- a/Documentation/networking/ip-sysctl.txt
++++ b/Documentation/networking/ip-sysctl.txt
+@@ -887,12 +887,14 @@ icmp_ratelimit - INTEGER
+ icmp_msgs_per_sec - INTEGER
+ Limit maximal number of ICMP packets sent per second from this host.
+ Only messages whose type matches icmp_ratemask (see below) are
+- controlled by this limit.
++ controlled by this limit. For security reasons, the precise count
++ of messages per second is randomized.
+ Default: 1000
+
+ icmp_msgs_burst - INTEGER
+ icmp_msgs_per_sec controls number of ICMP packets sent per second,
+ while icmp_msgs_burst controls the burst size of these packets.
++ For security reasons, the precise burst size is randomized.
+ Default: 50
+
+ icmp_ratemask - INTEGER
+--- a/net/ipv4/icmp.c
++++ b/net/ipv4/icmp.c
+@@ -246,7 +246,7 @@ static struct {
+ /**
+ * icmp_global_allow - Are we allowed to send one more ICMP message ?
+ *
+- * Uses a token bucket to limit our ICMP messages to sysctl_icmp_msgs_per_sec.
++ * Uses a token bucket to limit our ICMP messages to ~sysctl_icmp_msgs_per_sec.
+ * Returns false if we reached the limit and can not send another packet.
+ * Note: called with BH disabled
+ */
+@@ -274,7 +274,10 @@ bool icmp_global_allow(void)
+ }
+ credit = min_t(u32, icmp_global.credit + incr, sysctl_icmp_msgs_burst);
+ if (credit) {
+- credit--;
++ /* We want to use a credit of one in average, but need to randomize
++ * it for security reasons.
++ */
++ credit = max_t(int, credit - prandom_u32_max(3), 0);
+ rc = true;
+ }
+ WRITE_ONCE(icmp_global.credit, credit);
--- /dev/null
+From foo@baz Sat Oct 24 11:17:56 AM CEST 2020
+From: Xie He <xie.he.0141@gmail.com>
+Date: Mon, 19 Oct 2020 18:31:52 -0700
+Subject: net: hdlc: In hdlc_rcv, check to make sure dev is an HDLC device
+
+From: Xie He <xie.he.0141@gmail.com>
+
+[ Upstream commit 01c4ceae0a38a0bdbfea6896f41efcd985a9c064 ]
+
+The hdlc_rcv function is used as hdlc_packet_type.func to process any
+skb received in the kernel with skb->protocol == htons(ETH_P_HDLC).
+The purpose of this function is to provide second-stage processing for
+skbs not assigned a "real" L3 skb->protocol value in the first stage.
+
+This function assumes the device from which the skb is received is an
+HDLC device (a device created by this module). It assumes that
+netdev_priv(dev) returns a pointer to "struct hdlc_device".
+
+However, it is possible that some driver in the kernel (not necessarily
+in our control) submits a received skb with skb->protocol ==
+htons(ETH_P_HDLC), from a non-HDLC device. In this case, the skb would
+still be received by hdlc_rcv. This will cause problems.
+
+hdlc_rcv should be able to recognize and drop invalid skbs. It should
+first make sure "dev" is actually an HDLC device, before starting its
+processing. This patch adds this check to hdlc_rcv.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: Krzysztof Halasa <khc@pm.waw.pl>
+Signed-off-by: Xie He <xie.he.0141@gmail.com>
+Link: https://lore.kernel.org/r/20201020013152.89259-1-xie.he.0141@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wan/hdlc.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wan/hdlc.c
++++ b/drivers/net/wan/hdlc.c
+@@ -57,7 +57,15 @@ int hdlc_change_mtu(struct net_device *d
+ static int hdlc_rcv(struct sk_buff *skb, struct net_device *dev,
+ struct packet_type *p, struct net_device *orig_dev)
+ {
+- struct hdlc_device *hdlc = dev_to_hdlc(dev);
++ struct hdlc_device *hdlc;
++
++ /* First make sure "dev" is an HDLC device */
++ if (!(dev->priv_flags & IFF_WAN_HDLC)) {
++ kfree_skb(skb);
++ return NET_RX_SUCCESS;
++ }
++
++ hdlc = dev_to_hdlc(dev);
+
+ if (!net_eq(dev_net(dev), &init_net)) {
+ kfree_skb(skb);
--- /dev/null
+From foo@baz Sat Oct 24 11:17:56 AM CEST 2020
+From: Xie He <xie.he.0141@gmail.com>
+Date: Mon, 19 Oct 2020 23:34:20 -0700
+Subject: net: hdlc_raw_eth: Clear the IFF_TX_SKB_SHARING flag after calling ether_setup
+
+From: Xie He <xie.he.0141@gmail.com>
+
+[ Upstream commit 5fce1e43e2d5bf2f7e3224d7b99b1c65ab2c26e2 ]
+
+This driver calls ether_setup to set up the network device.
+The ether_setup function would add the IFF_TX_SKB_SHARING flag to the
+device. This flag indicates that it is safe to transmit shared skbs to
+the device.
+
+However, this is not true. This driver may pad the frame (in eth_tx)
+before transmission, so the skb may be modified.
+
+Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared")
+Cc: Neil Horman <nhorman@tuxdriver.com>
+Cc: Krzysztof Halasa <khc@pm.waw.pl>
+Signed-off-by: Xie He <xie.he.0141@gmail.com>
+Link: https://lore.kernel.org/r/20201020063420.187497-1-xie.he.0141@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wan/hdlc_raw_eth.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wan/hdlc_raw_eth.c
++++ b/drivers/net/wan/hdlc_raw_eth.c
+@@ -101,6 +101,7 @@ static int raw_eth_ioctl(struct net_devi
+ old_qlen = dev->tx_queue_len;
+ ether_setup(dev);
+ dev->tx_queue_len = old_qlen;
++ dev->priv_flags &= ~IFF_TX_SKB_SHARING;
+ eth_hw_addr_random(dev);
+ call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE, dev);
+ netif_dormant_off(dev);
--- /dev/null
+From foo@baz Sat Oct 24 11:17:56 AM CEST 2020
+From: Defang Bo <bodefang@126.com>
+Date: Mon, 19 Oct 2020 19:38:58 +0800
+Subject: nfc: Ensure presence of NFC_ATTR_FIRMWARE_NAME attribute in nfc_genl_fw_download()
+
+From: Defang Bo <bodefang@126.com>
+
+[ Upstream commit 280e3ebdafb863b3cb50d5842f056267e15bf40c ]
+
+Check that the NFC_ATTR_FIRMWARE_NAME attributes are provided by
+the netlink client prior to accessing them.This prevents potential
+unhandled NULL pointer dereference exceptions which can be triggered
+by malicious user-mode programs, if they omit one or both of these
+attributes.
+
+Similar to commit a0323b979f81 ("nfc: Ensure presence of required attributes in the activate_target handler").
+
+Fixes: 9674da8759df ("NFC: Add firmware upload netlink command")
+Signed-off-by: Defang Bo <bodefang@126.com>
+Link: https://lore.kernel.org/r/1603107538-4744-1-git-send-email-bodefang@126.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/nfc/netlink.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/nfc/netlink.c
++++ b/net/nfc/netlink.c
+@@ -1227,7 +1227,7 @@ static int nfc_genl_fw_download(struct s
+ u32 idx;
+ char firmware_name[NFC_FIRMWARE_NAME_MAXSIZE + 1];
+
+- if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
++ if (!info->attrs[NFC_ATTR_DEVICE_INDEX] || !info->attrs[NFC_ATTR_FIRMWARE_NAME])
+ return -EINVAL;
+
+ idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
net-ipv4-always-honour-route-mtu-during-forwarding.patch
r8169-fix-data-corruption-issue-on-rtl8402.patch
alsa-bebob-potential-info-leak-in-hwdep_read.patch
+net-hdlc-in-hdlc_rcv-check-to-make-sure-dev-is-an-hdlc-device.patch
+net-hdlc_raw_eth-clear-the-iff_tx_skb_sharing-flag-after-calling-ether_setup.patch
+nfc-ensure-presence-of-nfc_attr_firmware_name-attribute-in-nfc_genl_fw_download.patch
+tcp-fix-to-update-snd_wl1-in-bulk-receiver-fast-path.patch
+icmp-randomize-the-global-rate-limiter.patch
--- /dev/null
+From foo@baz Sat Oct 24 11:17:56 AM CEST 2020
+From: Neal Cardwell <ncardwell@google.com>
+Date: Thu, 22 Oct 2020 10:33:31 -0400
+Subject: tcp: fix to update snd_wl1 in bulk receiver fast path
+
+From: Neal Cardwell <ncardwell@google.com>
+
+[ Upstream commit 18ded910b589839e38a51623a179837ab4cc3789 ]
+
+In the header prediction fast path for a bulk data receiver, if no
+data is newly acknowledged then we do not call tcp_ack() and do not
+call tcp_ack_update_window(). This means that a bulk receiver that
+receives large amounts of data can have the incoming sequence numbers
+wrap, so that the check in tcp_may_update_window fails:
+ after(ack_seq, tp->snd_wl1)
+
+If the incoming receive windows are zero in this state, and then the
+connection that was a bulk data receiver later wants to send data,
+that connection can find itself persistently rejecting the window
+updates in incoming ACKs. This means the connection can persistently
+fail to discover that the receive window has opened, which in turn
+means that the connection is unable to send anything, and the
+connection's sending process can get permanently "stuck".
+
+The fix is to update snd_wl1 in the header prediction fast path for a
+bulk data receiver, so that it keeps up and does not see wrapping
+problems.
+
+This fix is based on a very nice and thorough analysis and diagnosis
+by Apollon Oikonomopoulos (see link below).
+
+This is a stable candidate but there is no Fixes tag here since the
+bug predates current git history. Just for fun: looks like the bug
+dates back to when header prediction was added in Linux v2.1.8 in Nov
+1996. In that version tcp_rcv_established() was added, and the code
+only updates snd_wl1 in tcp_ack(), and in the new "Bulk data transfer:
+receiver" code path it does not call tcp_ack(). This fix seems to
+apply cleanly at least as far back as v3.2.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Neal Cardwell <ncardwell@google.com>
+Reported-by: Apollon Oikonomopoulos <apoikos@dmesg.gr>
+Tested-by: Apollon Oikonomopoulos <apoikos@dmesg.gr>
+Link: https://www.spinics.net/lists/netdev/msg692430.html
+Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
+Acked-by: Yuchung Cheng <ycheng@google.com>
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/r/20201022143331.1887495-1-ncardwell.kernel@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/tcp_input.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/ipv4/tcp_input.c
++++ b/net/ipv4/tcp_input.c
+@@ -5598,6 +5598,8 @@ void tcp_rcv_established(struct sock *sk
+ tcp_data_snd_check(sk);
+ if (!inet_csk_ack_scheduled(sk))
+ goto no_ack;
++ } else {
++ tcp_update_wl(tp, TCP_SKB_CB(skb)->seq);
+ }
+
+ __tcp_ack_snd_check(sk, 0);
projects / thirdparty / kernel / stable-queue.git / commitdiff
