- Linux-stable-mirror - lists.linaro.org

[PATCHES] Networking

by David Miller

Please queue up the following networking bug fixes for v4.14, v4.15, and v4.16 -stable, respectively. Thank you!

7 years, 6 months

2
1
0 0

Patch "clk: at91: fix clk-generated compilation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled clk: at91: fix clk-generated compilation to the 4.9-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: clk-at91-fix-clk-generated-compilation.patch and it can be found in the queue-4.9 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 4a5f06a01cfd1f7a9141bdb760bf5b68cca7f224 Mon Sep 17 00:00:00 2001 From: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Date: Mon, 5 Jun 2017 00:02:57 +0200 Subject: clk: at91: fix clk-generated compilation From: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> commit 4a5f06a01cfd1f7a9141bdb760bf5b68cca7f224 upstream. Fix missing } Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com> Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org> Cc: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/clk/at91/clk-generated.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/clk/at91/clk-generated.c +++ b/drivers/clk/at91/clk-generated.c @@ -266,6 +266,7 @@ at91_clk_register_generated(struct regma if (ret) { kfree(gck); hw = ERR_PTR(ret); + } return hw; } Patches currently in stable-queue which might be from alexandre.belloni(a)free-electrons.com are queue-4.9/clk-at91-fix-clk-generated-parenting.patch queue-4.9/rtc-interface-validate-alarm-time-before-handling-rollover.patch queue-4.9/rtc-m41t80-fix-sqw-dividers-override-when-setting-a-date.patch queue-4.9/rtc-snvs-fix-an-incorrect-check-of-return-value.patch queue-4.9/clk-at91-fix-clk-generated-compilation.patch queue-4.9/rtc-opal-handle-disabled-tpo-in-opal_get_tpo_time.patch

7 years, 6 months

1
0
0 0

Patch "vlan: also check phy_driver ts_info for vlan's real device" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vlan: also check phy_driver ts_info for vlan's real device to the 4.16-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: vlan-also-check-phy_driver-ts_info-for-vlan-s-real-device.patch and it can be found in the queue-4.16 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:19:25 CEST 2018 From: Hangbin Liu <liuhangbin(a)gmail.com> Date: Fri, 30 Mar 2018 09:44:00 +0800 Subject: vlan: also check phy_driver ts_info for vlan's real device From: Hangbin Liu <liuhangbin(a)gmail.com> [ Upstream commit ec1d8ccb07deaf30fd0508af6755364ac47dc08d ] Just like function ethtool_get_ts_info(), we should also consider the phy_driver ts_info call back. For example, driver dp83640. Fixes: 37dd9255b2f6 ("vlan: Pass ethtool get_ts_info queries to real device.") Acked-by: Richard Cochran <richardcochran(a)gmail.com> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/8021q/vlan_dev.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/net/8021q/vlan_dev.c +++ b/net/8021q/vlan_dev.c @@ -29,6 +29,7 @@ #include <linux/net_tstamp.h> #include <linux/etherdevice.h> #include <linux/ethtool.h> +#include <linux/phy.h> #include <net/arp.h> #include <net/switchdev.h> @@ -665,8 +666,11 @@ static int vlan_ethtool_get_ts_info(stru { const struct vlan_dev_priv *vlan = vlan_dev_priv(dev); const struct ethtool_ops *ops = vlan->real_dev->ethtool_ops; + struct phy_device *phydev = vlan->real_dev->phydev; - if (ops->get_ts_info) { + if (phydev && phydev->drv && phydev->drv->ts_info) { + return phydev->drv->ts_info(phydev, info); + } else if (ops->get_ts_info) { return ops->get_ts_info(vlan->real_dev, info); } else { info->so_timestamping = SOF_TIMESTAMPING_RX_SOFTWARE | Patches currently in stable-queue which might be from liuhangbin(a)gmail.com are queue-4.16/vlan-also-check-phy_driver-ts_info-for-vlan-s-real-device.patch

7 years, 6 months

1
0
0 0

