4.4.128-stable review
Subsystems (7)
Re: [PATCH 4.4 164/190] futex: Remove requirement for lock_page() in get_futex_key()
In reply to Greg Kroah-HartmanQuoted 7 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mel Gorman <[email protected]>
commit
65d8fc777f6dcfee12785c057a6b57f679641c90upstream.
[...]
This causes regressions, fixed upstream by:
commit 077fa7aed17de5022e44bf07dbaf732078b7b5b2
Author: Mel Gorman <[email protected]>
Date: Wed Jun 8 14:25:22 2016 +0100
futex: Calculate the futex key based on a tail page for file-based futexes
commit 48fb6f4db940e92cfb16cd878cddd59ea6120d06
Author: Mel Gorman <[email protected]>
Date: Wed Aug 9 08:27:11 2017 +0100
futex: Remove unnecessary warning from get_futex_key
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Re: [PATCH 4.4 164/190] futex: Remove requirement for lock_page() in get_futex_key()
Quoted 11 lines · Ben Hutchings
Quoted 7 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mel Gorman <[email protected]>
commit
65d8fc777f6dcfee12785c057a6b57f679641c90upstream.[...]
Quoted 7 lines
This causes regressions, fixed upstream by:
commit
077fa7aed17de5022e44bf07dbaf732078b7b5b2
Author: Mel Gorman <[email protected]>
Date: Wed Jun 8 14:25:22 2016 +0100futex: Calculate the futex key based on a tail page for file-based futexes
Actually I think this backport to 4.4 incorporated the fix above, but the one below still looks applicable.
Ben.
Quoted 8 lines
commit
48fb6f4db940e92cfb16cd878cddd59ea6120d06
Author: Mel Gorman <[email protected]>
Date: Wed Aug 9 08:27:11 2017 +0100futex: Remove unnecessary warning from
get_futex_keyBen.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 164/190] futex: Remove requirement for lock_page() in get_futex_key()
Quoted 18 lines · Ben Hutchings
Quoted 17 lines · Ben Hutchings
Quoted 7 lines · Greg Kroah-Hartman
4.4-stable review patch.��If anyone has any objections, please let me know.
------------------
From: Mel Gorman <[email protected]>
commit
65d8fc777f6dcfee12785c057a6b57f679641c90upstream.[...]
This causes regressions, fixed upstream by:
commit
077fa7aed17de5022e44bf07dbaf732078b7b5b2
Author: Mel Gorman <[email protected]>
Date:���Wed Jun 8 14:25:22 2016 +0100
Quoted 12 lines
Quoted 1 line
����futex: Calculate the futex key based on a tail page for file-based futexes
Actually I think this backport to 4.4 incorporated the fix above, but the one below still looks applicable.
Ben.
Quoted 5 lines
commit
48fb6f4db940e92cfb16cd878cddd59ea6120d06
Author: Mel Gorman <[email protected]>
Date:���Wed Aug 9 08:27:11 2017 +0100����futex: Remove unnecessary warning from
get_futex_key
Thanks, I missed that one, now queued up.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 165/190 Kbuild: provide a __UNIQUE_ID for clang
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit b41c29b0527c7fd6a95d0f71274abb79933bf960 upstream.
The default __UNIQUE_ID macro in compiler.h fails to work for some drivers:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:615:1: error: redefinition of
'__UNIQUE_ID_firmware615'
BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
This adds a copy of the version we use for gcc-4.3 and higher, as the same one works with all versions of clang that I could find in svn (2.6 and higher).
--- include/linux/compiler-clang.h | 5 +++++ 1 file changed, 5 insertions(+)
include/linux/compiler-clang.h +5 -0
@@ -10,3 +10,8 @@#undef uninitialized_var#define uninitialized_var (x) x = *(&(x))#endif + +/* same as gcc, this was present in clang-2.6 so we can assume it works +* with any version that can compile the kernel +*/ +#define __UNIQUE_ID (prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
Greg Kroah-Hartman
maintainerPATCH 166/190 arp: fix arp_filter on l3slave devices
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miguel Fadon Perlines <[email protected]>
[ 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.
--- net/ipv4/arp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/arp.c +1 -1
@@ -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) {
Greg Kroah-Hartman
maintainerPATCH 167/190 net: fix possible out-of-bound read in skb_network_protocol()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 1dfe82ebd7d8fd43dba9948fdfb31f145014baa0 ]
skb mac header is not necessarily set at the time skb_network_protocol() is called. Use skb->data instead.
BUG: KASAN: slab-out-of-bounds in skb_network_protocol+0x46b/0x4b0 net/core/dev.c:2739 Read of size 2 at addr ffff8801b3097a0b by task syz-executor5/14242 CPU: 1 PID: 14242 Comm: syz-executor5 Not tainted 4.16.0-rc6+ #280 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+0x194/0x24d 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 __asan_report_load_n_noabort+0xf/0x20 mm/kasan/report.c:443 skb_network_protocol+0x46b/0x4b0 net/core/dev.c:2739 harmonize_features net/core/dev.c:2924 [inline] netif_skb_features+0x509/0x9b0 net/core/dev.c:3011 validate_xmit_skb+0x81/0xb00 net/core/dev.c:3084 validate_xmit_skb_list+0xbf/0x120 net/core/dev.c:3142 packet_direct_xmit+0x117/0x790 net/packet/af_packet.c:256 packet_snd net/packet/af_packet.c:2944 [inline] packet_sendmsg+0x3aed/0x60b0 net/packet/af_packet.c:2969 sock_sendmsg_nosec net/socket.c:629 [inline] sock_sendmsg+0xca/0x110 net/socket.c:639 ___sys_sendmsg+0x767/0x8b0 net/socket.c:2047 __sys_sendmsg+0xe5/0x210 net/socket.c:2081
--- net/core/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/core/dev.c +1 -1
@@ -2515,7 +2515,7 @@ __be16 skb_network_protocol(struct sk_buif (unlikely (!pskb_may_pull (skb,sizeof (struct ethhdr ))))return 0 ; - eth = (struct ethhdr *)skb_mac_header (skb); + eth = (struct ethhdr *)skb->data; type = eth->h_proto; }
Greg Kroah-Hartman
maintainerPATCH 168/190 net/ipv6: Fix route leaking between VRFs
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Ahern <[email protected]>
[ Upstream commit b6cdbc85234b072340b8923e69f49ec293f905dc ]
Donald reported that IPv6 route leaking between VRFs is not working. The root cause is the strict argument in the call to rt6_lookup when validating the nexthop spec.
ip6_route_check_nh validates the gateway and device (if given) of a route spec. It in turn could call rt6_lookup (e.g., lookup in a given table did not succeed so it falls back to a full lookup) and if so sets the strict argument to 1. That means if the egress device is given, the route lookup needs to return a result with the same device. This strict requirement does not work with VRFs (IPv4 or IPv6) because the oif in the flow struct is overridden with the index of the VRF device to trigger a match on the l3mdev rule and force the lookup to its table.
The right long term solution is to add an l3mdev index to the flow struct such that the oif is not overridden. That solution will not backport well, so this patch aims for a simpler solution to relax the strict argument if the route spec device is an l3mdev slave. As done in other places, use the FLOWI_FLAG_SKIP_NH_OIF to know that the RT6_LOOKUP_F_IFACE flag needs to be removed.
--- net/ipv6/route.c | 3 +++ 1 file changed, 3 insertions(+)
net/ipv6/route.c +3 -0
@@ -851,6 +851,9 @@ static struct rt6_info *ip6_pol_route_lostruct fib6_node *fn;struct rt6_info *rt; +if (fl6->flowi6_flags &FLOWI_FLAG_SKIP_NH_OIF ) + flags &= ~RT6_LOOKUP_F_IFACE ; +read_lock_bh (&table->tb6_lock); fn =fib6_lookup (&table->tb6_root, &fl6->daddr, &fl6->saddr); restart:
Greg Kroah-Hartman
maintainerPATCH 169/190 netlink: make sure nladdr has correct size in netlink_connect()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Potapenko <[email protected]>
[ Upstream commit 7880287981b60a6808f39f297bb66936e8bdf57a ]
KMSAN reports use of uninitialized memory in the case when |alen| is smaller than sizeof(struct sockaddr_nl), and therefore |nladdr| isn't fully copied from the userspace.
--- net/netlink/af_netlink.c | 3 +++ 1 file changed, 3 insertions(+)
net/netlink/af_netlink.c +3 -0
@@ -1054,6 +1054,9 @@ static int netlink_connect(struct socketif (addr->sa_family !=AF_NETLINK )return -EINVAL ; +if (alen <sizeof (struct sockaddr_nl )) +return -EINVAL ; +if ((nladdr->nl_groups || nladdr->nl_pid) && !netlink_allowed (sock,NL_CFG_F_NONROOT_SEND ))return -EPERM ;
Greg Kroah-Hartman
maintainerPATCH 170/190 net/sched: fix NULL dereference in the error path of tcf_bpf_init()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Davide Caratti <[email protected]>
[ Upstream commit 3239534a79ee6f20cffd974173a1e62e0730e8ac ]
when tcf_bpf_init_from_ops() fails (e.g. because of program having invalid number of instructions), tcf_bpf_cfg_cleanup() calls bpf_prog_put(NULL) or bpf_prog_destroy(NULL). Unless CONFIG_BPF_SYSCALL is unset, this causes the following error:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 PGD 800000007345a067 P4D 800000007345a067 PUD 340e1067 PMD 0 Oops: 0000 [#1] SMP PTI Modules linked in: act_bpf(E) ip6table_filter ip6_tables iptable_filter binfmt_misc ext4 mbcache jbd2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic pcbc snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm aesni_intel crypto_simd glue_helper cryptd joydev snd_timer snd virtio_balloon pcspkr soundcore i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi qxl drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm virtio_blk drm virtio_net virtio_console i2c_core crc32c_intel serio_raw virtio_pci ata_piix libata virtio_ring floppy virtio dm_mirror dm_region_hash dm_log dm_mod [last unloaded: act_bpf] CPU: 3 PID: 5654 Comm: tc Tainted: G E 4.16.0.bpf_test+ #408 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__bpf_prog_put+0xc/0xc0 RSP: 0018:ffff9594003ef728 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff9594003ef758 RCX: 0000000000000024 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044 R10: 0000000000000220 R11: ffff8a7ab9f17131 R12: 0000000000000000 R13: ffff8a7ab7c3c8e0 R14: 0000000000000001 R15: ffff8a7ab88f1054 FS: 00007fcb2f17c740(0000) GS:ffff8a7abfd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 000000007c888006 CR4: 00000000001606e0 Call Trace: tcf_bpf_cfg_cleanup+0x2f/0x40 [act_bpf] tcf_bpf_cleanup+0x4c/0x70 [act_bpf] __tcf_idr_release+0x79/0x140 tcf_bpf_init+0x125/0x330 [act_bpf] tcf_action_init_1+0x2cc/0x430 ? get_page_from_freelist+0x3f0/0x11b0 tcf_action_init+0xd3/0x1b0 tc_ctl_action+0x18b/0x240 rtnetlink_rcv_msg+0x29c/0x310 ? _cond_resched+0x15/0x30 ? __kmalloc_node_track_caller+0x1b9/0x270 ? rtnl_calcit.isra.29+0x100/0x100 netlink_rcv_skb+0xd2/0x110 netlink_unicast+0x17c/0x230 netlink_sendmsg+0x2cd/0x3c0 sock_sendmsg+0x30/0x40 ___sys_sendmsg+0x27a/0x290 ? mem_cgroup_commit_charge+0x80/0x130 ? page_add_new_anon_rmap+0x73/0xc0 ? do_anonymous_page+0x2a2/0x560 ? __handle_mm_fault+0xc75/0xe20 __sys_sendmsg+0x58/0xa0 do_syscall_64+0x6e/0x1a0 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x7fcb2e58eba0 RSP: 002b:00007ffc93c496c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007ffc93c497f0 RCX: 00007fcb2e58eba0 RDX: 0000000000000000 RSI: 00007ffc93c49740 RDI: 0000000000000003 RBP: 000000005ac6a646 R08: 0000000000000002 R09: 0000000000000000 R10: 00007ffc93c49120 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc93c49804 R14: 0000000000000001 R15: 000000000066afa0 Code: 5f 00 48 8b 43 20 48 c7 c7 70 2f 7c b8 c7 40 10 00 00 00 00 5b e9 a5 8b 61 00 0f 1f 44 00 00 0f 1f 44 00 00 41 54 55 48 89 fd 53 <48> 8b 47 20 f0 ff 08 74 05 5b 5d 41 5c c3 41 89 f4 0f 1f 44 00 RIP: __bpf_prog_put+0xc/0xc0 RSP: ffff9594003ef728 CR2: 0000000000000020
Fix it in tcf_bpf_cfg_cleanup(), ensuring that bpf_prog_{put,destroy}(f) is called only when f is not NULL.
--- net/sched/act_bpf.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
net/sched/act_bpf.c +8 -4
@@ -249,10 +249,14 @@ static int tcf_bpf_init_from_efd(structstatic void tcf_bpf_cfg_cleanup (const struct tcf_bpf_cfg *cfg) { -if (cfg->is_ebpf) -bpf_prog_put (cfg->filter); -else -bpf_prog_destroy (cfg->filter); +struct bpf_prog *filter = cfg->filter; + +if (filter) { +if (cfg->is_ebpf) +bpf_prog_put (filter); +else +bpf_prog_destroy (filter); + }kfree (cfg->bpf_ops);kfree (cfg->bpf_name);
Greg Kroah-Hartman
maintainerPATCH 171/190 pptp: remove a buggy dst release in pptp_connect()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ 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
--- drivers/net/ppp/pptp.c | 1 - 1 file changed, 1 deletion(-)
drivers/net/ppp/pptp.c +0 -1
@@ -501,7 +501,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 );
Greg Kroah-Hartman
maintainerPATCH 172/190 sctp: do not leak kernel memory to user space
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ 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
--- net/sctp/ipv6.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/sctp/ipv6.c +3 -1
@@ -723,8 +723,10 @@ static int sctp_v6_addr_to_user(struct ssctp_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 ); }
Greg Kroah-Hartman
maintainerPATCH 173/190 sctp: sctp_sockaddr_af must check minimal addr length for AF_INET6
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ 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
--- net/sctp/socket.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
net/sctp/socket.c +8 -5
@@ -335,11 +335,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);
Greg Kroah-Hartman
maintainerPATCH 174/190 sky2: Increase D3 delay to sky2 stops working after suspend
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kai-Heng Feng <[email protected]>
[ 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.
--- drivers/net/ethernet/marvell/sky2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/marvell/sky2.c +1 -1
@@ -5079,7 +5079,7 @@ static int sky2_probe(struct pci_dev *pdINIT_WORK (&hw->restart_work, sky2_restart);pci_set_drvdata (pdev, hw); - pdev->d3_delay =150 ; + pdev->d3_delay =200 ;return 0 ;
Greg Kroah-Hartman
maintainerPATCH 175/190 vhost: correctly remove wait queue during poll failure
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Wang <[email protected]>
[ Upstream commit dc6455a71c7fc5117977e197f67f71b49f27baba ]
We tried to remove vq poll from wait queue, but do not check whether or not it was in a list before. This will lead double free. Fixing this by switching to use vhost_poll_stop() which zeros poll->wqh after removing poll from waitqueue to make sure it won't be freed twice.
--- drivers/vhost/vhost.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/vhost/vhost.c +1 -2
@@ -173,8 +173,7 @@ int vhost_poll_start(struct vhost_poll *if (mask)vhost_poll_wakeup (&poll->wait,0 ,0 , (void *)mask);if (mask &POLLERR ) { -if (poll->wqh) -remove_wait_queue (poll->wqh, &poll->wait); +vhost_poll_stop (poll); ret = -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 176/190 vlan: also check phy_driver ts_info for vlans real device
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hangbin Liu <[email protected]>
[ 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.
--- net/8021q/vlan_dev.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/8021q/vlan_dev.c +5 -1
@@ -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 "vlan.h"
@@ -654,8 +655,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 |
Greg Kroah-Hartman
maintainerPATCH 177/190 bonding: fix the err path for dev hwaddr sync in bond_enslave
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ 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.
--- drivers/net/bonding/bond_main.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/net/bonding/bond_main.c +5 -4
@@ -1527,7 +1527,7 @@ int bond_enslave(struct net_device *bondif (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);
@@ -1709,9 +1709,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 );
@@ -1725,6 +1722,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);
Greg Kroah-Hartman
maintainerPATCH 178/190 bonding: move dev_mc_sync after master_upper_dev_link in bond_enslave
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ 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.
--- drivers/net/bonding/bond_main.c | 73 +++++++++++++++++++--------------------- 1 file changed, 35 insertions(+), 38 deletions(-)
drivers/net/bonding/bond_main.c +35 -38
@@ -1490,44 +1490,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);
@@ -1679,6 +1646,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);
@@ -1702,6 +1700,9 @@ int bond_enslave(struct net_device *bondreturn 0 ;/* Undo stages on error */ +err_sysfs_del: +bond_sysfs_slave_del (new_slave); + err_upper_unlink:bond_upper_dev_unlink (bond_dev, slave_dev);
@@ -1722,10 +1723,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);
Greg Kroah-Hartman
maintainerPATCH 179/190 bonding: process the err returned by dev_set_allmulti properly in bond_enslave
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ 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.
--- drivers/net/bonding/bond_main.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/bonding/bond_main.c +4 -1
@@ -1660,8 +1660,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);
Greg Kroah-Hartman
maintainerPATCH 180/190 net: fool proof dev_valid_name()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit a9d48205d0aedda021fc3728972a9e9934c2b9de ]
We want to use dev_valid_name() to validate tunnel names, so better use strnlen(name, IFNAMSIZ) than strlen(name) to make sure to not upset KASAN.
--- net/core/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/core/dev.c +1 -1
@@ -989,7 +989,7 @@ bool dev_valid_name(const char *name) {if (*name =='\0' )return false; -if (strlen (name) >=IFNAMSIZ ) +if (strnlen (name,IFNAMSIZ ) ==IFNAMSIZ )return false;if (!strcmp (name,"." ) || !strcmp (name,".." ))return false;
Greg Kroah-Hartman
maintainerPATCH 181/190 ip_tunnel: better validate user provided tunnel names
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ 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
--- net/ipv4/ip_tunnel.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
net/ipv4/ip_tunnel.c +6 -5
@@ -253,13 +253,14 @@ static struct net_device *__ip_tunnel_crstruct 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 ); }
Greg Kroah-Hartman
maintainerPATCH 182/190 ipv6: sit: better validate user provided tunnel names
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit b95211e066fc3494b7c115060b2297b4ba21f025 ]
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 ipip6_tunnel_locate+0x63b/0xaa0 net/ipv6/sit.c:254 Write of size 33 at addr ffff8801b64076d8 by task syzkaller932654/4453 CPU: 0 PID: 4453 Comm: syzkaller932654 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] ipip6_tunnel_locate+0x63b/0xaa0 net/ipv6/sit.c:254 ipip6_tunnel_ioctl+0xe71/0x241b net/ipv6/sit.c:1221 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
--- net/ipv6/sit.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
net/ipv6/sit.c +5 -3
@@ -244,11 +244,13 @@ static struct ip_tunnel *ipip6_tunnel_loif (!create) goto failed; -if (parms->name[0 ]) +if (parms->name[0 ]) { +if (!dev_valid_name (parms->name)) + goto failed;strlcpy (name, parms->name,IFNAMSIZ ); -else + }else {strcpy (name,"sit%d" ); - + } dev =alloc_netdev (sizeof (*t), name,NET_NAME_UNKNOWN , ipip6_tunnel_setup);if (!dev)
Greg Kroah-Hartman
maintainerPATCH 183/190 ip6_gre: better validate user provided tunnel names
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ 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
--- net/ipv6/ip6_gre.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
net/ipv6/ip6_gre.c +5 -3
@@ -320,11 +320,13 @@ static struct ip6_tnl *ip6gre_tunnel_locif (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)
Greg Kroah-Hartman
maintainerPATCH 184/190 ip6_tunnel: better validate user provided tunnel names
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit db7a65e3ab78e5b1c4b17c0870ebee35a4ee3257 ]
Use valid_name() to make sure user does not provide illegal device name.
--- net/ipv6/ip6_tunnel.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
net/ipv6/ip6_tunnel.c +7 -4
@@ -286,13 +286,16 @@ static struct ip6_tnl *ip6_tnl_create(ststruct 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)
Greg Kroah-Hartman
maintainerPATCH 185/190 vti6: better validate user provided tunnel names
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 537b361fbcbcc3cd6fe2bb47069fd292b9256d16 ]
Use valid_name() to make sure user does not provide illegal device name.
--- net/ipv6/ip6_vti.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
net/ipv6/ip6_vti.c +5 -2
@@ -212,10 +212,13 @@ static struct ip6_tnl *vti6_tnl_create(schar 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)
Greg Kroah-Hartman
maintainerPATCH 186/190 r8169: fix setting driver_data after register_netdev
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
[ Upstream commit 19c9ea363a244f85f90a424f9936e6d56449e33c ]
pci_set_drvdata() is called only after registering the net_device, therefore we could run into a NPE if one of the functions using driver_data is called before it's set.
Fix this by calling pci_set_drvdata() before registering the net_device.
This fix is a candidate for stable. As far as I can see the bug has been there in kernel version 3.2 already, therefore I can't provide a reference which commit is fixed by it.
The fix may need small adjustments per kernel version because due to other changes the label which is jumped to if register_netdev() fails has changed over time.
--- drivers/net/ethernet/realtek/r8169.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/realtek/r8169.c +2 -2
@@ -8411,12 +8411,12 @@ static int rtl_init_one(struct pci_dev * goto err_out_msi_4; } +pci_set_drvdata (pdev, dev); + rc =register_netdev (dev);if (rc <0 ) goto err_out_cnt_5; -pci_set_drvdata (pdev, dev); -netif_info (tp, probe, dev,"%s at 0x%p, %pM, XID %08x IRQ %d\n" , rtl_chip_infos[chipset].name, ioaddr, dev->dev_addr, (u32)(RTL_R32 (TxConfig) &0x9cf0f8ff ), pdev->irq);
Greg Kroah-Hartman
maintainerPATCH 187/190 net sched actions: fix dumping which requires several messages to user space
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Craig Dillabaugh <[email protected]>
[ Upstream commit 734549eb550c0c720bc89e50501f1b1e98cdd841 ]
Fixes a bug in the tcf_dump_walker function that can cause some actions to not be reported when dumping a large number of actions. This issue became more aggrevated when cookies feature was added. In particular this issue is manifest when large cookie values are assigned to the actions and when enough actions are created that the resulting table must be dumped in multiple batches.
The number of actions returned in each batch is limited by the total number of actions and the memory buffer size. With small cookies the numeric limit is reached before the buffer size limit, which avoids the code path triggering this bug. When large cookies are used buffer fills before the numeric limit, and the erroneous code path is hit.
For example after creating 32 csum actions with the cookie aaaabbbbccccdddd
$ tc actions ls action csum total acts 26
action order 0: csum (tcp) action continue
index 1 ref 1 bind 0
cookie aaaabbbbccccdddd
.....
action order 25: csum (tcp) action continue
index 26 ref 1 bind 0
cookie aaaabbbbccccdddd
total acts 6
action order 0: csum (tcp) action continue
index 28 ref 1 bind 0
cookie aaaabbbbccccdddd
......
action order 5: csum (tcp) action continue
index 32 ref 1 bind 0
cookie aaaabbbbccccdddd
Note that the action with index 27 is omitted from the report.
--- net/sched/act_api.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/sched/act_api.c +3 -1
@@ -101,8 +101,10 @@ static int tcf_dump_walker(struct sk_buf a->order = n_i; nest =nla_nest_start (skb, a->order); -if (nest ==NULL ) +if (nest ==NULL ) { + index--; goto nla_put_failure; + } err =tcf_action_dump_1 (skb, a,0 ,0 );if (err <0 ) { index--;
Greg Kroah-Hartman
maintainerPATCH 188/190 net/ipv6: Increment OUTxxx counters after netfilter hook
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Barnhill <[email protected]>
[ Upstream commit 71a1c915238c970cd9bdd5bf158b1279d6b6d55b ]
At the end of ip6_forward(), IPSTATS_MIB_OUTFORWDATAGRAMS and IPSTATS_MIB_OUTOCTETS are incremented immediately before the NF_HOOK call for NFPROTO_IPV6 / NF_INET_FORWARD. As a result, these counters get incremented regardless of whether or not the netfilter hook allows the packet to continue being processed. This change increments the counters in ip6_forward_finish() so that it will not happen if the netfilter hook chooses to terminate the packet, which is similar to how IPv4 works.
--- net/ipv6/ip6_output.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/ipv6/ip6_output.c +4 -2
@@ -340,6 +340,10 @@ static int ip6_forward_proxy_check(strucstatic inline int ip6_forward_finish (struct net *net,struct sock *sk,struct sk_buff *skb) { +struct dst_entry *dst =skb_dst (skb); + +IP6_INC_STATS_BH (net,ip6_dst_idev (dst),IPSTATS_MIB_OUTFORWDATAGRAMS ); +IP6_ADD_STATS_BH (net,ip6_dst_idev (dst),IPSTATS_MIB_OUTOCTETS , skb->len);skb_sender_cpu_clear (skb);return dst_output (net, sk, skb); }
@@ -534,8 +538,6 @@ int ip6_forward(struct sk_buff *skb) hdr->hop_limit--; -IP6_INC_STATS_BH (net,ip6_dst_idev (dst),IPSTATS_MIB_OUTFORWDATAGRAMS ); -IP6_ADD_STATS_BH (net,ip6_dst_idev (dst),IPSTATS_MIB_OUTOCTETS , skb->len);return NF_HOOK (NFPROTO_IPV6 ,NF_INET_FORWARD , net,NULL , skb, skb->dev, dst->dev, ip6_forward_finish);
Greg Kroah-Hartman
maintainerPATCH 189/190 ipv6: the entire IPv6 header chain must fit the first fragment
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
[ Upstream commit 10b8a3de603df7b96004179b1b33b1708c76d144 ]
While building ipv6 datagram we currently allow arbitrary large extheaders, even beyond pmtu size. The syzbot has found a way to exploit the above to trigger the following splat:
kernel BUG at ./include/linux/skbuff.h:2073!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in: CPU: 1 PID: 4230 Comm: syzkaller672661 Not tainted 4.16.0-rc2+ #326 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__skb_pull include/linux/skbuff.h:2073 [inline] RIP: 0010:__ip6_make_skb+0x1ac8/0x2190 net/ipv6/ip6_output.c:1636 RSP: 0018:ffff8801bc18f0f0 EFLAGS: 00010293 RAX: ffff8801b17400c0 RBX: 0000000000000738 RCX: ffffffff84f01828 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8801b415ac18 RBP: ffff8801bc18f360 R08: ffff8801b4576844 R09: 0000000000000000 R10: ffff8801bc18f380 R11: ffffed00367aee4e R12: 00000000000000d6 R13: ffff8801b415a740 R14: dffffc0000000000 R15: ffff8801b45767c0 FS: 0000000001535880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000b000 CR3: 00000001b4123001 CR4: 00000000001606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip6_finish_skb include/net/ipv6.h:969 [inline] udp_v6_push_pending_frames+0x269/0x3b0 net/ipv6/udp.c:1073 udpv6_sendmsg+0x2a96/0x3400 net/ipv6/udp.c:1343 inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg+0xca/0x110 net/socket.c:640 ___sys_sendmsg+0x320/0x8b0 net/socket.c:2046 __sys_sendmmsg+0x1ee/0x620 net/socket.c:2136 SYSC_sendmmsg net/socket.c:2167 [inline] SyS_sendmmsg+0x35/0x60 net/socket.c:2162 do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x4404c9 RSP: 002b:00007ffdce35f948 EFLAGS: 00000217 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004404c9 RDX: 0000000000000003 RSI: 0000000020001f00 RDI: 0000000000000003 RBP: 00000000006cb018 R08: 00000000004002c8 R09: 00000000004002c8 R10: 0000000020000080 R11: 0000000000000217 R12: 0000000000401df0 R13: 0000000000401e80 R14: 0000000000000000 R15: 0000000000000000 Code: ff e8 1d 5e b9 fc e9 15 e9 ff ff e8 13 5e b9 fc e9 44 e8 ff ff e8 29 5e b9 fc e9 c0 e6 ff ff e8 3f f3 80 fc 0f 0b e8 38 f3 80 fc <0f> 0b 49 8d 87 80 00 00 00 4d 8d 87 84 00 00 00 48 89 85 20 fe RIP: __skb_pull include/linux/skbuff.h:2073 [inline] RSP: ffff8801bc18f0f0 RIP: __ip6_make_skb+0x1ac8/0x2190 net/ipv6/ip6_output.c:1636 RSP:
ffff8801bc18f0f0
As stated by RFC 7112 section 5:
When a host fragments an IPv6 datagram, it MUST include the entire IPv6 Header Chain in the First Fragment.
So this patch addresses the issue dropping datagrams with excessive extheader length. It also updates the error path to report to the calling socket nonnegative pmtu values.
The issue apparently predates git history.
v1 -> v2: cleanup error path, as per Eric's suggestion
--- net/ipv6/ip6_output.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
net/ipv6/ip6_output.c +9 -4
@@ -1278,7 +1278,7 @@ static int __ip6_append_data(struct sock unsigned int flags, int dontfrag) {struct sk_buff *skb, *skb_prev =NULL ; -unsigned int maxfraglen, fragheaderlen, mtu, orig_mtu; +unsigned int maxfraglen, fragheaderlen, mtu, orig_mtu, pmtu;int exthdrlen =0 ;int dst_exthdrlen =0 ;int hh_len;
@@ -1314,6 +1314,12 @@ static int __ip6_append_data(struct sock sizeof(struct frag_hdr) : 0) + rt->rt6i_nfheader_len; +/* as per RFC 7112 section 5, the entire IPv6 Header Chain must fit +* the first fragment +*/ +if (headersize + transhdrlen > mtu) + goto emsgsize; +if (cork->length + length > mtu - headersize && dontfrag && (sk->sk_protocol ==IPPROTO_UDP || sk->sk_protocol ==IPPROTO_RAW )) {
@@ -1329,9 +1335,8 @@ static int __ip6_append_data(struct sockif (cork->length + length > maxnonfragsize - headersize) { emsgsize: -ipv6_local_error (sk,EMSGSIZE , fl6, - mtu - headersize + -sizeof (struct ipv6hdr )); + pmtu =max_t (int, mtu - headersize +sizeof (struct ipv6hdr ),0 ); +ipv6_local_error (sk,EMSGSIZE , fl6, pmtu);return -EMSGSIZE ; }
Greg Kroah-Hartman
maintainerPATCH 190/190 vrf: Fix use after free and double free in vrf_finish_output
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Ahern <[email protected]>
commit 82dd0d2a9a76fc8fa2b18d80b987d455728bf83a upstream.
Miguel reported an skb use after free / double free in vrf_finish_output when neigh_output returns an error. The vrf driver should return after the call to neigh_output as it takes over the skb on error path as well.
Patch is a simplified version of Miguel's patch which was written for 4.9, and updated to top of tree.
[ backport to 4.4 and 4.9 dropped the sock_confirm_neigh and
changed neigh_output to dst_neigh_output ]
--- drivers/net/vrf.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/net/vrf.c +5 -3
@@ -550,13 +550,15 @@ static int vrf_finish_output(struct net neigh =__ipv4_neigh_lookup_noref (dev, nexthop);if (unlikely (!neigh)) neigh =__neigh_create (&arp_tbl, &nexthop, dev, false); -if (!IS_ERR (neigh)) +if (!IS_ERR (neigh)) { ret =dst_neigh_output (dst, neigh, skb); +rcu_read_unlock_bh (); +return ret; + }rcu_read_unlock_bh (); err: -if (unlikely (ret <0 )) -vrf_tx_error (skb->dev, skb); +vrf_tx_error (skb->dev, skb);return ret; }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.128 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 13 18:34:54 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.
Ever since switching to Clang on the OP5 back in December, I haven't been compiling with GCC at all which was a mistake. So I have started compiling with Google's GCC 4.9.4, Bootlin's GCC 7.3.0, Google's Clang 5.0, and my own Clang 6.0 and 7.0. All builds completed successfully with -Werror.
No initial issues in dmesg or general usage.
Thanks!
Nathan
Greg Kroah-Hartman
maintainerQuoted 22 lines · Nathan Chancellor
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.128 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 13 18:34:54 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.
Quoted 7 lines
Ever since switching to Clang on the OP5 back in December, I haven't been compiling with GCC at all which was a mistake. So I have started compiling with Google's GCC 4.9.4, Bootlin's GCC 7.3.0, Google's Clang 5.0, and my own Clang 6.0 and 7.0. All builds completed successfully with -Werror.
No initial issues in dmesg or general usage.
Great! Thanks for testing and letting me know.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.128 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 13 18:34:54 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
stable-rc/linux-4.4.y boot: 61 boots: 3 failed, 56 passed with 2 untried/unknown (v4.4.127-191-ge9832d7653b2)
stable-rc/linux-4.4.y boot: 61 boots: 3 failed, 56 passed with 2 untried/unknown (v4.4.127-191-ge9832d7653b2)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.127-191-ge9832d7653b2/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.127-191-ge9832d7653b2/
Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.127-191-ge9832d7653b2
Git Commit: e9832d7653b2d69d156dcad4c78f82330c781aff
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 30 unique boards, 13 SoC families, 13 builds out of 178
Boot Regressions Detected:
arm:
at91_dt_defconfig:
at91sam9m10g45ek:
lab-free-electrons: new failure (last pass: v4.4.127-166-ge5eeab3948ec)
exynos_defconfig:
exynos5422-odroidxu3:
lab-collabora: failing since 1 day (last pass: v4.4.127 - first fail: v4.4.127-166-ge5eeab3948ec)
multi_v7_defconfig:
armada-375-db:
lab-free-electrons: new failure (last pass: v4.4.127-166-ge5eeab3948ec)Boot Failures Detected:
arm:
at91_dt_defconfig
at91sam9m10g45ek: 1 failed lab
exynos_defconfig
exynos5422-odroidxu3: 1 failed lab
multi_v7_defconfig
armada-375-db: 1 failed lab---
For more info write to <[email protected]>
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.128 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 13 18:34:54 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.128-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.4.128-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: e9832d7653b2d69d156dcad4c78f82330c781aff
git describe: v4.4.127-191-ge9832d7653b2
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.127-191-ge9832d7653b2
No regressions (compared to build v4.4.127-166-ge5eeab3948ec)
Boards, architectures and test suites:
-------------------------------------
juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 30, pass: 33
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 53, pass: 28
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 152, pass: 998
* ltp-timers-tests - skip: 1, pass: 12
qemu_x86_64
* boot - pass: 22
* kselftest - skip: 33, pass: 47
* kselftest-vsyscall-mode-native - skip: 33, pass: 47
* kselftest-vsyscall-mode-none - skip: 33, pass: 47
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 150, pass: 1000
* ltp-timers-tests - skip: 1, pass: 12
x15 - arm
* boot - pass: 20
* kselftest - skip: 29, pass: 32
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 98, pass: 1052
* ltp-timers-tests - skip: 1, pass: 12
x86_64
* boot - pass: 22
* kselftest - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-native - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-none - skip: 31, fail: 2, pass: 47
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 62
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 5, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 120, pass: 1030
* ltp-timers-tests - skip: 1, pass: 12
Hikey test results,
Summary
------------------------------------------------------------------------
kernel: 4.4.128-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.128-rc1-hikey-20180411-171
git commit: 692c708326e6648cb5dcbc0b0e88b8036ca2fdbd
git describe: 4.4.128-rc1-hikey-20180411-171
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.128-rc1-hikey-20180411-171
No regressions (compared to build 4.4.128-rc1-hikey-20180410-170)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - pass: 21
* kselftest - skip: 32, pass: 31
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 53, pass: 28
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 154, pass: 996
* ltp-timers-tests - skip: 1, pass: 12
Linaro QA (beta)
https://qa-reports.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.128 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri Apr 13 18:34:54 UTC 2018. Anything received after that time might be too late.
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 127 pass: 127 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter