3.18-stable patches

added patches:
	cfg80211-further-limit-wiphy-names-to-64-bytes.patch
	tcp-avoid-integer-overflows-in-tcp_rcv_space_adjust.patch

diff --git a/queue-3.18/cfg80211-further-limit-wiphy-names-to-64-bytes.patch b/queue-3.18/cfg80211-further-limit-wiphy-names-to-64-bytes.patch
new file mode 100644 (file)
index 0000000..e2520b4
--- /dev/null
+++ b/queue-3.18/cfg80211-further-limit-wiphy-names-to-64-bytes.patch
@@ -0,0 +1,41 @@
+From 814596495dd2b9d4aab92d8f89cf19060d25d2ea Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Mon, 14 May 2018 20:09:24 -0700
+Subject: cfg80211: further limit wiphy names to 64 bytes
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 814596495dd2b9d4aab92d8f89cf19060d25d2ea upstream.
+
+wiphy names were recently limited to 128 bytes by commit a7cfebcb7594
+("cfg80211: limit wiphy names to 128 bytes").  As it turns out though,
+this isn't sufficient because dev_vprintk_emit() needs the syslog header
+string "SUBSYSTEM=ieee80211\0DEVICE=+ieee80211:$devname" to fit into 128
+bytes.  This triggered the "device/subsystem name too long" WARN when
+the device name was >= 90 bytes.  As before, this was reproduced by
+syzbot by sending an HWSIM_CMD_NEW_RADIO command to the MAC80211_HWSIM
+generic netlink family.
+
+Fix it by further limiting wiphy names to 64 bytes.
+
+Reported-by: syzbot+e64565577af34b3768dc@syzkaller.appspotmail.com
+Fixes: a7cfebcb7594 ("cfg80211: limit wiphy names to 128 bytes")
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/uapi/linux/nl80211.h |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/uapi/linux/nl80211.h
++++ b/include/uapi/linux/nl80211.h
+@@ -2026,7 +2026,7 @@ enum nl80211_attrs {
+ #define NL80211_ATTR_KEYS NL80211_ATTR_KEYS
+ #define NL80211_ATTR_FEATURE_FLAGS NL80211_ATTR_FEATURE_FLAGS
+ 
+-#define NL80211_WIPHY_NAME_MAXLEN             128
++#define NL80211_WIPHY_NAME_MAXLEN             64
+ 
+ #define NL80211_MAX_SUPP_RATES                        32
+ #define NL80211_MAX_SUPP_HT_RATES             77

diff --git a/queue-3.18/series b/queue-3.18/series
index 9a76557ef044bb9a6b5e1b989f0ea72217c7bb68..0ac8e3af362a9abf7741f3bfd9b3192763a0755b 100644 (file)
--- a/queue-3.18/series
+++ b/queue-3.18/series
@@ -1,2 +1,4 @@
 tracing-fix-crash-when-freeing-instances-with-event-triggers.patch
 selinux-kasan-slab-out-of-bounds-in-xattr_getsecurity.patch
+cfg80211-further-limit-wiphy-names-to-64-bytes.patch
+tcp-avoid-integer-overflows-in-tcp_rcv_space_adjust.patch

diff --git a/queue-3.18/tcp-avoid-integer-overflows-in-tcp_rcv_space_adjust.patch b/queue-3.18/tcp-avoid-integer-overflows-in-tcp_rcv_space_adjust.patch
new file mode 100644 (file)
index 0000000..b0b6e68
--- /dev/null
+++ b/queue-3.18/tcp-avoid-integer-overflows-in-tcp_rcv_space_adjust.patch
@@ -0,0 +1,77 @@
+From 607065bad9931e72207b0cac365d7d4abc06bd99 Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Sun, 10 Dec 2017 17:55:03 -0800
+Subject: tcp: avoid integer overflows in tcp_rcv_space_adjust()
+
+From: Eric Dumazet <edumazet@google.com>
+
+commit 607065bad9931e72207b0cac365d7d4abc06bd99 upstream.
+
+When using large tcp_rmem[2] values (I did tests with 500 MB),
+I noticed overflows while computing rcvwin.
+
+Lets fix this before the following patch.
+
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
+Acked-by: Wei Wang <weiwan@google.com>
+Acked-by: Neal Cardwell <ncardwell@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+[Backport: sysctl_tcp_rmem is not Namespace-ify'd in older kernels]
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/tcp.h  |    2 +-
+ net/ipv4/tcp_input.c |   10 ++++++----
+ 2 files changed, 7 insertions(+), 5 deletions(-)
+
+--- a/include/linux/tcp.h
++++ b/include/linux/tcp.h
+@@ -292,7 +292,7 @@ struct tcp_sock {
+ 
+ /* Receiver queue space */
+       struct {
+-              int     space;
++              u32     space;
+               u32     seq;
+               u32     time;
+       } rcvq_space;
+--- a/net/ipv4/tcp_input.c
++++ b/net/ipv4/tcp_input.c
+@@ -550,8 +550,8 @@ static inline void tcp_rcv_rtt_measure_t
+ void tcp_rcv_space_adjust(struct sock *sk)
+ {
+       struct tcp_sock *tp = tcp_sk(sk);
++      u32 copied;
+       int time;
+-      int copied;
+ 
+       time = tcp_time_stamp - tp->rcvq_space.time;
+       if (time < (tp->rcv_rtt_est.rtt >> 3) || tp->rcv_rtt_est.rtt == 0)
+@@ -573,12 +573,13 @@ void tcp_rcv_space_adjust(struct sock *s
+ 
+       if (sysctl_tcp_moderate_rcvbuf &&
+           !(sk->sk_userlocks & SOCK_RCVBUF_LOCK)) {
+-              int rcvwin, rcvmem, rcvbuf;
++              int rcvmem, rcvbuf;
++              u64 rcvwin;
+ 
+               /* minimal window to cope with packet losses, assuming
+                * steady state. Add some cushion because of small variations.
+                */
+-              rcvwin = (copied << 1) + 16 * tp->advmss;
++              rcvwin = ((u64)copied << 1) + 16 * tp->advmss;
+ 
+               /* If rate increased by 25%,
+                *      assume slow start, rcvwin = 3 * copied
+@@ -598,7 +599,8 @@ void tcp_rcv_space_adjust(struct sock *s
+               while (tcp_win_from_space(rcvmem) < tp->advmss)
+                       rcvmem += 128;
+ 
+-              rcvbuf = min(rcvwin / tp->advmss * rcvmem, sysctl_tcp_rmem[2]);
++              do_div(rcvwin, tp->advmss);
++              rcvbuf = min_t(u64, rcvwin * rcvmem, sysctl_tcp_rmem[2]);
+               if (rcvbuf > sk->sk_rcvbuf) {
+                       sk->sk_rcvbuf = rcvbuf;
+