Patch "sky2: Increase D3 delay to sky2 stops working after suspend" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sky2: Increase D3 delay to sky2 stops working after suspend to the 4.16-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: sky2-increase-d3-delay-to-sky2-stops-working-after-suspend.patch and it can be found in the queue-4.16 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:19:25 CEST 2018 From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Date: Sat, 31 Mar 2018 23:42:03 +0800 Subject: sky2: Increase D3 delay to sky2 stops working after suspend From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> [ Upstream commit afb133637071be6deeb8b3d0e55593ffbf63c527 ] The sky2 ethernet stops working after system resume from suspend: [ 582.852065] sky2 0000:04:00.0: Refused to change power state, currently in D3 The current 150ms delay is not enough, change it to 200ms can solve the issue. BugLink: https://bugs.launchpad.net/bugs/1758507 Cc: Stable <stable(a)vger.kernel.org> Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/marvell/sky2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/marvell/sky2.c +++ b/drivers/net/ethernet/marvell/sky2.c @@ -5087,7 +5087,7 @@ static int sky2_probe(struct pci_dev *pd INIT_WORK(&hw->restart_work, sky2_restart); pci_set_drvdata(pdev, hw); - pdev->d3_delay = 150; + pdev->d3_delay = 200; return 0; Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are queue-4.16/sky2-increase-d3-delay-to-sky2-stops-working-after-suspend.patch

7 years, 6 months

1
0
0 0

Patch "vti6: better validate user provided tunnel names" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vti6: better validate user provided tunnel names to the 4.16-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: vti6-better-validate-user-provided-tunnel-names.patch and it can be found in the queue-4.16 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:19:25 CEST 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Thu, 5 Apr 2018 06:39:31 -0700 Subject: vti6: better validate user provided tunnel names From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 537b361fbcbcc3cd6fe2bb47069fd292b9256d16 ] Use valid_name() to make sure user does not provide illegal device name. Fixes: ed1efb2aefbb ("ipv6: Add support for IPsec virtual tunnel interfaces") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Steffen Klassert <steffen.klassert(a)secunet.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_vti.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -212,10 +212,13 @@ static struct ip6_tnl *vti6_tnl_create(s char name[IFNAMSIZ]; int err; - 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, "ip6_vti%%d"); + } dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN, vti6_dev_setup); if (!dev) Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.16/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch queue-4.16/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch queue-4.16/net-fool-proof-dev_valid_name.patch queue-4.16/vti6-better-validate-user-provided-tunnel-names.patch queue-4.16/ipv6-sit-better-validate-user-provided-tunnel-names.patch queue-4.16/ip6_tunnel-better-validate-user-provided-tunnel-names.patch queue-4.16/sctp-do-not-leak-kernel-memory-to-user-space.patch queue-4.16/ip_tunnel-better-validate-user-provided-tunnel-names.patch queue-4.16/ip6_gre-better-validate-user-provided-tunnel-names.patch

7 years, 6 months

1
0
0 0

