This is a note to let you know that I've just added the patch titled
ip6_tunnel: better validate user provided tunnel names
to the 4.14-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:
ip6_tunnel-better-validate-user-provided-tunnel-names.patch
and it can be found in the queue-4.14 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 23:20:08 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Thu, 5 Apr 2018 06:39:30 -0700
Subject: ip6_tunnel: better validate user provided tunnel names
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit db7a65e3ab78e5b1c4b17c0870ebee35a4ee3257 ]
Use valid_name() to make sure user does not provide illegal
device name.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_tunnel.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -297,13 +297,16 @@ static struct ip6_tnl *ip6_tnl_create(st
struct net_device *dev;
struct ip6_tnl *t;
char name[IFNAMSIZ];
- int err = -ENOMEM;
+ int err = -E2BIG;
- if (p->name[0])
+ if (p->name[0]) {
+ if (!dev_valid_name(p->name))
+ goto failed;
strlcpy(name, p->name, IFNAMSIZ);
- else
+ } else {
sprintf(name, "ip6tnl%%d");
-
+ }
+ err = -ENOMEM;
dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
ip6_tnl_dev_setup);
if (!dev)
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.14/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch
queue-4.14/net-fix-possible-out-of-bound-read-in-skb_network_protocol.patch
queue-4.14/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch
queue-4.14/net-fool-proof-dev_valid_name.patch
queue-4.14/ipv6-the-entire-ipv6-header-chain-must-fit-the-first-fragment.patch
queue-4.14/vti6-better-validate-user-provided-tunnel-names.patch
queue-4.14/ipv6-sit-better-validate-user-provided-tunnel-names.patch
queue-4.14/ip6_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.14/sctp-do-not-leak-kernel-memory-to-user-space.patch
queue-4.14/ip_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.14/netlink-make-sure-nladdr-has-correct-size-in-netlink_connect.patch
queue-4.14/ip6_gre-better-validate-user-provided-tunnel-names.patch
This is a note to let you know that I've just added the patch titled
ip_tunnel: better validate user provided tunnel names
to the 4.14-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:
ip_tunnel-better-validate-user-provided-tunnel-names.patch
and it can be found in the queue-4.14 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 23:20:08 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Thu, 5 Apr 2018 06:39:27 -0700
Subject: ip_tunnel: better validate user provided tunnel names
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 9cb726a212a82c88c98aa9f0037fd04777cd8fe5 ]
Use dev_valid_name() to make sure user does not provide illegal
device name.
syzbot caught the following bug :
BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300 [inline]
BUG: KASAN: stack-out-of-bounds in __ip_tunnel_create+0xca/0x6b0 net/ipv4/ip_tunnel.c:257
Write of size 20 at addr ffff8801ac79f810 by task syzkaller268107/4482
CPU: 0 PID: 4482 Comm: syzkaller268107 Not tainted 4.16.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1b9/0x29f lib/dump_stack.c:53
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
strlcpy include/linux/string.h:300 [inline]
__ip_tunnel_create+0xca/0x6b0 net/ipv4/ip_tunnel.c:257
ip_tunnel_create net/ipv4/ip_tunnel.c:352 [inline]
ip_tunnel_ioctl+0x818/0xd40 net/ipv4/ip_tunnel.c:861
ipip_tunnel_ioctl+0x1c5/0x420 net/ipv4/ipip.c:350
dev_ifsioc+0x43e/0xb90 net/core/dev_ioctl.c:334
dev_ioctl+0x69a/0xcc0 net/core/dev_ioctl.c:525
sock_ioctl+0x47e/0x680 net/socket.c:1015
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1cf/0x1650 fs/ioctl.c:684
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
SYSC_ioctl fs/ioctl.c:708 [inline]
SyS_ioctl+0x24/0x30 fs/ioctl.c:706
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/ip_tunnel.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -253,13 +253,14 @@ static struct net_device *__ip_tunnel_cr
struct net_device *dev;
char name[IFNAMSIZ];
- if (parms->name[0])
+ err = -E2BIG;
+ if (parms->name[0]) {
+ if (!dev_valid_name(parms->name))
+ goto failed;
strlcpy(name, parms->name, IFNAMSIZ);
- else {
- if (strlen(ops->kind) > (IFNAMSIZ - 3)) {
- err = -E2BIG;
+ } else {
+ if (strlen(ops->kind) > (IFNAMSIZ - 3))
goto failed;
- }
strlcpy(name, ops->kind, IFNAMSIZ);
strncat(name, "%d", 2);
}
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.14/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch
queue-4.14/net-fix-possible-out-of-bound-read-in-skb_network_protocol.patch
queue-4.14/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch
queue-4.14/net-fool-proof-dev_valid_name.patch
queue-4.14/ipv6-the-entire-ipv6-header-chain-must-fit-the-first-fragment.patch
queue-4.14/vti6-better-validate-user-provided-tunnel-names.patch
queue-4.14/ipv6-sit-better-validate-user-provided-tunnel-names.patch
queue-4.14/ip6_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.14/sctp-do-not-leak-kernel-memory-to-user-space.patch
queue-4.14/ip_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.14/netlink-make-sure-nladdr-has-correct-size-in-netlink_connect.patch
queue-4.14/ip6_gre-better-validate-user-provided-tunnel-names.patch
This is a note to let you know that I've just added the patch titled
ip6_gre: better validate user provided tunnel names
to the 4.14-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:
ip6_gre-better-validate-user-provided-tunnel-names.patch
and it can be found in the queue-4.14 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 23:20:08 CEST 2018
From: Eric Dumazet <edumazet(a)google.com>
Date: Thu, 5 Apr 2018 06:39:29 -0700
Subject: ip6_gre: better validate user provided tunnel names
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 5f42df013b8bc1b6511af7a04bf93b014884ae2a ]
Use dev_valid_name() to make sure user does not provide illegal
device name.
syzbot caught the following bug :
BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300 [inline]
BUG: KASAN: stack-out-of-bounds in ip6gre_tunnel_locate+0x334/0x860 net/ipv6/ip6_gre.c:339
Write of size 20 at addr ffff8801afb9f7b8 by task syzkaller851048/4466
CPU: 1 PID: 4466 Comm: syzkaller851048 Not tainted 4.16.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1b9/0x29f lib/dump_stack.c:53
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
strlcpy include/linux/string.h:300 [inline]
ip6gre_tunnel_locate+0x334/0x860 net/ipv6/ip6_gre.c:339
ip6gre_tunnel_ioctl+0x69d/0x12e0 net/ipv6/ip6_gre.c:1195
dev_ifsioc+0x43e/0xb90 net/core/dev_ioctl.c:334
dev_ioctl+0x69a/0xcc0 net/core/dev_ioctl.c:525
sock_ioctl+0x47e/0x680 net/socket.c:1015
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1cf/0x1650 fs/ioctl.c:684
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
SYSC_ioctl fs/ioctl.c:708 [inline]
SyS_ioctl+0x24/0x30 fs/ioctl.c:706
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv6/ip6_gre.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -319,11 +319,13 @@ static struct ip6_tnl *ip6gre_tunnel_loc
if (t || !create)
return t;
- if (parms->name[0])
+ if (parms->name[0]) {
+ if (!dev_valid_name(parms->name))
+ return NULL;
strlcpy(name, parms->name, IFNAMSIZ);
- else
+ } else {
strcpy(name, "ip6gre%d");
-
+ }
dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
ip6gre_tunnel_setup);
if (!dev)
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.14/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch
queue-4.14/net-fix-possible-out-of-bound-read-in-skb_network_protocol.patch
queue-4.14/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch
queue-4.14/net-fool-proof-dev_valid_name.patch
queue-4.14/ipv6-the-entire-ipv6-header-chain-must-fit-the-first-fragment.patch
queue-4.14/vti6-better-validate-user-provided-tunnel-names.patch
queue-4.14/ipv6-sit-better-validate-user-provided-tunnel-names.patch
queue-4.14/ip6_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.14/sctp-do-not-leak-kernel-memory-to-user-space.patch
queue-4.14/ip_tunnel-better-validate-user-provided-tunnel-names.patch
queue-4.14/netlink-make-sure-nladdr-has-correct-size-in-netlink_connect.patch
queue-4.14/ip6_gre-better-validate-user-provided-tunnel-names.patch
This is a note to let you know that I've just added the patch titled
bonding: process the err returned by dev_set_allmulti properly in bond_enslave
to the 4.14-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:
bonding-process-the-err-returned-by-dev_set_allmulti-properly-in-bond_enslave.patch
and it can be found in the queue-4.14 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 23:20:08 CEST 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 26 Mar 2018 01:16:47 +0800
Subject: bonding: process the err returned by dev_set_allmulti properly in bond_enslave
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 9f5a90c107741b864398f4ac0014711a8c1d8474 ]
When dev_set_promiscuity(1) succeeds but dev_set_allmulti(1) fails,
dev_set_promiscuity(-1) should be done before going to the err path.
Otherwise, dev->promiscuity will leak.
Fixes: 7e1a1ac1fbaa ("bonding: Check return of dev_set_promiscuity/allmulti")
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Andy Gospodarek <andy(a)greyhouse.net>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/bonding/bond_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1702,8 +1702,11 @@ int bond_enslave(struct net_device *bond
/* set allmulti level to new slave */
if (bond_dev->flags & IFF_ALLMULTI) {
res = dev_set_allmulti(slave_dev, 1);
- if (res)
+ if (res) {
+ if (bond_dev->flags & IFF_PROMISC)
+ dev_set_promiscuity(slave_dev, -1);
goto err_sysfs_del;
+ }
}
netif_addr_lock_bh(bond_dev);
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/team-move-dev_mc_sync-after-master_upper_dev_link-in-team_port_add.patch
queue-4.14/bonding-process-the-err-returned-by-dev_set_allmulti-properly-in-bond_enslave.patch
queue-4.14/bonding-fix-the-err-path-for-dev-hwaddr-sync-in-bond_enslave.patch
queue-4.14/bonding-move-dev_mc_sync-after-master_upper_dev_link-in-bond_enslave.patch
queue-4.14/route-check-sysctl_fib_multipath_use_neigh-earlier-than-hash.patch
This is a note to let you know that I've just added the patch titled
bonding: move dev_mc_sync after master_upper_dev_link in bond_enslave
to the 4.14-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:
bonding-move-dev_mc_sync-after-master_upper_dev_link-in-bond_enslave.patch
and it can be found in the queue-4.14 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 23:20:08 CEST 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 26 Mar 2018 01:16:46 +0800
Subject: bonding: move dev_mc_sync after master_upper_dev_link in bond_enslave
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit ae42cc62a9f07f1f6979054ed92606b9c30f4a2e ]
Beniamino found a crash when adding vlan as slave of bond which is also
the parent link:
ip link add bond1 type bond
ip link set bond1 up
ip link add link bond1 vlan1 type vlan id 80
ip link set vlan1 master bond1
The call trace is as below:
[<ffffffffa850842a>] queued_spin_lock_slowpath+0xb/0xf
[<ffffffffa8515680>] _raw_spin_lock+0x20/0x30
[<ffffffffa83f6f07>] dev_mc_sync+0x37/0x80
[<ffffffffc08687dc>] vlan_dev_set_rx_mode+0x1c/0x30 [8021q]
[<ffffffffa83efd2a>] __dev_set_rx_mode+0x5a/0xa0
[<ffffffffa83f7138>] dev_mc_sync_multiple+0x78/0x80
[<ffffffffc084127c>] bond_enslave+0x67c/0x1190 [bonding]
[<ffffffffa8401909>] do_setlink+0x9c9/0xe50
[<ffffffffa8403bf2>] rtnl_newlink+0x522/0x880
[<ffffffffa8403ff7>] rtnetlink_rcv_msg+0xa7/0x260
[<ffffffffa8424ecb>] netlink_rcv_skb+0xab/0xc0
[<ffffffffa83fe498>] rtnetlink_rcv+0x28/0x30
[<ffffffffa8424850>] netlink_unicast+0x170/0x210
[<ffffffffa8424bf8>] netlink_sendmsg+0x308/0x420
[<ffffffffa83cc396>] sock_sendmsg+0xb6/0xf0
This is actually a dead lock caused by sync slave hwaddr from master when
the master is the slave's 'slave'. This dead loop check is actually done
by netdev_master_upper_dev_link. However, Commit 1f718f0f4f97 ("bonding:
populate neighbour's private on enslave") moved it after dev_mc_sync.
This patch is to fix it by moving dev_mc_sync after master_upper_dev_link,
so that this loop check would be earlier than dev_mc_sync. It also moves
if (mode == BOND_MODE_8023AD) into if (!bond_uses_primary) clause as an
improvement.
Note team driver also has this issue, I will fix it in another patch.
Fixes: 1f718f0f4f97 ("bonding: populate neighbour's private on enslave")
Reported-by: Beniamino Galvani <bgalvani(a)redhat.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Andy Gospodarek <andy(a)greyhouse.net>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/bonding/bond_main.c | 73 +++++++++++++++++++---------------------
1 file changed, 35 insertions(+), 38 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1524,44 +1524,11 @@ int bond_enslave(struct net_device *bond
goto err_close;
}
- /* If the mode uses primary, then the following is handled by
- * bond_change_active_slave().
- */
- if (!bond_uses_primary(bond)) {
- /* set promiscuity level to new slave */
- if (bond_dev->flags & IFF_PROMISC) {
- res = dev_set_promiscuity(slave_dev, 1);
- if (res)
- goto err_close;
- }
-
- /* set allmulti level to new slave */
- if (bond_dev->flags & IFF_ALLMULTI) {
- res = dev_set_allmulti(slave_dev, 1);
- if (res)
- goto err_close;
- }
-
- netif_addr_lock_bh(bond_dev);
-
- dev_mc_sync_multiple(slave_dev, bond_dev);
- dev_uc_sync_multiple(slave_dev, bond_dev);
-
- netif_addr_unlock_bh(bond_dev);
- }
-
- if (BOND_MODE(bond) == BOND_MODE_8023AD) {
- /* add lacpdu mc addr to mc list */
- u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR;
-
- dev_mc_add(slave_dev, lacpdu_multicast);
- }
-
res = vlan_vids_add_by_dev(slave_dev, bond_dev);
if (res) {
netdev_err(bond_dev, "Couldn't add bond vlan ids to %s\n",
slave_dev->name);
- goto err_hwaddr_unsync;
+ goto err_close;
}
prev_slave = bond_last_slave(bond);
@@ -1721,6 +1688,37 @@ int bond_enslave(struct net_device *bond
goto err_upper_unlink;
}
+ /* If the mode uses primary, then the following is handled by
+ * bond_change_active_slave().
+ */
+ if (!bond_uses_primary(bond)) {
+ /* set promiscuity level to new slave */
+ if (bond_dev->flags & IFF_PROMISC) {
+ res = dev_set_promiscuity(slave_dev, 1);
+ if (res)
+ goto err_sysfs_del;
+ }
+
+ /* set allmulti level to new slave */
+ if (bond_dev->flags & IFF_ALLMULTI) {
+ res = dev_set_allmulti(slave_dev, 1);
+ if (res)
+ goto err_sysfs_del;
+ }
+
+ netif_addr_lock_bh(bond_dev);
+ dev_mc_sync_multiple(slave_dev, bond_dev);
+ dev_uc_sync_multiple(slave_dev, bond_dev);
+ netif_addr_unlock_bh(bond_dev);
+
+ if (BOND_MODE(bond) == BOND_MODE_8023AD) {
+ /* add lacpdu mc addr to mc list */
+ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR;
+
+ dev_mc_add(slave_dev, lacpdu_multicast);
+ }
+ }
+
bond->slave_cnt++;
bond_compute_features(bond);
bond_set_carrier(bond);
@@ -1744,6 +1742,9 @@ int bond_enslave(struct net_device *bond
return 0;
/* Undo stages on error */
+err_sysfs_del:
+ bond_sysfs_slave_del(new_slave);
+
err_upper_unlink:
bond_upper_dev_unlink(bond, new_slave);
@@ -1764,10 +1765,6 @@ err_detach:
synchronize_rcu();
slave_disable_netpoll(new_slave);
-err_hwaddr_unsync:
- if (!bond_uses_primary(bond))
- bond_hw_addr_flush(bond_dev, slave_dev);
-
err_close:
slave_dev->priv_flags &= ~IFF_BONDING;
dev_close(slave_dev);
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/team-move-dev_mc_sync-after-master_upper_dev_link-in-team_port_add.patch
queue-4.14/bonding-process-the-err-returned-by-dev_set_allmulti-properly-in-bond_enslave.patch
queue-4.14/bonding-fix-the-err-path-for-dev-hwaddr-sync-in-bond_enslave.patch
queue-4.14/bonding-move-dev_mc_sync-after-master_upper_dev_link-in-bond_enslave.patch
queue-4.14/route-check-sysctl_fib_multipath_use_neigh-earlier-than-hash.patch
This is a note to let you know that I've just added the patch titled
bonding: fix the err path for dev hwaddr sync in bond_enslave
to the 4.14-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:
bonding-fix-the-err-path-for-dev-hwaddr-sync-in-bond_enslave.patch
and it can be found in the queue-4.14 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 23:20:08 CEST 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 26 Mar 2018 01:16:45 +0800
Subject: bonding: fix the err path for dev hwaddr sync in bond_enslave
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 5c78f6bfae2b10ff70e21d343e64584ea6280c26 ]
vlan_vids_add_by_dev is called right after dev hwaddr sync, so on
the err path it should unsync dev hwaddr. Otherwise, the slave
dev's hwaddr will never be unsync when this err happens.
Fixes: 1ff412ad7714 ("bonding: change the bond's vlan syncing functions with the standard ones")
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Reviewed-by: Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
Acked-by: Andy Gospodarek <andy(a)greyhouse.net>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/bonding/bond_main.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1561,7 +1561,7 @@ int bond_enslave(struct net_device *bond
if (res) {
netdev_err(bond_dev, "Couldn't add bond vlan ids to %s\n",
slave_dev->name);
- goto err_close;
+ goto err_hwaddr_unsync;
}
prev_slave = bond_last_slave(bond);
@@ -1751,9 +1751,6 @@ err_unregister:
netdev_rx_handler_unregister(slave_dev);
err_detach:
- if (!bond_uses_primary(bond))
- bond_hw_addr_flush(bond_dev, slave_dev);
-
vlan_vids_del_by_dev(slave_dev, bond_dev);
if (rcu_access_pointer(bond->primary_slave) == new_slave)
RCU_INIT_POINTER(bond->primary_slave, NULL);
@@ -1767,6 +1764,10 @@ err_detach:
synchronize_rcu();
slave_disable_netpoll(new_slave);
+err_hwaddr_unsync:
+ if (!bond_uses_primary(bond))
+ bond_hw_addr_flush(bond_dev, slave_dev);
+
err_close:
slave_dev->priv_flags &= ~IFF_BONDING;
dev_close(slave_dev);
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/team-move-dev_mc_sync-after-master_upper_dev_link-in-team_port_add.patch
queue-4.14/bonding-process-the-err-returned-by-dev_set_allmulti-properly-in-bond_enslave.patch
queue-4.14/bonding-fix-the-err-path-for-dev-hwaddr-sync-in-bond_enslave.patch
queue-4.14/bonding-move-dev_mc_sync-after-master_upper_dev_link-in-bond_enslave.patch
queue-4.14/route-check-sysctl_fib_multipath_use_neigh-earlier-than-hash.patch
This is a note to let you know that I've just added the patch titled
arp: fix arp_filter on l3slave devices
to the 4.14-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:
arp-fix-arp_filter-on-l3slave-devices.patch
and it can be found in the queue-4.14 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 23:20:08 CEST 2018
From: Miguel Fadon Perlines <mfadon(a)teldat.com>
Date: Thu, 5 Apr 2018 10:25:38 +0200
Subject: arp: fix arp_filter on l3slave devices
From: Miguel Fadon Perlines <mfadon(a)teldat.com>
[ Upstream commit 58b35f27689b5eb514fc293c332966c226b1b6e4 ]
arp_filter performs an ip_route_output search for arp source address and
checks if output device is the same where the arp request was received,
if it is not, the arp request is not answered.
This route lookup is always done on main route table so l3slave devices
never find the proper route and arp is not answered.
Passing l3mdev_master_ifindex_rcu(dev) return value as oif fixes the
lookup for l3slave devices while maintaining same behavior for non
l3slave devices as this function returns 0 in that case.
Fixes: 613d09b30f8b ("net: Use VRF device index for lookups on TX")
Signed-off-by: Miguel Fadon Perlines <mfadon(a)teldat.com>
Acked-by: David Ahern <dsa(a)cumulusnetworks.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/arp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -437,7 +437,7 @@ static int arp_filter(__be32 sip, __be32
/*unsigned long now; */
struct net *net = dev_net(dev);
- rt = ip_route_output(net, sip, tip, 0, 0);
+ rt = ip_route_output(net, sip, tip, 0, l3mdev_master_ifindex_rcu(dev));
if (IS_ERR(rt))
return 1;
if (rt->dst.dev != dev) {
Patches currently in stable-queue which might be from mfadon(a)teldat.com are
queue-4.14/arp-fix-arp_filter-on-l3slave-devices.patch
queue-4.14/vrf-fix-use-after-free-and-double-free-in-vrf_finish_output.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: gpmi: Fix gpmi_nand_init() error path
to the 4.4-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:
mtd-nand-gpmi-fix-gpmi_nand_init-error-path.patch
and it can be found in the queue-4.4 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 10:31:53 CEST 2018
From: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Date: Mon, 10 Apr 2017 10:35:17 +0200
Subject: mtd: nand: gpmi: Fix gpmi_nand_init() error path
From: Boris Brezillon <boris.brezillon(a)free-electrons.com>
[ Upstream commit 4d02423e9afe6c46142ce98bbcaf5167316dbfbf ]
The GPMI driver is wrongly assuming that nand_release() can safely be
called on an uninitialized/unregistered NAND device.
Add a new err_nand_cleanup label in the error path and only execute if
nand_scan_tail() succeeded.
Note that we now call nand_cleanup() instead of nand_release()
(nand_release() is actually grouping the mtd_device_unregister() and
nand_cleanup() in one call) because there's no point in trying to
unregister a device that has never been registered.
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Reviewed-by: Marek Vasut <marek.vasut(a)gmail.com>
Acked-by: Han Xu <han.xu(a)nxp.com>
Reviewed-by: Marek Vasut <marek.vasut(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1949,19 +1949,21 @@ static int gpmi_nand_init(struct gpmi_na
ret = nand_boot_init(this);
if (ret)
- goto err_out;
+ goto err_nand_cleanup;
ret = chip->scan_bbt(mtd);
if (ret)
- goto err_out;
+ goto err_nand_cleanup;
ppdata.of_node = this->pdev->dev.of_node;
ret = mtd_device_parse_register(mtd, NULL, &ppdata, NULL, 0);
if (ret)
- goto err_out;
+ goto err_nand_cleanup;
return 0;
+err_nand_cleanup:
+ nand_cleanup(chip);
err_out:
- gpmi_nand_exit(this);
+ gpmi_free_dma_buffer(this);
return ret;
}
Patches currently in stable-queue which might be from boris.brezillon(a)free-electrons.com are
queue-4.4/mtd-nand-gpmi-fix-gpmi_nand_init-error-path.patch
This is a note to let you know that I've just added the patch titled
signal/arm: Document conflicts with SI_USER and SIGFPE
to the 4.4-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:
signal-arm-document-conflicts-with-si_user-and-sigfpe.patch
and it can be found in the queue-4.4 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 10:31:53 CEST 2018
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Thu, 17 Aug 2017 17:07:46 -0500
Subject: signal/arm: Document conflicts with SI_USER and SIGFPE
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
[ Upstream commit 7771c66457004977b616bab785209f49d164f527 ]
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
that uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME, siginfo_layout will now return SIL_FAULT and the
appropriate fields will be reliably copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: Russell King <rmk(a)flint.arm.linux.org.uk>
Cc: linux-arm-kernel(a)lists.infradead.org
Ref: 451436b7bbb2 ("[ARM] Add support code for ARM hardware vector floating point")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/include/uapi/asm/siginfo.h | 13 +++++++++++++
arch/arm/vfp/vfpmodule.c | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/uapi/asm/siginfo.h
--- /dev/null
+++ b/arch/arm/include/uapi/asm/siginfo.h
@@ -0,0 +1,13 @@
+#ifndef __ASM_SIGINFO_H
+#define __ASM_SIGINFO_H
+
+#include <asm-generic/siginfo.h>
+
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
+#endif
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -261,7 +261,7 @@ static void vfp_raise_exceptions(u32 exc
if (exceptions == VFP_EXCEPTION_ERROR) {
vfp_panic("unhandled bounce", inst);
- vfp_raise_sigfpe(0, regs);
+ vfp_raise_sigfpe(FPE_FIXME, regs);
return;
}
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.4/signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch
queue-4.4/pidns-disable-pid-allocation-if-pid_ns_prepare_proc-is-failed-in-alloc_pid.patch
queue-4.4/signal-arm-document-conflicts-with-si_user-and-sigfpe.patch
queue-4.4/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch
This is a note to let you know that I've just added the patch titled
signal/metag: Document a conflict with SI_USER with SIGFPE
to the 4.15-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:
signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch
and it can be found in the queue-4.15 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 Mon Apr 9 10:16:32 CEST 2018
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 10:37:40 -0500
Subject: signal/metag: Document a conflict with SI_USER with SIGFPE
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
[ Upstream commit b80328be53c215346b153769267b38f531d89b4f ]
Setting si_code to 0 results in a userspace seeing an si_code of 0.
This is the same si_code as SI_USER. Posix and common sense requires
that SI_USER not be a signal specific si_code. As such this use of 0
for the si_code is a pretty horribly broken ABI.
Further use of si_code == 0 guaranteed that copy_siginfo_to_user saw a
value of __SI_KILL and now sees a value of SIL_KILL with the result
hat uid and pid fields are copied and which might copying the si_addr
field by accident but certainly not by design. Making this a very
flakey implementation.
Utilizing FPE_FIXME siginfo_layout will now return SIL_FAULT and the
appropriate fields will reliably be copied.
Possible ABI fixes includee:
- Send the signal without siginfo
- Don't generate a signal
- Possibly assign and use an appropriate si_code
- Don't handle cases which can't happen
Cc: James Hogan <james.hogan(a)imgtec.com>
Cc: linux-metag(a)vger.kernel.org
Ref: ac919f0883e5 ("metag: Traps")
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/metag/include/uapi/asm/siginfo.h | 7 +++++++
arch/metag/kernel/traps.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
--- a/arch/metag/include/uapi/asm/siginfo.h
+++ b/arch/metag/include/uapi/asm/siginfo.h
@@ -6,4 +6,11 @@
#include <asm-generic/siginfo.h>
+/*
+ * SIGFPE si_codes
+ */
+#ifdef __KERNEL__
+#define FPE_FIXME 0 /* Broken dup of SI_USER */
+#endif /* __KERNEL__ */
+
#endif
--- a/arch/metag/kernel/traps.c
+++ b/arch/metag/kernel/traps.c
@@ -735,7 +735,7 @@ TBIRES fpe_handler(TBIRES State, int Sig
else if (error_state & TXSTAT_FPE_INEXACT_BIT)
info.si_code = FPE_FLTRES;
else
- info.si_code = 0;
+ info.si_code = FPE_FIXME;
info.si_errno = 0;
info.si_addr = (__force void __user *)regs->ctx.CurrPC;
force_sig_info(SIGFPE, &info, current);
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.15/signal-metag-document-a-conflict-with-si_user-with-sigfpe.patch
queue-4.15/signal-arm-document-conflicts-with-si_user-and-sigfpe.patch
queue-4.15/signal-powerpc-document-conflicts-with-si_user-and-sigfpe-and-sigtrap.patch