--- /dev/null
+From foo@baz Mon 27 Apr 2020 02:29:21 PM CEST
+From: John Haxby <john.haxby@oracle.com>
+Date: Sat, 18 Apr 2020 16:30:49 +0100
+Subject: ipv6: fix restrict IPV6_ADDRFORM operation
+
+From: John Haxby <john.haxby@oracle.com>
+
+[ Upstream commit 82c9ae440857840c56e05d4fb1427ee032531346 ]
+
+Commit b6f6118901d1 ("ipv6: restrict IPV6_ADDRFORM operation") fixed a
+problem found by syzbot an unfortunate logic error meant that it
+also broke IPV6_ADDRFORM.
+
+Rearrange the checks so that the earlier test is just one of the series
+of checks made before moving the socket from IPv6 to IPv4.
+
+Fixes: b6f6118901d1 ("ipv6: restrict IPV6_ADDRFORM operation")
+Signed-off-by: John Haxby <john.haxby@oracle.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/ipv6_sockglue.c | 13 ++++++-------
+ 1 file changed, 6 insertions(+), 7 deletions(-)
+
+--- a/net/ipv6/ipv6_sockglue.c
++++ b/net/ipv6/ipv6_sockglue.c
+@@ -185,15 +185,14 @@ static int do_ipv6_setsockopt(struct soc
+ retv = -EBUSY;
+ break;
+ }
+- } else if (sk->sk_protocol == IPPROTO_TCP) {
+- if (sk->sk_prot != &tcpv6_prot) {
+- retv = -EBUSY;
+- break;
+- }
+- break;
+- } else {
++ }
++ if (sk->sk_protocol == IPPROTO_TCP &&
++ sk->sk_prot != &tcpv6_prot) {
++ retv = -EBUSY;
+ break;
+ }
++ if (sk->sk_protocol != IPPROTO_TCP)
++ break;
+ if (sk->sk_state != TCP_ESTABLISHED) {
+ retv = -ENOTCONN;
+ break;
--- /dev/null
+From foo@baz Mon 27 Apr 2020 02:29:21 PM CEST
+From: Taehee Yoo <ap420073@gmail.com>
+Date: Mon, 20 Apr 2020 13:29:40 +0000
+Subject: macvlan: fix null dereference in macvlan_device_event()
+
+From: Taehee Yoo <ap420073@gmail.com>
+
+[ Upstream commit 4dee15b4fd0d61ec6bbd179238191e959d34cf7a ]
+
+In the macvlan_device_event(), the list_first_entry_or_null() is used.
+This function could return null pointer if there is no node.
+But, the macvlan module doesn't check the null pointer.
+So, null-ptr-deref would occur.
+
+ bond0
+ |
+ +----+-----+
+ | |
+macvlan0 macvlan1
+ | |
+ dummy0 dummy1
+
+The problem scenario.
+If dummy1 is removed,
+1. ->dellink() of dummy1 is called.
+2. NETDEV_UNREGISTER of dummy1 notification is sent to macvlan module.
+3. ->dellink() of macvlan1 is called.
+4. NETDEV_UNREGISTER of macvlan1 notification is sent to bond module.
+5. __bond_release_one() is called and it internally calls
+ dev_set_mac_address().
+6. dev_set_mac_address() calls the ->ndo_set_mac_address() of macvlan1,
+ which is macvlan_set_mac_address().
+7. macvlan_set_mac_address() calls the dev_set_mac_address() with dummy1.
+8. NETDEV_CHANGEADDR of dummy1 is sent to macvlan module.
+9. In the macvlan_device_event(), it calls list_first_entry_or_null().
+At this point, dummy1 and macvlan1 were removed.
+So, list_first_entry_or_null() will return NULL.
+
+Test commands:
+ ip netns add nst
+ ip netns exec nst ip link add bond0 type bond
+ for i in {0..10}
+ do
+ ip netns exec nst ip link add dummy$i type dummy
+ ip netns exec nst ip link add macvlan$i link dummy$i \
+ type macvlan mode passthru
+ ip netns exec nst ip link set macvlan$i master bond0
+ done
+ ip netns del nst
+
+Splat looks like:
+[ 40.585687][ T146] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP DEI
+[ 40.587249][ T146] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
+[ 40.588342][ T146] CPU: 1 PID: 146 Comm: kworker/u8:2 Not tainted 5.7.0-rc1+ #532
+[ 40.589299][ T146] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
+[ 40.590469][ T146] Workqueue: netns cleanup_net
+[ 40.591045][ T146] RIP: 0010:macvlan_device_event+0x4e2/0x900 [macvlan]
+[ 40.591905][ T146] Code: 00 00 00 00 00 fc ff df 80 3c 06 00 0f 85 45 02 00 00 48 89 da 48 b8 00 00 00 00 00 fc ff d2
+[ 40.594126][ T146] RSP: 0018:ffff88806116f4a0 EFLAGS: 00010246
+[ 40.594783][ T146] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
+[ 40.595653][ T146] RDX: 0000000000000000 RSI: ffff88806547ddd8 RDI: ffff8880540f1360
+[ 40.596495][ T146] RBP: ffff88804011a808 R08: fffffbfff4fb8421 R09: fffffbfff4fb8421
+[ 40.597377][ T146] R10: ffffffffa7dc2107 R11: 0000000000000000 R12: 0000000000000008
+[ 40.598186][ T146] R13: ffff88804011a000 R14: ffff8880540f1000 R15: 1ffff1100c22de9a
+[ 40.599012][ T146] FS: 0000000000000000(0000) GS:ffff888067800000(0000) knlGS:0000000000000000
+[ 40.600004][ T146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 40.600665][ T146] CR2: 00005572d3a807b8 CR3: 000000005fcf4003 CR4: 00000000000606e0
+[ 40.601485][ T146] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 40.602461][ T146] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 40.603443][ T146] Call Trace:
+[ 40.603871][ T146] ? nf_tables_dump_setelem+0xa0/0xa0 [nf_tables]
+[ 40.604587][ T146] ? macvlan_uninit+0x100/0x100 [macvlan]
+[ 40.605212][ T146] ? __module_text_address+0x13/0x140
+[ 40.605842][ T146] notifier_call_chain+0x90/0x160
+[ 40.606477][ T146] dev_set_mac_address+0x28e/0x3f0
+[ 40.607117][ T146] ? netdev_notify_peers+0xc0/0xc0
+[ 40.607762][ T146] ? __module_text_address+0x13/0x140
+[ 40.608440][ T146] ? notifier_call_chain+0x90/0x160
+[ 40.609097][ T146] ? dev_set_mac_address+0x1f0/0x3f0
+[ 40.609758][ T146] dev_set_mac_address+0x1f0/0x3f0
+[ 40.610402][ T146] ? __local_bh_enable_ip+0xe9/0x1b0
+[ 40.611071][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding]
+[ 40.611823][ T146] ? netdev_notify_peers+0xc0/0xc0
+[ 40.612461][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding]
+[ 40.613213][ T146] ? bond_hw_addr_flush+0x77/0x100 [bonding]
+[ 40.613963][ T146] ? __local_bh_enable_ip+0xe9/0x1b0
+[ 40.614631][ T146] ? bond_time_in_interval.isra.31+0x90/0x90 [bonding]
+[ 40.615484][ T146] ? __bond_release_one+0x9f0/0x12c0 [bonding]
+[ 40.616230][ T146] __bond_release_one+0x9f0/0x12c0 [bonding]
+[ 40.616949][ T146] ? bond_enslave+0x47c0/0x47c0 [bonding]
+[ 40.617642][ T146] ? lock_downgrade+0x730/0x730
+[ 40.618218][ T146] ? check_flags.part.42+0x450/0x450
+[ 40.618850][ T146] ? __mutex_unlock_slowpath+0xd0/0x670
+[ 40.619519][ T146] ? trace_hardirqs_on+0x30/0x180
+[ 40.620117][ T146] ? wait_for_completion+0x250/0x250
+[ 40.620754][ T146] bond_netdev_event+0x822/0x970 [bonding]
+[ 40.621460][ T146] ? __module_text_address+0x13/0x140
+[ 40.622097][ T146] notifier_call_chain+0x90/0x160
+[ 40.622806][ T146] rollback_registered_many+0x660/0xcf0
+[ 40.623522][ T146] ? netif_set_real_num_tx_queues+0x780/0x780
+[ 40.624290][ T146] ? notifier_call_chain+0x90/0x160
+[ 40.624957][ T146] ? netdev_upper_dev_unlink+0x114/0x180
+[ 40.625686][ T146] ? __netdev_adjacent_dev_unlink_neighbour+0x30/0x30
+[ 40.626421][ T146] ? mutex_is_locked+0x13/0x50
+[ 40.627016][ T146] ? unregister_netdevice_queue+0xf2/0x240
+[ 40.627663][ T146] unregister_netdevice_many.part.134+0x13/0x1b0
+[ 40.628362][ T146] default_device_exit_batch+0x2d9/0x390
+[ 40.628987][ T146] ? unregister_netdevice_many+0x40/0x40
+[ 40.629615][ T146] ? dev_change_net_namespace+0xcb0/0xcb0
+[ 40.630279][ T146] ? prepare_to_wait_exclusive+0x2e0/0x2e0
+[ 40.630943][ T146] ? ops_exit_list.isra.9+0x97/0x140
+[ 40.631554][ T146] cleanup_net+0x441/0x890
+[ ... ]
+
+Fixes: e289fd28176b ("macvlan: fix the problem when mac address changes for passthru mode")
+Reported-by: syzbot+5035b1f9dc7ea4558d5a@syzkaller.appspotmail.com
+Signed-off-by: Taehee Yoo <ap420073@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/macvlan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/macvlan.c
++++ b/drivers/net/macvlan.c
+@@ -1561,7 +1561,7 @@ static int macvlan_device_event(struct n
+ struct macvlan_dev,
+ list);
+
+- if (macvlan_sync_address(vlan->dev, dev->dev_addr))
++ if (vlan && macvlan_sync_address(vlan->dev, dev->dev_addr))
+ return NOTIFY_BAD;
+
+ break;
--- /dev/null
+From foo@baz Mon 27 Apr 2020 02:29:21 PM CEST
+From: Xiyu Yang <xiyuyang19@fudan.edu.cn>
+Date: Wed, 15 Apr 2020 16:36:19 +0800
+Subject: net: netrom: Fix potential nr_neigh refcnt leak in nr_add_node
+
+From: Xiyu Yang <xiyuyang19@fudan.edu.cn>
+
+[ Upstream commit d03f228470a8c0a22b774d1f8d47071e0de4f6dd ]
+
+nr_add_node() invokes nr_neigh_get_dev(), which returns a local
+reference of the nr_neigh object to "nr_neigh" with increased refcnt.
+
+When nr_add_node() returns, "nr_neigh" becomes invalid, so the refcount
+should be decreased to keep refcount balanced.
+
+The issue happens in one normal path of nr_add_node(), which forgets to
+decrease the refcnt increased by nr_neigh_get_dev() and causes a refcnt
+leak. It should decrease the refcnt before the function returns like
+other normal paths do.
+
+Fix this issue by calling nr_neigh_put() before the nr_add_node()
+returns.
+
+Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
+Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/netrom/nr_route.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/netrom/nr_route.c
++++ b/net/netrom/nr_route.c
+@@ -199,6 +199,7 @@ static int __must_check nr_add_node(ax25
+ /* refcount initialized at 1 */
+ spin_unlock_bh(&nr_node_list_lock);
+
++ nr_neigh_put(nr_neigh);
+ return 0;
+ }
+ nr_node_lock(nr_node);
--- /dev/null
+From foo@baz Mon 27 Apr 2020 02:29:21 PM CEST
+From: Xiyu Yang <xiyuyang19@fudan.edu.cn>
+Date: Thu, 23 Apr 2020 13:13:03 +0800
+Subject: net/x25: Fix x25_neigh refcnt leak when receiving frame
+
+From: Xiyu Yang <xiyuyang19@fudan.edu.cn>
+
+[ Upstream commit f35d12971b4d814cdb2f659d76b42f0c545270b6 ]
+
+x25_lapb_receive_frame() invokes x25_get_neigh(), which returns a
+reference of the specified x25_neigh object to "nb" with increased
+refcnt.
+
+When x25_lapb_receive_frame() returns, local variable "nb" becomes
+invalid, so the refcount should be decreased to keep refcount balanced.
+
+The reference counting issue happens in one path of
+x25_lapb_receive_frame(). When pskb_may_pull() returns false, the
+function forgets to decrease the refcnt increased by x25_get_neigh(),
+causing a refcnt leak.
+
+Fix this issue by calling x25_neigh_put() when pskb_may_pull() returns
+false.
+
+Fixes: cb101ed2c3c7 ("x25: Handle undersized/fragmented skbs")
+Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
+Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/x25/x25_dev.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/net/x25/x25_dev.c
++++ b/net/x25/x25_dev.c
+@@ -120,8 +120,10 @@ int x25_lapb_receive_frame(struct sk_buf
+ goto drop;
+ }
+
+- if (!pskb_may_pull(skb, 1))
++ if (!pskb_may_pull(skb, 1)) {
++ x25_neigh_put(nb);
+ return 0;
++ }
+
+ switch (skb->data[0]) {
+
s390-cio-avoid-duplicated-add-uevents.patch
pwm-renesas-tpu-fix-late-runtime-pm-enablement.patch
pwm-bcm2835-dynamically-allocate-base.patch
+ipv6-fix-restrict-ipv6_addrform-operation.patch
+macvlan-fix-null-dereference-in-macvlan_device_event.patch
+net-netrom-fix-potential-nr_neigh-refcnt-leak-in-nr_add_node.patch
+net-x25-fix-x25_neigh-refcnt-leak-when-receiving-frame.patch
+tcp-cache-line-align-max_tcp_header.patch
+team-fix-hang-in-team_mode_get.patch
+xfrm-always-set-xfrm_transformed-in-xfrm-4-6-_output_finish.patch
--- /dev/null
+From foo@baz Mon 27 Apr 2020 02:29:21 PM CEST
+From: Eric Dumazet <edumazet@google.com>
+Date: Fri, 17 Apr 2020 07:10:23 -0700
+Subject: tcp: cache line align MAX_TCP_HEADER
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit 9bacd256f1354883d3c1402655153367982bba49 ]
+
+TCP stack is dumb in how it cooks its output packets.
+
+Depending on MAX_HEADER value, we might chose a bad ending point
+for the headers.
+
+If we align the end of TCP headers to cache line boundary, we
+make sure to always use the smallest number of cache lines,
+which always help.
+
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Cc: Soheil Hassas Yeganeh <soheil@google.com>
+Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/tcp.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/net/tcp.h
++++ b/include/net/tcp.h
+@@ -52,7 +52,7 @@ extern struct inet_hashinfo tcp_hashinfo
+ extern struct percpu_counter tcp_orphan_count;
+ void tcp_time_wait(struct sock *sk, int state, int timeo);
+
+-#define MAX_TCP_HEADER (128 + MAX_HEADER)
++#define MAX_TCP_HEADER L1_CACHE_ALIGN(128 + MAX_HEADER)
+ #define MAX_TCP_OPTION_SPACE 40
+ #define TCP_MIN_SND_MSS 48
+ #define TCP_MIN_GSO_SIZE (TCP_MIN_SND_MSS - MAX_TCP_OPTION_SPACE)
--- /dev/null
+From foo@baz Mon 27 Apr 2020 02:29:21 PM CEST
+From: Taehee Yoo <ap420073@gmail.com>
+Date: Mon, 20 Apr 2020 15:01:33 +0000
+Subject: team: fix hang in team_mode_get()
+
+From: Taehee Yoo <ap420073@gmail.com>
+
+[ Upstream commit 1c30fbc76b8f0c07c92a8ca4cd7c456612e17eb5 ]
+
+When team mode is changed or set, the team_mode_get() is called to check
+whether the mode module is inserted or not. If the mode module is not
+inserted, it calls the request_module().
+In the request_module(), it creates a child process, which is
+the "modprobe" process and waits for the done of the child process.
+At this point, the following locks were used.
+down_read(&cb_lock()); by genl_rcv()
+ genl_lock(); by genl_rcv_msc()
+ rtnl_lock(); by team_nl_cmd_options_set()
+ mutex_lock(&team->lock); by team_nl_team_get()
+
+Concurrently, the team module could be removed by rmmod or "modprobe -r"
+The __exit function of team module is team_module_exit(), which calls
+team_nl_fini() and it tries to acquire following locks.
+down_write(&cb_lock);
+ genl_lock();
+Because of the genl_lock() and cb_lock, this process can't be finished
+earlier than request_module() routine.
+
+The problem secenario.
+CPU0 CPU1
+team_mode_get
+ request_module()
+ modprobe -r team_mode_roundrobin
+ team <--(B)
+ modprobe team <--(A)
+ team_mode_roundrobin
+
+By request_module(), the "modprobe team_mode_roundrobin" command
+will be executed. At this point, the modprobe process will decide
+that the team module should be inserted before team_mode_roundrobin.
+Because the team module is being removed.
+
+By the module infrastructure, the same module insert/remove operations
+can't be executed concurrently.
+So, (A) waits for (B) but (B) also waits for (A) because of locks.
+So that the hang occurs at this point.
+
+Test commands:
+ while :
+ do
+ teamd -d &
+ killall teamd &
+ modprobe -rv team_mode_roundrobin &
+ done
+
+The approach of this patch is to hold the reference count of the team
+module if the team module is compiled as a module. If the reference count
+of the team module is not zero while request_module() is being called,
+the team module will not be removed at that moment.
+So that the above scenario could not occur.
+
+Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
+Signed-off-by: Taehee Yoo <ap420073@gmail.com>
+Reviewed-by: Jiri Pirko <jiri@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/team/team.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/net/team/team.c
++++ b/drivers/net/team/team.c
+@@ -466,6 +466,9 @@ static const struct team_mode *team_mode
+ struct team_mode_item *mitem;
+ const struct team_mode *mode = NULL;
+
++ if (!try_module_get(THIS_MODULE))
++ return NULL;
++
+ spin_lock(&mode_list_lock);
+ mitem = __find_mode(kind);
+ if (!mitem) {
+@@ -481,6 +484,7 @@ static const struct team_mode *team_mode
+ }
+
+ spin_unlock(&mode_list_lock);
++ module_put(THIS_MODULE);
+ return mode;
+ }
+
--- /dev/null
+From foo@baz Mon 27 Apr 2020 02:29:21 PM CEST
+From: David Ahern <dsahern@gmail.com>
+Date: Mon, 20 Apr 2020 17:13:51 -0600
+Subject: xfrm: Always set XFRM_TRANSFORMED in xfrm{4,6}_output_finish
+
+From: David Ahern <dsahern@gmail.com>
+
+[ Upstream commit 0c922a4850eba2e668f73a3f1153196e09abb251 ]
+
+IPSKB_XFRM_TRANSFORMED and IP6SKB_XFRM_TRANSFORMED are skb flags set by
+xfrm code to tell other skb handlers that the packet has been passed
+through the xfrm output functions. Simplify the code and just always
+set them rather than conditionally based on netfilter enabled thus
+making the flag available for other users.
+
+Signed-off-by: David Ahern <dsahern@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/xfrm4_output.c | 2 --
+ net/ipv6/xfrm6_output.c | 2 --
+ 2 files changed, 4 deletions(-)
+
+--- a/net/ipv4/xfrm4_output.c
++++ b/net/ipv4/xfrm4_output.c
+@@ -75,9 +75,7 @@ int xfrm4_output_finish(struct sock *sk,
+ {
+ memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
+
+-#ifdef CONFIG_NETFILTER
+ IPCB(skb)->flags |= IPSKB_XFRM_TRANSFORMED;
+-#endif
+
+ return xfrm_output(sk, skb);
+ }
+--- a/net/ipv6/xfrm6_output.c
++++ b/net/ipv6/xfrm6_output.c
+@@ -125,9 +125,7 @@ int xfrm6_output_finish(struct sock *sk,
+ {
+ memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
+
+-#ifdef CONFIG_NETFILTER
+ IP6CB(skb)->flags |= IP6SKB_XFRM_TRANSFORMED;
+-#endif
+
+ return xfrm_output(sk, skb);
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