Patch "sctp: sctp_sockaddr_af must check minimal addr length for AF_INET6" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: sctp_sockaddr_af must check minimal addr length for AF_INET6 to the 4.16-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: sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch and it can be found in the queue-4.16 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:19:25 CEST 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Sun, 8 Apr 2018 07:52:08 -0700 Subject: sctp: sctp_sockaddr_af must check minimal addr length for AF_INET6 From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 81e98370293afcb58340ce8bd71af7b97f925c26 ] Check must happen before call to ipv6_addr_v4mapped() syzbot report was : BUG: KMSAN: uninit-value in sctp_sockaddr_af net/sctp/socket.c:359 [inline] BUG: KMSAN: uninit-value in sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384 CPU: 0 PID: 3576 Comm: syzkaller968804 Not tainted 4.16.0+ #82 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+0x185/0x1d0 lib/dump_stack.c:53 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676 sctp_sockaddr_af net/sctp/socket.c:359 [inline] sctp_do_bind+0x60f/0xdc0 net/sctp/socket.c:384 sctp_bind+0x149/0x190 net/sctp/socket.c:332 inet6_bind+0x1fd/0x1820 net/ipv6/af_inet6.c:293 SYSC_bind+0x3f2/0x4b0 net/socket.c:1474 SyS_bind+0x54/0x80 net/socket.c:1460 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x43fd49 RSP: 002b:00007ffe99df3d28 EFLAGS: 00000213 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd49 RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000003 RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8 R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401670 R13: 0000000000401700 R14: 0000000000000000 R15: 0000000000000000 Local variable description: ----address@SYSC_bind Variable was created at: SYSC_bind+0x6f/0x4b0 net/socket.c:1461 SyS_bind+0x54/0x80 net/socket.c:1460 Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Vlad Yasevich <vyasevich(a)gmail.com> Cc: Neil Horman <nhorman(a)tuxdriver.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/sctp/socket.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -354,11 +354,14 @@ static struct sctp_af *sctp_sockaddr_af( if (!opt->pf->af_supported(addr->sa.sa_family, opt)) return NULL; - /* V4 mapped address are really of AF_INET family */ - if (addr->sa.sa_family == AF_INET6 && - ipv6_addr_v4mapped(&addr->v6.sin6_addr) && - !opt->pf->af_supported(AF_INET, opt)) - return NULL; + if (addr->sa.sa_family == AF_INET6) { + if (len < SIN6_LEN_RFC2133) + return NULL; + /* V4 mapped address are really of AF_INET family */ + if (ipv6_addr_v4mapped(&addr->v6.sin6_addr) && + !opt->pf->af_supported(AF_INET, opt)) + return NULL; + } /* If we get this far, af is valid. */ af = sctp_get_af_specific(addr->sa.sa_family); Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.16/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch queue-4.16/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch queue-4.16/net-fool-proof-dev_valid_name.patch queue-4.16/vti6-better-validate-user-provided-tunnel-names.patch queue-4.16/ipv6-sit-better-validate-user-provided-tunnel-names.patch queue-4.16/ip6_tunnel-better-validate-user-provided-tunnel-names.patch queue-4.16/sctp-do-not-leak-kernel-memory-to-user-space.patch queue-4.16/ip_tunnel-better-validate-user-provided-tunnel-names.patch queue-4.16/ip6_gre-better-validate-user-provided-tunnel-names.patch

7 years, 6 months

1
0
0 0

Patch "sctp: do not leak kernel memory to user space" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: do not leak kernel memory to user space to the 4.16-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: sctp-do-not-leak-kernel-memory-to-user-space.patch and it can be found in the queue-4.16 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:19:25 CEST 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Sat, 7 Apr 2018 17:15:22 -0700 Subject: sctp: do not leak kernel memory to user space From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 6780db244d6b1537d139dea0ec8aad10cf9e4adb ] syzbot produced a nice report [1] Issue here is that a recvmmsg() managed to leak 8 bytes of kernel memory to user space, because sin_zero (padding field) was not properly cleared. [1] BUG: KMSAN: uninit-value in copy_to_user include/linux/uaccess.h:184 [inline] BUG: KMSAN: uninit-value in move_addr_to_user+0x32e/0x530 net/socket.c:227 CPU: 1 PID: 3586 Comm: syzkaller481044 Not tainted 4.16.0+ #82 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+0x185/0x1d0 lib/dump_stack.c:53 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067 kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176 kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199 copy_to_user include/linux/uaccess.h:184 [inline] move_addr_to_user+0x32e/0x530 net/socket.c:227 ___sys_recvmsg+0x4e2/0x810 net/socket.c:2211 __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313 SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394 SyS_recvmmsg+0x76/0xa0 net/socket.c:2378 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x4401c9 RSP: 002b:00007ffc56f73098 EFLAGS: 00000217 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004401c9 RDX: 0000000000000001 RSI: 0000000020003ac0 RDI: 0000000000000003 RBP: 00000000006ca018 R08: 0000000020003bc0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000401af0 R13: 0000000000401b80 R14: 0000000000000000 R15: 0000000000000000 Local variable description: ----addr@___sys_recvmsg Variable was created at: ___sys_recvmsg+0xd5/0x810 net/socket.c:2172 __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313 Bytes 8-15 of 16 are uninitialized ================================================================== Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 3586 Comm: syzkaller481044 Tainted: G B 4.16.0+ #82 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+0x185/0x1d0 lib/dump_stack.c:53 panic+0x39d/0x940 kernel/panic.c:183 kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083 kmsan_internal_check_memory+0x164/0x1d0 mm/kmsan/kmsan.c:1176 kmsan_copy_to_user+0x69/0x160 mm/kmsan/kmsan.c:1199 copy_to_user include/linux/uaccess.h:184 [inline] move_addr_to_user+0x32e/0x530 net/socket.c:227 ___sys_recvmsg+0x4e2/0x810 net/socket.c:2211 __sys_recvmmsg+0x54e/0xdb0 net/socket.c:2313 SYSC_recvmmsg+0x29b/0x3e0 net/socket.c:2394 SyS_recvmmsg+0x76/0xa0 net/socket.c:2378 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Vlad Yasevich <vyasevich(a)gmail.com> Cc: Neil Horman <nhorman(a)tuxdriver.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/sctp/ipv6.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/net/sctp/ipv6.c +++ b/net/sctp/ipv6.c @@ -728,8 +728,10 @@ static int sctp_v6_addr_to_user(struct s sctp_v6_map_v4(addr); } - if (addr->sa.sa_family == AF_INET) + if (addr->sa.sa_family == AF_INET) { + memset(addr->v4.sin_zero, 0, sizeof(addr->v4.sin_zero)); return sizeof(struct sockaddr_in); + } return sizeof(struct sockaddr_in6); } Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.16/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch queue-4.16/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch queue-4.16/net-fool-proof-dev_valid_name.patch queue-4.16/vti6-better-validate-user-provided-tunnel-names.patch queue-4.16/ipv6-sit-better-validate-user-provided-tunnel-names.patch queue-4.16/ip6_tunnel-better-validate-user-provided-tunnel-names.patch queue-4.16/sctp-do-not-leak-kernel-memory-to-user-space.patch queue-4.16/ip_tunnel-better-validate-user-provided-tunnel-names.patch queue-4.16/ip6_gre-better-validate-user-provided-tunnel-names.patch

7 years, 6 months

1
0
0 0

Patch "pptp: remove a buggy dst release in pptp_connect()" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled pptp: remove a buggy dst release in pptp_connect() to the 4.16-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: pptp-remove-a-buggy-dst-release-in-pptp_connect.patch and it can be found in the queue-4.16 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:19:25 CEST 2018 From: Eric Dumazet <edumazet(a)google.com> Date: Mon, 2 Apr 2018 18:48:37 -0700 Subject: pptp: remove a buggy dst release in pptp_connect() From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit bfacfb457b36911a10140b8cb3ce76a74883ac5a ] Once dst has been cached in socket via sk_setup_caps(), it is illegal to call ip_rt_put() (or dst_release()), since sk_setup_caps() did not change dst refcount. We can still dereference it since we hold socket lock. Caugth by syzbot : BUG: KASAN: use-after-free in atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline] BUG: KASAN: use-after-free in dst_release+0x27/0xa0 net/core/dst.c:185 Write of size 4 at addr ffff8801c54dc040 by task syz-executor4/20088 CPU: 1 PID: 20088 Comm: syz-executor4 Not tainted 4.16.0+ #376 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+0x1a7/0x27d lib/dump_stack.c:53 print_address_description+0x73/0x250 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report+0x23c/0x360 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x137/0x190 mm/kasan/kasan.c:267 kasan_check_write+0x14/0x20 mm/kasan/kasan.c:278 atomic_dec_return include/asm-generic/atomic-instrumented.h:198 [inline] dst_release+0x27/0xa0 net/core/dst.c:185 sk_dst_set include/net/sock.h:1812 [inline] sk_dst_reset include/net/sock.h:1824 [inline] sock_setbindtodevice net/core/sock.c:610 [inline] sock_setsockopt+0x431/0x1b20 net/core/sock.c:707 SYSC_setsockopt net/socket.c:1845 [inline] SyS_setsockopt+0x2ff/0x360 net/socket.c:1828 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x4552d9 RSP: 002b:00007f4878126c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007f48781276d4 RCX: 00000000004552d9 RDX: 0000000000000019 RSI: 0000000000000001 RDI: 0000000000000013 RBP: 000000000072bea0 R08: 0000000000000010 R09: 0000000000000000 R10: 00000000200010c0 R11: 0000000000000246 R12: 00000000ffffffff R13: 0000000000000526 R14: 00000000006fac30 R15: 0000000000000000 Allocated by task 20088: save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3542 dst_alloc+0x11f/0x1a0 net/core/dst.c:104 rt_dst_alloc+0xe9/0x540 net/ipv4/route.c:1520 __mkroute_output net/ipv4/route.c:2265 [inline] ip_route_output_key_hash_rcu+0xa49/0x2c60 net/ipv4/route.c:2493 ip_route_output_key_hash+0x20b/0x370 net/ipv4/route.c:2322 __ip_route_output_key include/net/route.h:126 [inline] ip_route_output_flow+0x26/0xa0 net/ipv4/route.c:2577 ip_route_output_ports include/net/route.h:163 [inline] pptp_connect+0xa84/0x1170 drivers/net/ppp/pptp.c:453 SYSC_connect+0x213/0x4a0 net/socket.c:1639 SyS_connect+0x24/0x30 net/socket.c:1620 do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 Freed by task 20082: save_stack+0x43/0xd0 mm/kasan/kasan.c:447 set_track mm/kasan/kasan.c:459 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527 __cache_free mm/slab.c:3486 [inline] kmem_cache_free+0x83/0x2a0 mm/slab.c:3744 dst_destroy+0x266/0x380 net/core/dst.c:140 dst_destroy_rcu+0x16/0x20 net/core/dst.c:153 __rcu_reclaim kernel/rcu/rcu.h:178 [inline] rcu_do_batch kernel/rcu/tree.c:2675 [inline] invoke_rcu_callbacks kernel/rcu/tree.c:2930 [inline] __rcu_process_callbacks kernel/rcu/tree.c:2897 [inline] rcu_process_callbacks+0xd6c/0x17b0 kernel/rcu/tree.c:2914 __do_softirq+0x2d7/0xb85 kernel/softirq.c:285 The buggy address belongs to the object at ffff8801c54dc000 which belongs to the cache ip_dst_cache of size 168 The buggy address is located 64 bytes inside of 168-byte region [ffff8801c54dc000, ffff8801c54dc0a8) The buggy address belongs to the page: page:ffffea0007153700 count:1 mapcount:0 mapping:ffff8801c54dc000 index:0x0 flags: 0x2fffc0000000100(slab) raw: 02fffc0000000100 ffff8801c54dc000 0000000000000000 0000000100000010 raw: ffffea0006b34b20 ffffea0006b6c1e0 ffff8801d674a1c0 0000000000000000 page dumped because: kasan: bad access detected 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> --- drivers/net/ppp/pptp.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/net/ppp/pptp.c +++ b/drivers/net/ppp/pptp.c @@ -464,7 +464,6 @@ static int pptp_connect(struct socket *s po->chan.mtu = dst_mtu(&rt->dst); if (!po->chan.mtu) po->chan.mtu = PPP_MRU; - ip_rt_put(rt); po->chan.mtu -= PPTP_HEADER_OVERHEAD; po->chan.hdrlen = 2 + sizeof(struct pptp_gre_header); Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.16/sctp-sctp_sockaddr_af-must-check-minimal-addr-length-for-af_inet6.patch queue-4.16/pptp-remove-a-buggy-dst-release-in-pptp_connect.patch queue-4.16/net-fool-proof-dev_valid_name.patch queue-4.16/vti6-better-validate-user-provided-tunnel-names.patch queue-4.16/ipv6-sit-better-validate-user-provided-tunnel-names.patch queue-4.16/ip6_tunnel-better-validate-user-provided-tunnel-names.patch queue-4.16/sctp-do-not-leak-kernel-memory-to-user-space.patch queue-4.16/ip_tunnel-better-validate-user-provided-tunnel-names.patch queue-4.16/ip6_gre-better-validate-user-provided-tunnel-names.patch

7 years, 6 months

1
0
0 0

Patch "nfp: use full 40 bits of the NSP buffer address" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nfp: use full 40 bits of the NSP buffer address to the 4.16-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: nfp-use-full-40-bits-of-the-nsp-buffer-address.patch and it can be found in the queue-4.16 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:19:25 CEST 2018 From: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com> Date: Tue, 3 Apr 2018 17:24:23 -0700 Subject: nfp: use full 40 bits of the NSP buffer address From: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com> [ Upstream commit 1489bbd10e16079ce30a53d3c22a431fd47af791 ] The NSP default buffer is a piece of NFP memory where additional command data can be placed. Its format has been copied from host buffer, but the PCIe selection bits do not make sense in this case. If those get masked out from a NFP address - writes to random place in the chip memory may be issued and crash the device. Even in the general NSP buffer case, it doesn't make sense to have the PCIe selection bits there anymore. These are unused at the moment, and when it becomes necessary, the PCIe selection bits should rather be moved to another register to utilise more bits for the buffer address. This has never been an issue because the buffer used to be allocated in memory with less-than-38-bit-long address but that is about to change. Fixes: 1a64821c6af7 ("nfp: add support for service processor access") Signed-off-by: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com> Reviewed-by: Jakub Kicinski <jakub.kicinski(a)netronome.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c +++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nsp.c @@ -71,10 +71,11 @@ /* CPP address to retrieve the data from */ #define NSP_BUFFER 0x10 #define NSP_BUFFER_CPP GENMASK_ULL(63, 40) -#define NSP_BUFFER_PCIE GENMASK_ULL(39, 38) -#define NSP_BUFFER_ADDRESS GENMASK_ULL(37, 0) +#define NSP_BUFFER_ADDRESS GENMASK_ULL(39, 0) #define NSP_DFLT_BUFFER 0x18 +#define NSP_DFLT_BUFFER_CPP GENMASK_ULL(63, 40) +#define NSP_DFLT_BUFFER_ADDRESS GENMASK_ULL(39, 0) #define NSP_DFLT_BUFFER_CONFIG 0x20 #define NSP_DFLT_BUFFER_SIZE_MB GENMASK_ULL(7, 0) @@ -427,8 +428,8 @@ __nfp_nsp_command_buf(struct nfp_nsp *ns if (err < 0) return err; - cpp_id = FIELD_GET(NSP_BUFFER_CPP, reg) << 8; - cpp_buf = FIELD_GET(NSP_BUFFER_ADDRESS, reg); + cpp_id = FIELD_GET(NSP_DFLT_BUFFER_CPP, reg) << 8; + cpp_buf = FIELD_GET(NSP_DFLT_BUFFER_ADDRESS, reg); if (in_buf && in_size) { err = nfp_cpp_write(cpp, cpp_id, cpp_buf, in_buf, in_size); Patches currently in stable-queue which might be from dirk.vandermerwe(a)netronome.com are queue-4.16/nfp-use-full-40-bits-of-the-nsp-buffer-address.patch

7 years, 6 months

1
0
0 0

Patch "net_sched: fix a missing idr_remove() in u32_delete_key()" has been added to the 4.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net_sched: fix a missing idr_remove() in u32_delete_key() to the 4.16-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: net_sched-fix-a-missing-idr_remove-in-u32_delete_key.patch and it can be found in the queue-4.16 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:19:25 CEST 2018 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Fri, 6 Apr 2018 17:19:41 -0700 Subject: net_sched: fix a missing idr_remove() in u32_delete_key() From: Cong Wang <xiyou.wangcong(a)gmail.com> [ Upstream commit f12c643209db0626f2f54780d86bb93bfa7a9c2d ] When we delete a u32 key via u32_delete_key(), we forget to call idr_remove() to remove its handle from IDR. Fixes: e7614370d6f0 ("net_sched: use idr to allocate u32 filter handles") Reported-by: Marcin Kabiesz <admin(a)hostcenter.eu> Tested-by: Marcin Kabiesz <admin(a)hostcenter.eu> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sched/cls_u32.c | 1 + 1 file changed, 1 insertion(+) --- a/net/sched/cls_u32.c +++ b/net/sched/cls_u32.c @@ -489,6 +489,7 @@ static int u32_delete_key(struct tcf_pro RCU_INIT_POINTER(*kp, key->next); tcf_unbind_filter(tp, &key->res); + idr_remove(&ht->handle_idr, key->handle); tcf_exts_get_net(&key->exts); call_rcu(&key->rcu, u32_delete_key_freepf_rcu); return 0; Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-4.16/net_sched-fix-a-missing-idr_remove-in-u32_delete_key.patch

7 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror