commit dcd888983542055210f5e68f1b1f1f8fe11a369a Author: Greg Kroah-Hartman Date: Sun Jan 12 12:17:30 2020 +0100 Linux 4.19.95 commit aad8003ad201c518d8200f1da587b6a24150c4e4 Author: Qi Zhou Date: Sat Jan 4 11:02:01 2020 +0000 usb: missing parentheses in USE_NEW_SCHEME commit 1530f6f5f5806b2abbf2a9276c0db313ae9a0e09 upstream. According to bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") the kernel will try the old enumeration scheme first for high speed devices. This can happen when a high speed device is plugged in. But due to missing parentheses in the USE_NEW_SCHEME define, this logic can get messed up and the incorrect result happens. Acked-by: Alan Stern Signed-off-by: Qi Zhou Link: https://lore.kernel.org/r/ht4mtag8ZP-HKEhD0KkJhcFnVlOFV8N8eNjJVRD9pDkkLUNhmEo8_cL_sl7xy9mdajdH-T8J3TFQsjvoYQT61NFjQXy469Ed_BbBw_x4S1E=@protonmail.com [ fixup changelog text - gregkh] Cc: stable Fixes: bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") Signed-off-by: Greg Kroah-Hartman commit a16ae61375c0016b624c3e56bf7de50e8dcb2ea1 Author: Daniele Palmas Date: Fri Dec 13 14:56:15 2019 +0100 USB: serial: option: add Telit ME910G1 0x110a composition commit 0d3010fa442429f8780976758719af05592ff19f upstream. This patch adds the following Telit ME910G1 composition: 0x110a: tty, tty, tty, rmnet Signed-off-by: Daniele Palmas Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f85541a5d8d5223706f7874630ba4907e647ced4 Author: Johan Hovold Date: Thu Dec 19 17:10:16 2019 +0100 USB: core: fix check for duplicate endpoints commit 3e4f8e21c4f27bcf30a48486b9dcc269512b79ff upstream. Amend the endpoint-descriptor sanity checks to detect all duplicate endpoint addresses in a configuration. Commit 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses") added a check for duplicate endpoint addresses within a single alternate setting, but did not look for duplicate addresses in other interfaces. The current check would also not detect all duplicate addresses when one endpoint is as a (bi-directional) control endpoint. This specifically avoids overwriting the endpoint entries in struct usb_device when enabling a duplicate endpoint, something which could potentially lead to crashes or leaks, for example, when endpoints are later disabled. Cc: stable Signed-off-by: Johan Hovold Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191219161016.6695-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit ceaeb21b4bdaaad81577abcbf1c86d35a31071aa Author: Thinh Nguyen Date: Fri Dec 13 18:40:45 2019 -0800 usb: dwc3: gadget: Fix request complete check commit ea0d762775e20aaff7909a3f0866ff1688b1c618 upstream. We can only check for IN direction if the request had completed. For OUT direction, it's perfectly fine that the host can send less than the setup length. Let's return true fall all cases of OUT direction. Fixes: e0c42ce590fe ("usb: dwc3: gadget: simplify IOC handling") Cc: stable@vger.kernel.org Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/ac5a3593a94fdaa3d92e6352356b5f7a01ccdc7c.1576291140.git.thinhn@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 672d3ca2f395c8e1b92b79c03ef38953dfe79caa Author: Petr Machata Date: Mon Jan 6 18:01:56 2020 +0000 net: sch_prio: When ungrafting, replace with FIFO [ Upstream commit 240ce7f6428ff5188b9eedc066e1e4d645b8635f ] When a child Qdisc is removed from one of the PRIO Qdisc's bands, it is replaced unconditionally by a NOOP qdisc. As a result, any traffic hitting that band gets dropped. That is incorrect--no Qdisc was explicitly added when PRIO was created, and after removal, none should have to be added either. Fix PRIO by first attempting to create a default Qdisc and only falling back to noop when that fails. This pattern of attempting to create an invisible FIFO, using NOOP only as a fallback, is also seen in other Qdiscs. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Petr Machata Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 741cf884069e8260c6ec9a1e7dcc5fe516867a60 Author: Petr Machata Date: Mon Jan 6 18:01:55 2020 +0000 mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO [ Upstream commit 3971a535b839489e4ea31796cc086e6ce616318c ] The following patch will change PRIO to replace a removed Qdisc with an invisible FIFO, instead of NOOP. mlxsw will see this replacement due to the graft message that is generated. But because FIFO does not issue its own REPLACE message, when the graft operation takes place, the Qdisc that mlxsw tracks under the indicated band is still the old one. The child handle (0:0) therefore does not match, and mlxsw rejects the graft operation, which leads to an extack message: Warning: Offloading graft operation failed. Fix by ignoring the invisible children in the PRIO graft handler. The DESTROY message of the removed Qdisc is going to follow shortly and handle the removal. Fixes: 32dc5efc6cb4 ("mlxsw: spectrum: qdiscs: prio: Handle graft command") Signed-off-by: Petr Machata Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a98672dd8f79028e19554186658d2dc9010118c5 Author: Eric Dumazet Date: Tue Jan 7 01:42:25 2020 -0800 vlan: vlan_changelink() should propagate errors [ Upstream commit eb8ef2a3c50092bb018077c047b8dba1ce0e78e3 ] Both vlan_dev_change_flags() and vlan_dev_set_egress_priority() can return an error. vlan_changelink() should not ignore them. Fixes: 07b5b17e157b ("[VLAN]: Use rtnl_link API") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4e71a156b40dd20534b28cce8c816657b7fba8a4 Author: Eric Dumazet Date: Tue Jan 7 01:42:24 2020 -0800 vlan: fix memory leak in vlan_dev_set_egress_priority [ Upstream commit 9bbd917e0bec9aebdbd0c8dbc966caec15eb33e9 ] There are few cases where the ndo_uninit() handler might be not called if an error happens while device is initialized. Since vlan_newlink() calls vlan_changelink() before trying to register the netdevice, we need to make sure vlan_dev_uninit() has been called at least once, or we might leak allocated memory. BUG: memory leak unreferenced object 0xffff888122a206c0 (size 32): comm "syz-executor511", pid 7124, jiffies 4294950399 (age 32.240s) hex dump (first 32 bytes): 00 00 00 00 00 00 61 73 00 00 00 00 00 00 00 00 ......as........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000eb3bb85>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<000000000eb3bb85>] slab_post_alloc_hook mm/slab.h:586 [inline] [<000000000eb3bb85>] slab_alloc mm/slab.c:3320 [inline] [<000000000eb3bb85>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3549 [<000000007b99f620>] kmalloc include/linux/slab.h:556 [inline] [<000000007b99f620>] vlan_dev_set_egress_priority+0xcc/0x150 net/8021q/vlan_dev.c:194 [<000000007b0cb745>] vlan_changelink+0xd6/0x140 net/8021q/vlan_netlink.c:126 [<0000000065aba83a>] vlan_newlink+0x135/0x200 net/8021q/vlan_netlink.c:181 [<00000000fb5dd7a2>] __rtnl_newlink+0x89a/0xb80 net/core/rtnetlink.c:3305 [<00000000ae4273a1>] rtnl_newlink+0x4e/0x80 net/core/rtnetlink.c:3363 [<00000000decab39f>] rtnetlink_rcv_msg+0x178/0x4b0 net/core/rtnetlink.c:5424 [<00000000accba4ee>] netlink_rcv_skb+0x61/0x170 net/netlink/af_netlink.c:2477 [<00000000319fe20f>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5442 [<00000000d51938dc>] netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] [<00000000d51938dc>] netlink_unicast+0x223/0x310 net/netlink/af_netlink.c:1328 [<00000000e539ac79>] netlink_sendmsg+0x2c0/0x570 net/netlink/af_netlink.c:1917 [<000000006250c27e>] sock_sendmsg_nosec net/socket.c:639 [inline] [<000000006250c27e>] sock_sendmsg+0x54/0x70 net/socket.c:659 [<00000000e2a156d1>] ____sys_sendmsg+0x2d0/0x300 net/socket.c:2330 [<000000008c87466e>] ___sys_sendmsg+0x8a/0xd0 net/socket.c:2384 [<00000000110e3054>] __sys_sendmsg+0x80/0xf0 net/socket.c:2417 [<00000000d71077c8>] __do_sys_sendmsg net/socket.c:2426 [inline] [<00000000d71077c8>] __se_sys_sendmsg net/socket.c:2424 [inline] [<00000000d71077c8>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2424 Fixe: 07b5b17e157b ("[VLAN]: Use rtnl_link API") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b5fdf59c20196e7002f224ccf3dc17b676fd9455 Author: Hangbin Liu Date: Thu Jan 2 17:23:45 2020 +0800 vxlan: fix tos value before xmit [ Upstream commit 71130f29979c7c7956b040673e6b9d5643003176 ] Before ip_tunnel_ecn_encap() and udp_tunnel_xmit_skb() we should filter tos value by RT_TOS() instead of using config tos directly. vxlan_get_route() would filter the tos to fl4.flowi4_tos but we didn't return it back, as geneve_get_v4_rt() did. So we have to use RT_TOS() directly in function ip_tunnel_ecn_encap(). Fixes: 206aaafcd279 ("VXLAN: Use IP Tunnels tunnel ENC encap API") Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5ea5b6e3c6e146efeae7df6b0da898868cdb4765 Author: Pengcheng Yang Date: Mon Dec 30 17:54:41 2019 +0800 tcp: fix "old stuff" D-SACK causing SACK to be treated as D-SACK [ Upstream commit c9655008e7845bcfdaac10a1ed8554ec167aea88 ] When we receive a D-SACK, where the sequence number satisfies: undo_marker <= start_seq < end_seq <= prior_snd_una we consider this is a valid D-SACK and tcp_is_sackblock_valid() returns true, then this D-SACK is discarded as "old stuff", but the variable first_sack_index is not marked as negative in tcp_sacktag_write_queue(). If this D-SACK also carries a SACK that needs to be processed (for example, the previous SACK segment was lost), this SACK will be treated as a D-SACK in the following processing of tcp_sacktag_write_queue(), which will eventually lead to incorrect updates of undo_retrans and reordering. Fixes: fd6dad616d4f ("[TCP]: Earlier SACK block verification & simplify access to them") Signed-off-by: Pengcheng Yang Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5f52b9ebd47caf11e5ee11172c1db42ae2f26fe5 Author: Xin Long Date: Sat Jan 4 14:15:02 2020 +0800 sctp: free cmd->obj.chunk for the unprocessed SCTP_CMD_REPLY [ Upstream commit be7a7729207797476b6666f046d765bdf9630407 ] This patch is to fix a memleak caused by no place to free cmd->obj.chunk for the unprocessed SCTP_CMD_REPLY. This issue occurs when failing to process a cmd while there're still SCTP_CMD_REPLY cmds on the cmd seq with an allocated chunk in cmd->obj.chunk. So fix it by freeing cmd->obj.chunk for each SCTP_CMD_REPLY cmd left on the cmd seq when any cmd returns error. While at it, also remove 'nomem' label. Reported-by: syzbot+107c4aff5f392bf1517f@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f5c8c211d811b0e0b705f66b36ad2de11e71aef0 Author: Wen Yang Date: Thu Jan 2 17:21:43 2020 +0800 sch_cake: avoid possible divide by zero in cake_enqueue() [ Upstream commit 68aab823c223646fab311f8a6581994facee66a0 ] The variables 'window_interval' is u64 and do_div() truncates it to 32 bits, which means it can test non-zero and be truncated to zero for division. The unit of window_interval is nanoseconds, so its lower 32-bit is relatively easy to exceed. Fix this issue by using div64_u64() instead. Fixes: 7298de9cd725 ("sch_cake: Add ingress mode") Signed-off-by: Wen Yang Cc: Kevin Darbyshire-Bryant Cc: Toke Høiland-Jørgensen Cc: David S. Miller Cc: Cong Wang Cc: cake@lists.bufferbloat.net Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 94ac4a4d938f51a18a51286fd94a46c1d6558103 Author: Eric Dumazet Date: Mon Jan 6 06:10:39 2020 -0800 pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM [ Upstream commit d9e15a2733067c9328fb56d98fe8e574fa19ec31 ] As diagnosed by Florian : If TCA_FQ_QUANTUM is set to 0x80000000, fq_deueue() can loop forever in : if (f->credit <= 0) { f->credit += q->quantum; goto begin; } ... because f->credit is either 0 or -2147483648. Let's limit TCA_FQ_QUANTUM to no more than 1 << 20 : This max value should limit risks of breaking user setups while fixing this bug. Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler") Signed-off-by: Eric Dumazet Diagnosed-by: Florian Westphal Reported-by: syzbot+dc9071cc5a85950bdfce@syzkaller.appspotmail.com Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 77b07bbf47e4c447bd36c97a8b597865ebff2d49 Author: Eric Dumazet Date: Tue Jan 7 10:57:01 2020 -0800 net: usb: lan78xx: fix possible skb leak [ Upstream commit 47240ba0cd09bb6fe6db9889582048324999dfa4 ] If skb_linearize() fails, we need to free the skb. TSO makes skb bigger, and this bug might be the reason Raspberry Pi 3B+ users had to disable TSO. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Eric Dumazet Reported-by: RENARD Pierre-Francois Cc: Stefan Wahren Cc: Woojung Huh Cc: Microchip Linux Driver Support Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5994f91dcdc4c85c0dc024091d0ab5b16d4088b2 Author: Chen-Yu Tsai Date: Mon Jan 6 11:09:22 2020 +0800 net: stmmac: dwmac-sunxi: Allow all RGMII modes [ Upstream commit 52cc73e5404c7ba0cbfc50cb4c265108c84b3d5a ] Allow all the RGMII modes to be used. This would allow us to represent the hardware better in the device tree with RGMII_ID where in most cases the PHY's internal delay for both RX and TX are used. Fixes: af0bd4e9ba80 ("net: stmmac: sunxi platform extensions for GMAC in Allwinner A20 SoC's") Signed-off-by: Chen-Yu Tsai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 527d7463069155959bc64555a5e261d1d037b7d6 Author: Chen-Yu Tsai Date: Mon Jan 6 11:09:45 2020 +0800 net: stmmac: dwmac-sun8i: Allow all RGMII modes [ Upstream commit f1239d8aa84dad8fe4b6cc1356f40fc8e842db47 ] Allow all the RGMII modes to be used. This would allow us to represent the hardware better in the device tree with RGMII_ID where in most cases the PHY's internal delay for both RX and TX are used. Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i") Signed-off-by: Chen-Yu Tsai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d36857e02bf8a9574362912afc865cdfb8ba1972 Author: Andrew Lunn Date: Sat Jan 4 23:14:51 2020 +0100 net: dsa: mv88e6xxx: Preserve priority when setting CPU port. [ Upstream commit d8dc2c9676e614ef62f54a155b50076888c8a29a ] The 6390 family uses an extended register to set the port connected to the CPU. The lower 5 bits indicate the port, the upper three bits are the priority of the frames as they pass through the switch, what egress queue they should use, etc. Since frames being set to the CPU are typically management frames, BPDU, IGMP, ARP, etc set the priority to 7, the reset default, and the highest. Fixes: 33641994a676 ("net: dsa: mv88e6xxx: Monitor and Management tables") Signed-off-by: Andrew Lunn Tested-by: Chris Healy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5f3274c53ae7049755b29ec0c351f145cb68270c Author: Eric Dumazet Date: Mon Jan 6 12:30:48 2020 -0800 macvlan: do not assume mac_header is set in macvlan_broadcast() [ Upstream commit 96cc4b69581db68efc9749ef32e9cf8e0160c509 ] Use of eth_hdr() in tx path is error prone. Many drivers call skb_reset_mac_header() before using it, but others do not. Commit 6d1ccff62780 ("net: reset mac header in dev_start_xmit()") attempted to fix this generically, but commit d346a3fae3ff ("packet: introduce PACKET_QDISC_BYPASS socket option") brought back the macvlan bug. Lets add a new helper, so that tx paths no longer have to call skb_reset_mac_header() only to get a pointer to skb->data. Hopefully we will be able to revert 6d1ccff62780 ("net: reset mac header in dev_start_xmit()") and save few cycles in transmit fast path. BUG: KASAN: use-after-free in __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline] BUG: KASAN: use-after-free in mc_hash drivers/net/macvlan.c:251 [inline] BUG: KASAN: use-after-free in macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277 Read of size 4 at addr ffff8880a4932401 by task syz-executor947/9579 CPU: 0 PID: 9579 Comm: syz-executor947 Not tainted 5.5.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:145 __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline] mc_hash drivers/net/macvlan.c:251 [inline] macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277 macvlan_queue_xmit drivers/net/macvlan.c:520 [inline] macvlan_start_xmit+0x402/0x77f drivers/net/macvlan.c:559 __netdev_start_xmit include/linux/netdevice.h:4447 [inline] netdev_start_xmit include/linux/netdevice.h:4461 [inline] dev_direct_xmit+0x419/0x630 net/core/dev.c:4079 packet_direct_xmit+0x1a9/0x250 net/packet/af_packet.c:240 packet_snd net/packet/af_packet.c:2966 [inline] packet_sendmsg+0x260d/0x6220 net/packet/af_packet.c:2991 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:659 __sys_sendto+0x262/0x380 net/socket.c:1985 __do_sys_sendto net/socket.c:1997 [inline] __se_sys_sendto net/socket.c:1993 [inline] __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1993 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x442639 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffc13549e08 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000442639 RDX: 000000000000000e RSI: 0000000020000080 RDI: 0000000000000003 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000403bb0 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 9389: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc mm/kasan/common.c:513 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:527 __do_kmalloc mm/slab.c:3656 [inline] __kmalloc+0x163/0x770 mm/slab.c:3665 kmalloc include/linux/slab.h:561 [inline] tomoyo_realpath_from_path+0xc5/0x660 security/tomoyo/realpath.c:252 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822 tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129 security_inode_getattr+0xf2/0x150 security/security.c:1222 vfs_getattr+0x25/0x70 fs/stat.c:115 vfs_statx_fd+0x71/0xc0 fs/stat.c:145 vfs_fstat include/linux/fs.h:3265 [inline] __do_sys_newfstat+0x9b/0x120 fs/stat.c:378 __se_sys_newfstat fs/stat.c:375 [inline] __x64_sys_newfstat+0x54/0x80 fs/stat.c:375 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 9389: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:335 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:474 kasan_slab_free+0xe/0x10 mm/kasan/common.c:483 __cache_free mm/slab.c:3426 [inline] kfree+0x10a/0x2c0 mm/slab.c:3757 tomoyo_realpath_from_path+0x1a7/0x660 security/tomoyo/realpath.c:289 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822 tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129 security_inode_getattr+0xf2/0x150 security/security.c:1222 vfs_getattr+0x25/0x70 fs/stat.c:115 vfs_statx_fd+0x71/0xc0 fs/stat.c:145 vfs_fstat include/linux/fs.h:3265 [inline] __do_sys_newfstat+0x9b/0x120 fs/stat.c:378 __se_sys_newfstat fs/stat.c:375 [inline] __x64_sys_newfstat+0x54/0x80 fs/stat.c:375 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8880a4932000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 1025 bytes inside of 4096-byte region [ffff8880a4932000, ffff8880a4933000) The buggy address belongs to the page: page:ffffea0002924c80 refcount:1 mapcount:0 mapping:ffff8880aa402000 index:0x0 compound_mapcount: 0 raw: 00fffe0000010200 ffffea0002846208 ffffea00028f3888 ffff8880aa402000 raw: 0000000000000000 ffff8880a4932000 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880a4932300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a4932380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880a4932400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880a4932480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a4932500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: b863ceb7ddce ("[NET]: Add macvlan driver") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 776a81a024e73e809af4d965ed397405062d4515 Author: Eric Dumazet Date: Mon Jan 6 06:45:37 2020 -0800 gtp: fix bad unlock balance in gtp_encap_enable_socket [ Upstream commit 90d72256addff9e5f8ad645e8f632750dd1f8935 ] WARNING: bad unlock balance detected! 5.5.0-rc5-syzkaller #0 Not tainted ------------------------------------- syz-executor921/9688 is trying to release lock (sk_lock-AF_INET6) at: [] gtp_encap_enable_socket+0x146/0x400 drivers/net/gtp.c:830 but there are no more locks to release! other info that might help us debug this: 2 locks held by syz-executor921/9688: #0: ffffffff8a4d8840 (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:72 [inline] #0: ffffffff8a4d8840 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x405/0xaf0 net/core/rtnetlink.c:5421 #1: ffff88809304b560 (slock-AF_INET6){+...}, at: spin_lock_bh include/linux/spinlock.h:343 [inline] #1: ffff88809304b560 (slock-AF_INET6){+...}, at: release_sock+0x20/0x1c0 net/core/sock.c:2951 stack backtrace: CPU: 0 PID: 9688 Comm: syz-executor921 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_unlock_imbalance_bug kernel/locking/lockdep.c:4008 [inline] print_unlock_imbalance_bug.cold+0x114/0x123 kernel/locking/lockdep.c:3984 __lock_release kernel/locking/lockdep.c:4242 [inline] lock_release+0x5f2/0x960 kernel/locking/lockdep.c:4503 sock_release_ownership include/net/sock.h:1496 [inline] release_sock+0x17c/0x1c0 net/core/sock.c:2961 gtp_encap_enable_socket+0x146/0x400 drivers/net/gtp.c:830 gtp_encap_enable drivers/net/gtp.c:852 [inline] gtp_newlink+0x9fc/0xc60 drivers/net/gtp.c:666 __rtnl_newlink+0x109e/0x1790 net/core/rtnetlink.c:3305 rtnl_newlink+0x69/0xa0 net/core/rtnetlink.c:3363 rtnetlink_rcv_msg+0x45e/0xaf0 net/core/rtnetlink.c:5424 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5442 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x58c/0x7d0 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:659 ____sys_sendmsg+0x753/0x880 net/socket.c:2330 ___sys_sendmsg+0x100/0x170 net/socket.c:2384 __sys_sendmsg+0x105/0x1d0 net/socket.c:2417 __do_sys_sendmsg net/socket.c:2426 [inline] __se_sys_sendmsg net/socket.c:2424 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2424 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x445d49 Code: e8 bc b7 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f8019074db8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000006dac38 RCX: 0000000000445d49 RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003 RBP: 00000000006dac30 R08: 0000000000000004 R09: 0000000000000000 R10: 0000000000000008 R11: 0000000000000246 R12: 00000000006dac3c R13: 00007ffea687f6bf R14: 00007f80190759c0 R15: 20c49ba5e353f7cf Fixes: e198987e7dd7 ("gtp: fix suspicious RCU usage") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 13d9f98ef4c11cef57093cd6e28b31d7c3b55fb0 Author: Logan Gunthorpe Date: Tue Sep 10 13:58:33 2019 -0600 PCI/switchtec: Read all 64 bits of part_event_bitmap commit 6acdf7e19b37cb3a9258603d0eab315079c19c5e upstream. The part_event_bitmap register is 64 bits wide, so read it with ioread64() instead of the 32-bit ioread32(). Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver") Link: https://lore.kernel.org/r/20190910195833.3891-1-logang@deltatee.com Reported-by: Doug Meyer Signed-off-by: Logan Gunthorpe Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v4.12+ Cc: Kelvin Cao Signed-off-by: Greg Kroah-Hartman commit 40b049d085f3869bb2f4dfda2ce922a9e14f7cdc Author: Anson Huang Date: Fri Sep 14 10:59:21 2018 +0800 ARM: dts: imx6ul: use nvmem-cells for cpu speed grading commit 92f0eb08c66a73594cf200e65689e767f7f0da5e upstream. On i.MX6UL, accessing OCOTP directly is wrong because the ocotp clock needs to be enabled first, so use the nvmem-cells binding instead. Signed-off-by: Anson Huang Signed-off-by: Shawn Guo Cc: Sébastien Szymanski Cc: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit 4ef576e99d29a6c58a3cc9016f052629f040f111 Author: Anson Huang Date: Mon Oct 8 14:07:34 2018 +0800 cpufreq: imx6q: read OCOTP through nvmem for imx6ul/imx6ull commit 2733fb0d0699246711cf622e0e2faf02a05b69dc upstream. On i.MX6UL/i.MX6ULL, accessing OCOTP directly is wrong because the ocotp clock needs to be enabled first. Add support for reading OCOTP through the nvmem API, and keep the old method there to support old dtb. Signed-off-by: Anson Huang Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Cc: Sébastien Szymanski Cc: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit 0b9700de712a479cf214fe503cf4d51c09b25785 Author: Jason A. Donenfeld Date: Mon Dec 23 14:31:47 2019 +0100 powerpc/spinlocks: Include correct header for static key commit 6da3eced8c5f3b03340b0c395bacd552c4d52411 upstream. Recently, the spinlock implementation grew a static key optimization, but the jump_label.h header include was left out, leading to build errors: linux/arch/powerpc/include/asm/spinlock.h:44:7: error: implicit declaration of function ‘static_branch_unlikely’ 44 | if (!static_branch_unlikely(&shared_processor)) This commit adds the missing header. mpe: The build break is only seen with CONFIG_JUMP_LABEL=n. Fixes: 656c21d6af5d ("powerpc/shared: Use static key to detect shared processor") Signed-off-by: Jason A. Donenfeld Reviewed-by: Srikar Dronamraju Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191223133147.129983-1-Jason@zx2c4.com Cc: Srikar Dronamraju Signed-off-by: Greg Kroah-Hartman commit 04a2096c4bf01960790e6469229fb0a3f479389d Author: Srikar Dronamraju Date: Thu Dec 5 14:02:17 2019 +0530 powerpc/vcpu: Assume dedicated processors as non-preempt commit 14c73bd344da60abaf7da3ea2e7733ddda35bbac upstream. With commit 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted vCPUs"), the scheduler avoids preempted vCPUs to schedule tasks on wakeup. This leads to wrong choice of CPU, which in-turn leads to larger wakeup latencies. Eventually, it leads to performance regression in latency sensitive benchmarks like soltp, schbench etc. On Powerpc, vcpu_is_preempted() only looks at yield_count. If the yield_count is odd, the vCPU is assumed to be preempted. However yield_count is increased whenever the LPAR enters CEDE state (idle). So any CPU that has entered CEDE state is assumed to be preempted. Even if vCPU of dedicated LPAR is preempted/donated, it should have right of first-use since they are supposed to own the vCPU. On a Power9 System with 32 cores: # lscpu Architecture: ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 Core(s) per socket: 1 Socket(s): 16 NUMA node(s): 2 Model: 2.2 (pvr 004e 0202) Model name: POWER9 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 512K L3 cache: 10240K NUMA node0 CPU(s): 0-63 NUMA node1 CPU(s): 64-127 # perf stat -a -r 5 ./schbench v5.4 v5.4 + patch Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 45 75.0000th: 62 75.0th: 63 90.0000th: 71 90.0th: 74 95.0000th: 77 95.0th: 78 *99.0000th: 91 *99.0th: 82 99.5000th: 707 99.5th: 83 99.9000th: 6920 99.9th: 86 min=0, max=10048 min=0, max=96 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 46 75.0000th: 61 75.0th: 64 90.0000th: 72 90.0th: 75 95.0000th: 79 95.0th: 79 *99.0000th: 691 *99.0th: 83 99.5000th: 3972 99.5th: 85 99.9000th: 8368 99.9th: 91 min=0, max=16606 min=0, max=117 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 46 75.0000th: 61 75.0th: 64 90.0000th: 71 90.0th: 75 95.0000th: 77 95.0th: 79 *99.0000th: 106 *99.0th: 83 99.5000th: 2364 99.5th: 84 99.9000th: 7480 99.9th: 90 min=0, max=10001 min=0, max=95 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 47 75.0000th: 62 75.0th: 65 90.0000th: 72 90.0th: 75 95.0000th: 78 95.0th: 79 *99.0000th: 93 *99.0th: 84 99.5000th: 108 99.5th: 85 99.9000th: 6792 99.9th: 90 min=0, max=17681 min=0, max=117 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 46 50.0th: 45 75.0000th: 62 75.0th: 64 90.0000th: 73 90.0th: 75 95.0000th: 79 95.0th: 79 *99.0000th: 113 *99.0th: 82 99.5000th: 2724 99.5th: 83 99.9000th: 6184 99.9th: 93 min=0, max=9887 min=0, max=111 Performance counter stats for 'system wide' (5 runs): context-switches 43,373 ( +- 0.40% ) 44,597 ( +- 0.55% ) cpu-migrations 1,211 ( +- 5.04% ) 220 ( +- 6.23% ) page-faults 15,983 ( +- 5.21% ) 15,360 ( +- 3.38% ) Waiman Long suggested using static_keys. Fixes: 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted vCPUs") Cc: stable@vger.kernel.org # v4.18+ Reported-by: Parth Shah Reported-by: Ihor Pasichnyk Tested-by: Juri Lelli Acked-by: Waiman Long Reviewed-by: Gautham R. Shenoy Signed-off-by: Srikar Dronamraju Acked-by: Phil Auld Reviewed-by: Vaidyanathan Srinivasan Tested-by: Parth Shah [mpe: Move the key and setting of the key to pseries/setup.c] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191213035036.6913-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 24fc85b5f5b6dec6f54a19c0295bac477125c88c Author: Haiyang Zhang Date: Thu Dec 19 18:28:10 2019 -0800 hv_netvsc: Fix unwanted rx_table reset [ Upstream commit b0689faa8efc5a3391402d7ae93bd373b7248e51 ] In existing code, the receive indirection table, rx_table, is in struct rndis_device, which will be reset when changing MTU, ringparam, etc. User configured receive indirection table values will be lost. To fix this, move rx_table to struct net_device_context, and check netif_is_rxfh_configured(), so rx_table will be set to default only if no user configured value. Fixes: ff4a44199012 ("netvsc: allow get/set of RSS indirection table") Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fc95d2b0d4ee599147e1897ed6e5168bacb0ada0 Author: Chan Shu Tak, Alex Date: Thu Dec 19 14:16:18 2019 +0800 llc2: Fix return statement of llc_stat_ev_rx_null_dsap_xid_c (and _test_c) [ Upstream commit af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285 ] When a frame with NULL DSAP is received, llc_station_rcv is called. In turn, llc_stat_ev_rx_null_dsap_xid_c is called to check if it is a NULL XID frame. The return statement of llc_stat_ev_rx_null_dsap_xid_c returns 1 when the incoming frame is not a NULL XID frame and 0 otherwise. Hence, a NULL XID response is returned unexpectedly, e.g. when the incoming frame is a NULL TEST command. To fix the error, simply remove the conditional operator. A similar error in llc_stat_ev_rx_null_dsap_test_c is also fixed. Signed-off-by: Chan Shu Tak, Alex Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4b9f0187aa07bd9386cb81e47e0387a6ff679294 Author: Helge Deller Date: Fri Dec 20 21:00:19 2019 +0100 parisc: Fix compiler warnings in debug_core.c [ Upstream commit 75cf9797006a3a9f29a3a25c1febd6842a4a9eb2 ] Fix this compiler warning: kernel/debug/debug_core.c: In function ‘kgdb_cpu_enter’: arch/parisc/include/asm/cmpxchg.h:48:3: warning: value computed is not used [-Wunused-value] 48 | ((__typeof__(*(ptr)))__xchg((unsigned long)(x), (ptr), sizeof(*(ptr)))) arch/parisc/include/asm/atomic.h:78:30: note: in expansion of macro ‘xchg’ 78 | #define atomic_xchg(v, new) (xchg(&((v)->counter), new)) | ^~~~ kernel/debug/debug_core.c:596:4: note: in expansion of macro ‘atomic_xchg’ 596 | atomic_xchg(&kgdb_active, cpu); | ^~~~~~~~~~~ Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit e80e36de03f37d06bb0a6a9cf72938434ae1aef0 Author: Yang Yingliang Date: Wed Dec 18 16:44:04 2019 +0800 block: fix memleak when __blk_rq_map_user_iov() is failed [ Upstream commit 3b7995a98ad76da5597b488fa84aa5a56d43b608 ] When I doing fuzzy test, get the memleak report: BUG: memory leak unreferenced object 0xffff88837af80000 (size 4096): comm "memleak", pid 3557, jiffies 4294817681 (age 112.499s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 20 00 00 00 10 01 00 00 00 00 00 00 01 00 00 00 ............... backtrace: [<000000001c894df8>] bio_alloc_bioset+0x393/0x590 [<000000008b139a3c>] bio_copy_user_iov+0x300/0xcd0 [<00000000a998bd8c>] blk_rq_map_user_iov+0x2f1/0x5f0 [<000000005ceb7f05>] blk_rq_map_user+0xf2/0x160 [<000000006454da92>] sg_common_write.isra.21+0x1094/0x1870 [<00000000064bb208>] sg_write.part.25+0x5d9/0x950 [<000000004fc670f6>] sg_write+0x5f/0x8c [<00000000b0d05c7b>] __vfs_write+0x7c/0x100 [<000000008e177714>] vfs_write+0x1c3/0x500 [<0000000087d23f34>] ksys_write+0xf9/0x200 [<000000002c8dbc9d>] do_syscall_64+0x9f/0x4f0 [<00000000678d8e9a>] entry_SYSCALL_64_after_hwframe+0x49/0xbe If __blk_rq_map_user_iov() is failed in blk_rq_map_user_iov(), the bio(s) which is allocated before this failing will leak. The refcount of the bio(s) is init to 1 and increased to 2 by calling bio_get(), but __blk_rq_unmap_user() only decrease it to 1, so the bio cannot be freed. Fix it by calling blk_rq_unmap_user(). Reviewed-by: Bob Liu Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 729a7f5e41f39973b3939733c8f88c56ebfca7a4 Author: Stefan Haberland Date: Thu Dec 19 09:43:51 2019 +0100 s390/dasd: fix memleak in path handling error case [ Upstream commit 00b39f698a4f1ee897227cace2e3937fc4412270 ] If for whatever reason the dasd_eckd_check_characteristics() function exits after at least some paths have their configuration data allocated those data is never freed again. In the error case the device->private pointer is set to NULL and dasd_eckd_uncheck_device() will exit without freeing the path data because of this NULL pointer. Fix by calling dasd_eckd_clear_conf_data() for error cases. Also use dasd_eckd_clear_conf_data() in dasd_eckd_uncheck_device() to avoid code duplication. Reported-by: Qian Cai Reviewed-by: Jan Hoeppner Signed-off-by: Stefan Haberland Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 000d4f2fcf2c6a6f49e50cd02cf8022e1c0caf83 Author: Jan Höppner Date: Thu Dec 19 09:43:50 2019 +0100 s390/dasd/cio: Interpret ccw_device_get_mdc return value correctly [ Upstream commit dd4b3c83b9efac10d48a94c61372119fc555a077 ] The max data count (mdc) is an unsigned 16-bit integer value as per AR documentation and is received via ccw_device_get_mdc() for a specific path mask from the CIO layer. The function itself also always returns a positive mdc value or 0 in case mdc isn't supported or couldn't be determined. Though, the comment for this function describes a negative return value to indicate failures. As a result, the DASD device driver interprets the return value of ccw_device_get_mdc() incorrectly. The error case is essentially a dead code path. To fix this behaviour, check explicitly for a return value of 0 and change the comment for ccw_device_get_mdc() accordingly. This fix merely enables the error code path in the DASD functions get_fcx_max_data() and verify_fcx_max_data(). The actual functionality stays the same and is still correct. Reviewed-by: Cornelia Huck Signed-off-by: Jan Höppner Acked-by: Peter Oberparleiter Reviewed-by: Stefan Haberland Signed-off-by: Stefan Haberland Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f2bcbc595849d5408b07f3814a86ed8950652f16 Author: Chuhong Yuan Date: Mon Nov 18 19:39:55 2019 +0800 drm/exynos: gsc: add missed component_del [ Upstream commit 84c92365b20a44c363b95390ea00dfbdd786f031 ] The driver forgets to call component_del in remove to match component_add in probe. Add the missed call to fix it. Signed-off-by: Chuhong Yuan Signed-off-by: Inki Dae Signed-off-by: Sasha Levin commit 152eaa8626cca077be5c72bd9928e6e56fd61f59 Author: Christian Borntraeger Date: Wed Dec 18 09:34:57 2019 +0100 s390/purgatory: do not build purgatory with kcov, kasan and friends [ Upstream commit c23587c92f6e3260fe3b82bb75b38aa2553b9468 ] the purgatory must not rely on functions from the "old" kernel, so we must disable kasan and friends. We also need to have a separate copy of string.c as the default does not build memcmp with KASAN. Reported-by: kbuild test robot Signed-off-by: Christian Borntraeger Reviewed-by: Vasily Gorbik Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 5ee6f0da6bbdaf21368210767434df7ba69f115b Author: Jose Abreu Date: Wed Dec 18 11:17:43 2019 +0100 net: stmmac: Always arm TX Timer at end of transmission start [ Upstream commit 4772f26db8d1fb568c4862c538344a1b5fb52081 ] If TX Coalesce timer is enabled we should always arm it, otherwise we may hit the case where an interrupt is missed and the TX Queue will timeout. Arming the timer does not necessarly mean it will run the tx_clean() because this function is wrapped around NAPI launcher. Fixes: 9125cdd1be11 ("stmmac: add the initial tx coalesce schema") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c8fa1cb103307c4acc398bee7c13430313e4fbe5 Author: Jose Abreu Date: Wed Dec 18 11:17:40 2019 +0100 net: stmmac: RX buffer size must be 16 byte aligned [ Upstream commit 8d558f0294fe92e04af192e221d0d0f6a180ee7b ] We need to align the RX buffer size to at least 16 byte so that IP doesn't mis-behave. This is required by HW. Changes from v2: - Align UP and not DOWN (David) Fixes: 7ac6653a085b ("stmmac: Move the STMicroelectronics driver") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 864a8ff571d2a409f1e73d0bf564ab4b77c174de Author: Jose Abreu Date: Wed Dec 18 11:17:39 2019 +0100 net: stmmac: xgmac: Clear previous RX buffer size [ Upstream commit 11d55fd9975f8e46a0e5e19c14899544e81e1e15 ] When switching between buffer sizes we need to clear the previous value. Fixes: d6ddfacd95c7 ("net: stmmac: Add DMA related callbacks for XGMAC2") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 57d547a41ecf932378cdb08b6c7c3d2f1d3abf35 Author: Jose Abreu Date: Wed Dec 18 11:17:37 2019 +0100 net: stmmac: Do not accept invalid MTU values [ Upstream commit eaf4fac478077d4ed57cbca2c044c4b58a96bd98 ] The maximum MTU value is determined by the maximum size of TX FIFO so that a full packet can fit in the FIFO. Add a check for this in the MTU change callback. Also check if provided and rounded MTU does not passes the maximum limit of 16K. Changes from v2: - Align MTU before checking if its valid Fixes: 7ac6653a085b ("stmmac: Move the STMicroelectronics driver") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 77de8ee6b09f5c73a92c0434e8a08b4e614fbcba Author: Eric Sandeen Date: Fri Dec 6 10:54:23 2019 -0600 fs: avoid softlockups in s_inodes iterators [ Upstream commit 04646aebd30b99f2cfa0182435a2ec252fcb16d0 ] Anything that walks all inodes on sb->s_inodes list without rescheduling risks softlockups. Previous efforts were made in 2 functions, see: c27d82f fs/drop_caches.c: avoid softlockups in drop_pagecache_sb() ac05fbb inode: don't softlockup when evicting inodes but there hasn't been an audit of all walkers, so do that now. This also consistently moves the cond_resched() calls to the bottom of each loop in cases where it already exists. One loop remains: remove_dquot_ref(), because I'm not quite sure how to deal with that one w/o taking the i_lock. Signed-off-by: Eric Sandeen Reviewed-by: Jan Kara Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 50360686bf73ad844c1970702d2a1c70e3bf4766 Author: Alexander Shishkin Date: Tue Dec 10 12:51:01 2019 +0200 perf/x86/intel: Fix PT PMI handling [ Upstream commit 92ca7da4bdc24d63bb0bcd241c11441ddb63b80a ] Commit: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it") skips the PT/LBR exclusivity check on CPUs where PT and LBRs coexist, but also inadvertently skips the active_events bump for PT in that case, which is a bug. If there aren't any hardware events at the same time as PT, the PMI handler will ignore PT PMIs, as active_events reads zero in that case, resulting in the "Uhhuh" spurious NMI warning and PT data loss. Fix this by always increasing active_events for PT events. Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it") Reported-by: Vitaly Slobodskoy Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Acked-by: Alexey Budankov Cc: Jiri Olsa Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Link: https://lkml.kernel.org/r/20191210105101.77210-1-alexander.shishkin@linux.intel.com Signed-off-by: Sasha Levin commit a64d7894b4614e6507f108f402d854868969a9c1 Author: Thomas Hebb Date: Mon Dec 9 00:19:17 2019 -0800 kconfig: don't crash on NULL expressions in expr_eq() [ Upstream commit 272a72103012862e3a24ea06635253ead0b6e808 ] NULL expressions are taken to always be true, as implemented by the expr_is_yes() macro and by several other functions in expr.c. As such, they ought to be valid inputs to expr_eq(), which compares two expressions. Signed-off-by: Thomas Hebb Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 17a6e26e54742a97782ac8d28bb3fbf52c9655a2 Author: Xiaotao Yin Date: Tue Dec 10 12:27:04 2019 +0800 iommu/iova: Init the struct iova to fix the possible memleak [ Upstream commit 472d26df5e8075eda677b6be730e0fbf434ff2a8 ] During ethernet(Marvell octeontx2) set ring buffer test: ethtool -G eth1 rx tx following kmemleak will happen sometimes: unreferenced object 0xffff000b85421340 (size 64): comm "ethtool", pid 867, jiffies 4295323539 (age 550.500s) hex dump (first 64 bytes): 80 13 42 85 0b 00 ff ff ff ff ff ff ff ff ff ff ..B............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000001b204ddf>] kmem_cache_alloc+0x1b0/0x350 [<00000000d9ef2e50>] alloc_iova+0x3c/0x168 [<00000000ea30f99d>] alloc_iova_fast+0x7c/0x2d8 [<00000000b8bb2f1f>] iommu_dma_alloc_iova.isra.0+0x12c/0x138 [<000000002f1a43b5>] __iommu_dma_map+0x8c/0xf8 [<00000000ecde7899>] iommu_dma_map_page+0x98/0xf8 [<0000000082004e59>] otx2_alloc_rbuf+0xf4/0x158 [<000000002b107f6b>] otx2_rq_aura_pool_init+0x110/0x270 [<00000000c3d563c7>] otx2_open+0x15c/0x734 [<00000000a2f5f3a8>] otx2_dev_open+0x3c/0x68 [<00000000456a98b5>] otx2_set_ringparam+0x1ac/0x1d4 [<00000000f2fbb819>] dev_ethtool+0xb84/0x2028 [<0000000069b67c5a>] dev_ioctl+0x248/0x3a0 [<00000000af38663a>] sock_ioctl+0x280/0x638 [<000000002582384c>] do_vfs_ioctl+0x8b0/0xa80 [<000000004e1a2c02>] ksys_ioctl+0x84/0xb8 The reason: When alloc_iova_mem() without initial with Zero, sometimes fpn_lo will equal to IOVA_ANCHOR by chance, so when return with -ENOMEM(iova32_full) from __alloc_and_insert_iova_range(), the new_iova will not be freed in free_iova_mem(). Fixes: bb68b2fbfbd6 ("iommu/iova: Add rbtree anchor node") Signed-off-by: Xiaotao Yin Reviewed-by: Robin Murphy Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b82c08e490c05d56e3dffac534edebcd2f0a6946 Author: Andreas Kemnade Date: Wed Dec 11 23:16:00 2019 +0100 regulator: rn5t618: fix module aliases [ Upstream commit 62a1923cc8fe095912e6213ed5de27abbf1de77e ] platform device aliases were missing, preventing autoloading of module. Fixes: 811b700630ff ("regulator: rn5t618: add driver for Ricoh RN5T618 regulators") Signed-off-by: Andreas Kemnade Link: https://lore.kernel.org/r/20191211221600.29438-1-andreas@kemnade.info Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 18932974d67b37d7b38081e7f89ac9549ec0c8d7 Author: Shengjiu Wang Date: Wed Dec 11 19:57:22 2019 +0800 ASoC: wm8962: fix lambda value [ Upstream commit 556672d75ff486e0b6786056da624131679e0576 ] According to user manual, it is required that FLL_LAMBDA > 0 in all cases (Integer and Franctional modes). Fixes: 9a76f1ff6e29 ("ASoC: Add initial WM8962 CODEC driver") Signed-off-by: Shengjiu Wang Acked-by: Charles Keepax Link: https://lore.kernel.org/r/1576065442-19763-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d8ec4cf103d6aafcabe8a63cfc53e2350c12b5f6 Author: Aditya Pakki Date: Sun Dec 15 09:34:08 2019 -0600 rfkill: Fix incorrect check to avoid NULL pointer dereference [ Upstream commit 6fc232db9e8cd50b9b83534de9cd91ace711b2d7 ] In rfkill_register, the struct rfkill pointer is first derefernced and then checked for NULL. This patch removes the BUG_ON and returns an error to the caller in case rfkill is NULL. Signed-off-by: Aditya Pakki Link: https://lore.kernel.org/r/20191215153409.21696-1-pakki001@umn.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4afc044f2010325380848839d67094e9e1950e5f Author: Sven Schnelle Date: Sun Dec 15 20:09:27 2019 +0100 parisc: add missing __init annotation [ Upstream commit aeea5eae4fd54e94d820ed17ea3b238160be723e ] compilation failed with: MODPOST vmlinux.o WARNING: vmlinux.o(.text.unlikely+0xa0c): Section mismatch in reference from the function walk_lower_bus() to the function .init.text:walk_native_bus() The function walk_lower_bus() references the function __init walk_native_bus(). This is often because walk_lower_bus lacks a __init annotation or the annotation of walk_native_bus is wrong. FATAL: modpost: Section mismatches detected. Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them. make[2]: *** [/home/svens/linux/parisc-linux/src/scripts/Makefile.modpost:64: __modpost] Error 1 make[1]: *** [/home/svens/linux/parisc-linux/src/Makefile:1077: vmlinux] Error 2 make[1]: Leaving directory '/home/svens/linux/parisc-linux/build' make: *** [Makefile:179: sub-make] Error 2 Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 588b700ce88b459180efd5f121956eda10e9e169 Author: Cristian Birsan Date: Fri Dec 13 18:33:11 2019 +0200 net: usb: lan78xx: Fix error message format specifier [ Upstream commit 858ce8ca62ea1530f2779d0e3f934b0176e663c3 ] Display the return code as decimal integer. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Cristian Birsan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 93aaacd3da743e9fcfd8294aca30fcc3c9391d44 Author: Vishal Kulkarni Date: Fri Dec 13 06:39:39 2019 +0530 cxgb4: Fix kernel panic while accessing sge_info [ Upstream commit 479a0d1376f6d97c60871442911f1394d4446a25 ] The sge_info debugfs collects offload queue info even when offload capability is disabled and leads to panic. [ 144.139871] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 144.139874] CR2: 0000000000000000 CR3: 000000082d456005 CR4: 00000000001606e0 [ 144.139876] Call Trace: [ 144.139887] sge_queue_start+0x12/0x30 [cxgb4] [ 144.139897] seq_read+0x1d4/0x3d0 [ 144.139906] full_proxy_read+0x50/0x70 [ 144.139913] vfs_read+0x89/0x140 [ 144.139916] ksys_read+0x55/0xd0 [ 144.139924] do_syscall_64+0x5b/0x1d0 [ 144.139933] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 144.139936] RIP: 0033:0x7f4b01493990 Fix this crash by skipping the offload queue access in sge_qinfo when offload capability is disabled Signed-off-by: Herat Ramani Signed-off-by: Vishal Kulkarni Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 133c0bab94376ec19f32814e490b0c8b011bb492 Author: Manish Chopra Date: Wed Dec 11 09:59:56 2019 -0800 bnx2x: Fix logic to get total no. of PFs per engine [ Upstream commit ee699f89bdbaa19c399804504241b5c531b48888 ] Driver doesn't calculate total number of PFs configured on a given engine correctly which messed up resources in the PFs loaded on that engine, leading driver to exceed configuration of resources (like vlan filters etc.) beyond the limit per engine, which ended up with asserts from the firmware. Signed-off-by: Manish Chopra Signed-off-by: Ariel Elior Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c96c9f1470b0e3f4ed03f27faa3786104e8e010 Author: Manish Chopra Date: Wed Dec 11 09:59:55 2019 -0800 bnx2x: Do not handle requests from VFs after parity [ Upstream commit 7113f796bbbced2470cd6d7379d50d7a7a78bf34 ] Parity error from the hardware will cause PF to lose the state of their VFs due to PF's internal reload and hardware reset following the parity error. Restrict any configuration request from the VFs after the parity as it could cause unexpected hardware behavior, only way for VFs to recover would be to trigger FLR on VFs and reload them. Signed-off-by: Manish Chopra Signed-off-by: Ariel Elior Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e3d5f12b312ab40d7522b1106bf85e1811c71eb5 Author: Lorenz Bauer Date: Fri Dec 13 18:08:17 2019 +0000 bpf: Clear skb->tstamp in bpf_redirect when necessary [ Upstream commit 5133498f4ad1123a5ffd4c08df6431dab882cc32 ] Redirecting a packet from ingress to egress by using bpf_redirect breaks if the egress interface has an fq qdisc installed. This is the same problem as fixed in 'commit 8203e2d844d3 ("net: clear skb->tstamp in forwarding paths") Clear skb->tstamp when redirecting into the egress path. Fixes: 80b14dee2bea ("net: Add a new socket option for a future transmit time.") Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC") Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/bpf/20191213180817.2510-1-lmb@cloudflare.com Signed-off-by: Sasha Levin commit 12ac1eb6ee76507a8360897909162e7831aaef00 Author: Nikolay Borisov Date: Mon Nov 18 14:16:44 2019 +0200 btrfs: Fix error messages in qgroup_rescan_init [ Upstream commit 37d02592f11bb76e4ab1dcaa5b8a2a0715403207 ] The branch of qgroup_rescan_init which is executed from the mount path prints wrong errors messages. The textual print out in case BTRFS_QGROUP_STATUS_FLAG_RESCAN/BTRFS_QGROUP_STATUS_FLAG_ON are not set are transposed. Fix it by exchanging their place. Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 055b4a62f11519b9f98e173ffd70323cf3ca11e7 Author: Mike Rapoport Date: Wed Dec 4 14:35:24 2019 +0200 powerpc: Ensure that swiotlb buffer is allocated from low memory [ Upstream commit 8fabc623238e68b3ac63c0dd1657bf86c1fa33af ] Some powerpc platforms (e.g. 85xx) limit DMA-able memory way below 4G. If a system has more physical memory than this limit, the swiotlb buffer is not addressable because it is allocated from memblock using top-down mode. Force memblock to bottom-up mode before calling swiotlb_init() to ensure that the swiotlb buffer is DMA-able. Reported-by: Christian Zigotzky Signed-off-by: Mike Rapoport Reviewed-by: Christoph Hellwig Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191204123524.22919-1-rppt@kernel.org Signed-off-by: Sasha Levin commit 7d5ad9fe2c9b3ad9c5473e354c12eeb2237520c2 Author: Daniel T. Lee Date: Thu Dec 5 17:01:14 2019 +0900 samples: bpf: fix syscall_tp due to unused syscall [ Upstream commit fe3300897cbfd76c6cb825776e5ac0ca50a91ca4 ] Currently, open() is called from the user program and it calls the syscall 'sys_openat', not the 'sys_open'. This leads to an error of the program of user side, due to the fact that the counter maps are zero since no function such 'sys_open' is called. This commit adds the kernel bpf program which are attached to the tracepoint 'sys_enter_openat' and 'sys_enter_openat'. Fixes: 1da236b6be963 ("bpf: add a test case for syscalls/sys_{enter|exit}_* tracepoints") Signed-off-by: Daniel T. Lee Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5663eb75ee9ad591b089e92f03029ed970e05baf Author: Daniel T. Lee Date: Thu Dec 5 17:01:13 2019 +0900 samples: bpf: Replace symbol compare of trace_event [ Upstream commit bba1b2a890253528c45aa66cf856f289a215bfbc ] Previously, when this sample is added, commit 1c47910ef8013 ("samples/bpf: add perf_event+bpf example"), a symbol 'sys_read' and 'sys_write' has been used without no prefixes. But currently there are no exact symbols with these under kallsyms and this leads to failure. This commit changes exact compare to substring compare to keep compatible with exact symbol or prefixed symbol. Fixes: 1c47910ef8013 ("samples/bpf: add perf_event+bpf example") Signed-off-by: Daniel T. Lee Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191205080114.19766-2-danieltimlee@gmail.com Signed-off-by: Sasha Levin commit 712cd9d02b8400f1752db9cc2050e402ff874e66 Author: Tomi Valkeinen Date: Thu Nov 14 11:39:48 2019 +0200 ARM: dts: am437x-gp/epos-evm: fix panel compatible [ Upstream commit c6b16761c6908d3dc167a0a566578b4b0b972905 ] The LCD panel on AM4 GP EVMs and ePOS boards seems to be osd070t1718-19ts. The current dts files say osd057T0559-34ts. Possibly the panel has changed since the early EVMs, or there has been a mistake with the panel type. Update the DT files accordingly. Acked-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 5821a1e91e0f904e0cbc0d3e3fd0752795830801 Author: Vignesh Raghavendra Date: Wed Dec 11 21:22:16 2019 +0530 spi: spi-ti-qspi: Fix a bug when accessing non default CS [ Upstream commit c52c91bb9aa6bd8c38dbf9776158e33038aedd43 ] When switching ChipSelect from default CS0 to any other CS, driver fails to update the bits in system control module register that control which CS is mapped for MMIO access. This causes reads to fail when driver tries to access QSPI flash on CS1/2/3. Fix this by updating appropriate bits whenever active CS changes. Reported-by: Andreas Dannenberg Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20191211155216.30212-1-vigneshr@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e240f26a7f1d357984ea15152f0a746fc5f815ac Author: Paul Chaignon Date: Mon Dec 9 19:52:52 2019 +0100 bpf, mips: Limit to 33 tail calls [ Upstream commit e49e6f6db04e915dccb494ae10fa14888fea6f89 ] All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in MIPS' JIT compiler to allow 33 tail calls. Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.") Reported-by: Mahshid Khezri Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/b8eb2caac1c25453c539248e56ca22f74b5316af.1575916815.git.paul.chaignon@gmail.com Signed-off-by: Sasha Levin commit 4bf973a1f84aefb64750bdb3afe72d54de3199d7 Author: Vasundhara Volam Date: Tue Dec 10 02:49:09 2019 -0500 bnxt_en: Return error if FW returns more data than dump length [ Upstream commit c74751f4c39232c31214ec6a3bc1c7e62f5c728b ] If any change happened in the configuration of VF in VM while collecting live dump, there could be a race and firmware can return more data than allocated dump length. Fix it by keeping track of the accumulated core dump length copied so far and abort the copy with error code if the next chunk of core dump will exceed the original dump length. Fixes: 6c5657d085ae ("bnxt_en: Add support for ethtool get dump.") Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d1611ab687726af7e5a13fd53c5bd8edca944653 Author: Stefan Wahren Date: Sat Nov 30 13:31:13 2019 +0100 ARM: dts: bcm283x: Fix critical trip point [ Upstream commit 30e647a764d446723a7e0fb08d209e0104f16173 ] During definition of the CPU thermal zone of BCM283x SoC family there was a misunderstanding of the meaning "criticial trip point" and the thermal throttling range of the VideoCore firmware. The latter one takes effect when the core temperature is at least 85 degree celsius or higher So the current critical trip point doesn't make sense, because the thermal shutdown appears before the firmware has a chance to throttle the ARM core(s). Fix these unwanted shutdowns by increasing the critical trip point to a value which shouldn't be reached with working thermal throttling. Fixes: 0fe4d2181cc4 ("ARM: dts: bcm283x: Add CPU thermal zone with 1 trip point") Signed-off-by: Stefan Wahren Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 459e1fba92b603936ef34bbc3f889e300627bce0 Author: Dragos Tarcatu Date: Mon Dec 9 18:39:39 2019 -0600 ASoC: topology: Check return value for soc_tplg_pcm_create() [ Upstream commit a3039aef52d9ffeb67e9211899cd3e8a2953a01f ] The return value of soc_tplg_pcm_create() is currently not checked in soc_tplg_pcm_elems_load(). If an error is to occur there, the topology ignores it and continues loading. Fix that by checking the status and rejecting the topology on error. Reviewed-by: Ranjani Sridharan Signed-off-by: Dragos Tarcatu Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191210003939.15752-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f8832728bf33e652feffac3733a5c191cf1c45d2 Author: Chuhong Yuan Date: Fri Dec 6 15:55:00 2019 +0800 spi: spi-cavium-thunderx: Add missing pci_release_regions() [ Upstream commit a841e2853e1afecc2ee692b8cc5bff606bc84e4c ] The driver forgets to call pci_release_regions() in probe failure and remove. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan Link: https://lore.kernel.org/r/20191206075500.18525-1-hslester96@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 59b1cbee0885977b441d3e974e856fd3cc423ac7 Author: Florian Fainelli Date: Fri Dec 6 10:19:09 2019 -0800 ARM: dts: Cygnus: Fix MDIO node address/size cells [ Upstream commit fac2c2da3596d77c343988bb0d41a8c533b2e73c ] The MDIO node on Cygnus had an reversed #address-cells and #size-cells properties, correct those. Fixes: 40c26d3af60a ("ARM: dts: Cygnus: Add the ethernet switch and ethernet PHY") Reported-by: Simon Horman Reviewed-by: Ray Jui Reviewed-by: Simon Horman Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit db3cb5c11ae7215d49f0a32dea65dbcb44239101 Author: Masami Hiramatsu Date: Tue Nov 26 17:34:42 2019 +0900 selftests/ftrace: Fix multiple kprobe testcase [ Upstream commit 5cc6c8d4a99d0ee4d5466498e258e593df1d3eb6 ] Fix multiple kprobe event testcase to work it correctly. There are 2 bugfixes. - Since `wc -l FILE` returns not only line number but also FILE filename, following "if" statement always failed. Fix this bug by replacing it with 'cat FILE | wc -l' - Since "while do-done loop" block with pipeline becomes a subshell, $N local variable is not update outside of the loop. Fix this bug by using actual target number (256) instead of $N. Signed-off-by: Masami Hiramatsu Reviewed-by: Steven Rostedt (VMware) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 6e168ef21fa31396e3a37f0a8a55243630926dbb Author: Florian Fainelli Date: Thu Dec 5 16:01:20 2019 -0800 ARM: dts: BCM5301X: Fix MDIO node address/size cells [ Upstream commit 093c3f94e922d83a734fc4da08cc5814990f32c6 ] The MDIO node on BCM5301X had an reversed #address-cells and #size-cells properties, correct those, silencing checker warnings: .../linux/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dt.yaml: mdio@18003000: #address-cells:0:0: 1 was expected Reported-by: Simon Horman Fixes: 23f1eca6d59b ("ARM: dts: BCM5301X: Specify MDIO bus in the DT") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 84133b6011ee7b06e30c308307cc37bef0d12c11 Author: Pablo Neira Ayuso Date: Fri Dec 6 22:09:14 2019 +0100 netfilter: nf_tables: validate NFT_DATA_VALUE after nft_data_init() [ Upstream commit 0d2c96af797ba149e559c5875c0151384ab6dd14 ] Userspace might bogusly sent NFT_DATA_VERDICT in several netlink attributes that assume NFT_DATA_VALUE. Moreover, make sure that error path invokes nft_data_release() to decrement the reference count on the chain object. Fixes: 96518518cc41 ("netfilter: add nftables") Fixes: 0f3cd9b36977 ("netfilter: nf_tables: add range expression") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit dc330d942c9f642438cd60101e7a95d529fed5a1 Author: Pablo Neira Ayuso Date: Fri Dec 6 21:55:20 2019 +0100 netfilter: nf_tables: validate NFT_SET_ELEM_INTERVAL_END [ Upstream commit bffc124b6fe37d0ae9b428d104efb426403bb5c9 ] Only NFTA_SET_ELEM_KEY and NFTA_SET_ELEM_FLAGS make sense for elements whose NFT_SET_ELEM_INTERVAL_END flag is set on. Fixes: 96518518cc41 ("netfilter: add nftables") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 80a035ebefa1f4abef2f9e421793f4b0077d6406 Author: Pablo Neira Ayuso Date: Fri Dec 6 20:23:29 2019 +0100 netfilter: nft_set_rbtree: bogus lookup/get on consecutive elements in named sets [ Upstream commit db3b665dd77b34e34df00e17d7b299c98fcfb2c5 ] The existing rbtree implementation might store consecutive elements where the closing element and the opening element might overlap, eg. [ a, a+1) [ a+1, a+2) This patch removes the optimization for non-anonymous sets in the exact matching case, where it is assumed to stop searching in case that the closing element is found. Instead, invalidate candidate interval and keep looking further in the tree. The lookup/get operation might return false, while there is an element in the rbtree. Moreover, the get operation returns true as if a+2 would be in the tree. This happens with named sets after several set updates. The existing lookup optimization (that only works for the anonymous sets) might not reach the opening [ a+1,... element if the closing ...,a+1) is found in first place when walking over the rbtree. Hence, walking the full tree in that case is needed. This patch fixes the lookup and get operations. Fixes: e701001e7cbe ("netfilter: nft_rbtree: allow adjacent intervals with dynamic updates") Fixes: ba0e4d9917b4 ("netfilter: nf_tables: get set elements via netlink") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 962debec83130003e1a156cd1475844fc248578c Author: Phil Sutter Date: Thu Dec 5 13:35:11 2019 +0100 netfilter: uapi: Avoid undefined left-shift in xt_sctp.h [ Upstream commit 164166558aacea01b99c8c8ffb710d930405ba69 ] With 'bytes(__u32)' being 32, a left-shift of 31 may happen which is undefined for the signed 32-bit value 1. Avoid this by declaring 1 as unsigned. Signed-off-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 829fde079bd99fc03bacb0c3b98cf27b43799a67 Author: Sudeep Holla Date: Wed Nov 27 15:56:40 2019 +0000 ARM: vexpress: Set-up shared OPP table instead of individual for each CPU [ Upstream commit 2a76352ad2cc6b78e58f737714879cc860903802 ] Currently we add individual copy of same OPP table for each CPU within the cluster. This is redundant and doesn't reflect the reality. We can't use core cpumask to set policy->cpus in ve_spc_cpufreq_init() anymore as it gets called via cpuhp_cpufreq_online()->cpufreq_online() ->cpufreq_driver->init() and the cpumask gets updated upon CPU hotplug operations. It also may cause issues when the vexpress_spc_cpufreq driver is built as a module. Since ve_spc_clk_init is built-in device initcall, we should be able to use the same topology_core_cpumask to set the opp sharing cpumask via dev_pm_opp_set_sharing_cpus and use the same later in the driver via dev_pm_opp_get_sharing_cpus. Cc: Liviu Dudau Cc: Lorenzo Pieralisi Acked-by: Viresh Kumar Tested-by: Dietmar Eggemann Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 05f3fbb0538014f11be6042dd658c0c19aaa24a2 Author: Stefan Roese Date: Tue Nov 5 14:04:56 2019 +0100 ARM: dts: imx6ul: imx6ul-14x14-evk.dtsi: Fix SPI NOR probing [ Upstream commit 0aeb1f2b74f3402e9cdb7c0b8e2c369c9767301e ] Without this "jedec,spi-nor" compatible property, probing of the SPI NOR does not work on the NXP i.MX6ULL EVK. Fix this by adding this compatible property to the DT. Fixes: 7d77b8505aa9 ("ARM: dts: imx6ull: fix the imx6ull-14x14-evk configuration") Signed-off-by: Stefan Roese Reviewed-by: Fabio Estevam Reviewed-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 0010192db178058cd4345cd009b893a0af2bd21d Author: Arvind Sankar Date: Fri Dec 6 16:55:40 2019 +0000 efi/gop: Fix memory leak in __gop_query32/64() [ Upstream commit ff397be685e410a59c34b21ce0c55d4daa466bb7 ] efi_graphics_output_protocol::query_mode() returns info in callee-allocated memory which must be freed by the caller, which we aren't doing. We don't actually need to call query_mode() in order to obtain the info for the current graphics mode, which is already there in gop->mode->info, so just access it directly in the setup_gop32/64() functions. Also nothing uses the size of the info structure, so don't update the passed-in size (which is the size of the gop_handle table in bytes) unnecessarily. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-5-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 737bc8f6787956f7189b5ce99b7ad0b48dfc944c Author: Arvind Sankar Date: Fri Dec 6 16:55:39 2019 +0000 efi/gop: Return EFI_SUCCESS if a usable GOP was found [ Upstream commit dbd89c303b4420f6cdb689fd398349fc83b059dd ] If we've found a usable instance of the Graphics Output Protocol (GOP) with a framebuffer, it is possible that one of the later EFI calls fails while checking if any support console output. In this case status may be an EFI error code even though we found a usable GOP. Fix this by explicitly return EFI_SUCCESS if a usable GOP has been located. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-4-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 765a2970e66f64014fc341500ee9f0e082b5d5e3 Author: Arvind Sankar Date: Fri Dec 6 16:55:38 2019 +0000 efi/gop: Return EFI_NOT_FOUND if there are no usable GOPs [ Upstream commit 6fc3cec30dfeee7d3c5db8154016aff9d65503c5 ] If we don't find a usable instance of the Graphics Output Protocol (GOP) because none of them have a framebuffer (i.e. they were all PIXEL_BLT_ONLY), but all the EFI calls succeeded, we will return EFI_SUCCESS even though we didn't find a usable GOP. Fix this by explicitly returning EFI_NOT_FOUND if no usable GOPs are found, allowing the caller to probe for UGA instead. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-3-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 0320cc64e325bf237879204c301d282c125526ac Author: Hans de Goede Date: Tue Dec 3 23:14:42 2019 +0100 ASoC: Intel: bytcr_rt5640: Update quirk for Teclast X89 [ Upstream commit 7eccc05c7101f34cc36afe9405d15de6d4099fb4 ] When the Teclast X89 quirk was added we did not have jack-detection support yet. Note the over-current detection limit is set to 2mA instead of the usual 1.5mA because this tablet tends to give false-positive button-presses when it is set to 1.5mA. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191203221442.2657-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fa03b9cab91c9c2ca4b19e3bb90d8c822191d8f1 Author: Dave Young Date: Wed Dec 4 15:52:33 2019 +0800 x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage [ Upstream commit af164898482817a1d487964b68f3c21bae7a1beb ] Michael Weiser reported that he got this error during a kexec rebooting: esrt: Unsupported ESRT version 2904149718861218184. The ESRT memory stays in EFI boot services data, and it was reserved in kernel via efi_mem_reserve(). The initial purpose of the reservation is to reuse the EFI boot services data across kexec reboot. For example the BGRT image data and some ESRT memory like Michael reported. But although the memory is reserved it is not updated in the X86 E820 table, and kexec_file_load() iterates system RAM in the IO resource list to find places for kernel, initramfs and other stuff. In Michael's case the kexec loaded initramfs overwrote the ESRT memory and then the failure happened. Since kexec_file_load() depends on the E820 table being updated, just fix this by updating the reserved EFI boot services memory as reserved type in E820. Originally any memory descriptors with EFI_MEMORY_RUNTIME attribute are bypassed in the reservation code path because they are assumed as reserved. But the reservation is still needed for multiple kexec reboots, and it is the only possible case we come here thus just drop the code chunk, then everything works without side effects. On my machine the ESRT memory sits in an EFI runtime data range, it does not trigger the problem, but I successfully tested with BGRT instead. both kexec_load() and kexec_file_load() work and kdump works as well. [ mingo: Edited the changelog. ] Reported-by: Michael Weiser Tested-by: Michael Weiser Signed-off-by: Dave Young Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Eric W. Biederman Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: kexec@lists.infradead.org Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191204075233.GA10520@dhcp-128-65.nay.redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit cb3b83a1151b4a41d8c4342b84b2ffa58009b092 Author: Sudip Mukherjee Date: Fri Nov 15 11:36:09 2019 +0000 libtraceevent: Fix lib installation with O= [ Upstream commit 587db8ebdac2c5eb3a8851e16b26f2e2711ab797 ] When we use 'O=' with make to build libtraceevent in a separate folder it fails to install libtraceevent.a and libtraceevent.so.1.1.0 with the error: INSTALL /home/sudip/linux/obj-trace/libtraceevent.a INSTALL /home/sudip/linux/obj-trace/libtraceevent.so.1.1.0 cp: cannot stat 'libtraceevent.a': No such file or directory Makefile:225: recipe for target 'install_lib' failed make: *** [install_lib] Error 1 I used the command: make O=../../../obj-trace DESTDIR=~/test prefix==/usr install It turns out libtraceevent Makefile, even though it builds in a separate folder, searches for libtraceevent.a and libtraceevent.so.1.1.0 in its source folder. So, add the 'OUTPUT' prefix to the source path so that 'make' looks for the files in the correct place. Signed-off-by: Sudipm Mukherjee Reviewed-by: Steven Rostedt (VMware) Cc: linux-trace-devel@vger.kernel.org Link: http://lore.kernel.org/lkml/20191115113610.21493-1-sudipm.mukherjee@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 21f08020dd8519baf209348c345131a8967e3cef Author: qize wang Date: Fri Nov 29 18:10:54 2019 +0800 mwifiex: Fix heap overflow in mmwifiex_process_tdls_action_frame() [ Upstream commit 1e58252e334dc3f3756f424a157d1b7484464c40 ] mwifiex_process_tdls_action_frame() without checking the incoming tdls infomation element's vality before use it, this may cause multi heap buffer overflows. Fix them by putting vality check before use it. IE is TLV struct, but ht_cap and ht_oper aren’t TLV struct. the origin marvell driver code is wrong: memcpy(&sta_ptr->tdls_cap.ht_oper, pos,.... memcpy((u8 *)&sta_ptr->tdls_cap.ht_capb, pos,... Fix the bug by changing pos(the address of IE) to pos+2 ( the address of IE value ). Signed-off-by: qize wang Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 9e0f4d24733e9a755b69dd5a6cb523fbc9e924eb Author: Florian Westphal Date: Fri Nov 15 12:39:23 2019 +0100 netfilter: ctnetlink: netns exit must wait for callbacks [ Upstream commit 18a110b022a5c02e7dc9f6109d0bd93e58ac6ebb ] Curtis Taylor and Jon Maxwell reported and debugged a crash on 3.10 based kernel. Crash occurs in ctnetlink_conntrack_events because net->nfnl socket is NULL. The nfnl socket was set to NULL by netns destruction running on another cpu. The exiting network namespace calls the relevant destructors in the following order: 1. ctnetlink_net_exit_batch This nulls out the event callback pointer in struct netns. 2. nfnetlink_net_exit_batch This nulls net->nfnl socket and frees it. 3. nf_conntrack_cleanup_net_list This removes all remaining conntrack entries. This is order is correct. The only explanation for the crash so ar is: cpu1: conntrack is dying, eviction occurs: -> nf_ct_delete() -> nf_conntrack_event_report \ -> nf_conntrack_eventmask_report -> notify->fcn() (== ctnetlink_conntrack_events). cpu1: a. fetches rcu protected pointer to obtain ctnetlink event callback. b. gets interrupted. cpu2: runs netns exit handlers: a runs ctnetlink destructor, event cb pointer set to NULL. b runs nfnetlink destructor, nfnl socket is closed and set to NULL. cpu1: c. resumes and trips over NULL net->nfnl. Problem appears to be that ctnetlink_net_exit_batch only prevents future callers of nf_conntrack_eventmask_report() from obtaining the callback. It doesn't wait of other cpus that might have already obtained the callbacks address. I don't see anything in upstream kernels that would prevent similar crash: We need to wait for all cpus to have exited the event callback. Fixes: 9592a5c01e79dbc59eb56fa ("netfilter: ctnetlink: netns support") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c7673f01604fa722b9d7c1e29e17cec1b8ae09c5 Author: Marco Elver Date: Wed Nov 20 16:57:15 2019 +0100 locking/spinlock/debug: Fix various data races [ Upstream commit 1a365e822372ba24c9da0822bc583894f6f3d821 ] This fixes various data races in spinlock_debug. By testing with KCSAN, it is observable that the console gets spammed with data races reports, suggesting these are extremely frequent. Example data race report: read to 0xffff8ab24f403c48 of 4 bytes by task 221 on cpu 2: debug_spin_lock_before kernel/locking/spinlock_debug.c:85 [inline] do_raw_spin_lock+0x9b/0x210 kernel/locking/spinlock_debug.c:112 __raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline] _raw_spin_lock+0x39/0x40 kernel/locking/spinlock.c:151 spin_lock include/linux/spinlock.h:338 [inline] get_partial_node.isra.0.part.0+0x32/0x2f0 mm/slub.c:1873 get_partial_node mm/slub.c:1870 [inline] write to 0xffff8ab24f403c48 of 4 bytes by task 167 on cpu 3: debug_spin_unlock kernel/locking/spinlock_debug.c:103 [inline] do_raw_spin_unlock+0xc9/0x1a0 kernel/locking/spinlock_debug.c:138 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:159 [inline] _raw_spin_unlock_irqrestore+0x2d/0x50 kernel/locking/spinlock.c:191 spin_unlock_irqrestore include/linux/spinlock.h:393 [inline] free_debug_processing+0x1b3/0x210 mm/slub.c:1214 __slab_free+0x292/0x400 mm/slub.c:2864 As a side-effect, with KCSAN, this eventually locks up the console, most likely due to deadlock, e.g. .. -> printk lock -> spinlock_debug -> KCSAN detects data race -> kcsan_print_report() -> printk lock -> deadlock. This fix will 1) avoid the data races, and 2) allow using lock debugging together with KCSAN. Reported-by: Qian Cai Signed-off-by: Marco Elver Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Link: https://lkml.kernel.org/r/20191120155715.28089-1-elver@google.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 5a8c4f96a5f03c062369ed1a6a0b926a41f7e1a8 Author: Tzung-Bi Shih Date: Fri Nov 22 15:31:14 2019 +0800 ASoC: max98090: fix possible race conditions [ Upstream commit 45dfbf56975994822cce00b7475732a49f8aefed ] max98090_interrupt() and max98090_pll_work() run in 2 different threads. There are 2 possible races: Note: M98090_REG_DEVICE_STATUS = 0x01. Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked. max98090_interrupt max98090_pll_work ---------------------------------------------- schedule max98090_pll_work restart max98090 codec receive ULK INT assert ULK == 0 schedule max98090_pll_work (1). In the case (1), the PLL is locked but max98090_interrupt unnecessarily schedules another max98090_pll_work. max98090_interrupt max98090_pll_work max98090 codec ---------------------------------------------------------------------- ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) schedule max98090_pll_work restart max98090 codec ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) read 0x01 assert ULK == 0 (2). In the case (2), both max98090_interrupt and max98090_pll_work read the same clear-on-read register. max98090_pll_work would falsely thought PLL is locked. Note: the case (2) race is introduced by the previous commit ("ASoC: max98090: exit workaround earlier if PLL is locked") to check the status and exit the loop earlier in max98090_pll_work. There are 2 possible solution options: A. turn off ULK interrupt before scheduling max98090_pll_work; and turn on again before exiting max98090_pll_work. B. remove the second thread of execution. Option A cannot fix the case (2) race because it still has 2 threads access the same clear-on-read register simultaneously. Although we could suppose the register is volatile and read the status via I2C could be much slower than the hardware raises the bits. Option B introduces a maximum 10~12 msec penalty delay in the interrupt handler. However, it could only punish the jack detection by extra 10~12 msec. Adopts option B which is the better solution overall. Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20191122073114.219945-4-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 551d7ff754f54316ddcbc55c556bc2e20fe476f1 Author: Wen Yang Date: Sun Nov 24 22:58:35 2019 +0800 regulator: fix use after free issue [ Upstream commit 4affd79a125ac91e6a53be843ea3960a8fc00cbb ] This is caused by dereferencing 'rdev' after put_device() in the _regulator_get()/_regulator_put() functions. This patch just moves the put_device() down a bit to avoid the issue. Signed-off-by: Wen Yang Cc: Liam Girdwood Cc: Mark Brown Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191124145835.25999-1-wenyang@linux.alibaba.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f70280ee8937f1e86bca940fb64b394efe74bb52 Author: Daniel Borkmann Date: Mon Jan 6 22:51:57 2020 +0100 bpf: Fix passing modified ctx to ld/abs/ind instruction commit 6d4f151acf9a4f6fab09b615f246c717ddedcf0c upstream. Anatoly has been fuzzing with kBdysch harness and reported a KASAN slab oob in one of the outcomes: [...] [ 77.359642] BUG: KASAN: slab-out-of-bounds in bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.360463] Read of size 4 at addr ffff8880679bac68 by task bpf/406 [ 77.361119] [ 77.361289] CPU: 2 PID: 406 Comm: bpf Not tainted 5.5.0-rc2-xfstests-00157-g2187f215eba #1 [ 77.362134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 77.362984] Call Trace: [ 77.363249] dump_stack+0x97/0xe0 [ 77.363603] print_address_description.constprop.0+0x1d/0x220 [ 77.364251] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.365030] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.365860] __kasan_report.cold+0x37/0x7b [ 77.366365] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.366940] kasan_report+0xe/0x20 [ 77.367295] bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.367821] ? bpf_skb_load_helper_8+0xf0/0xf0 [ 77.368278] ? mark_lock+0xa3/0x9b0 [ 77.368641] ? kvm_sched_clock_read+0x14/0x30 [ 77.369096] ? sched_clock+0x5/0x10 [ 77.369460] ? sched_clock_cpu+0x18/0x110 [ 77.369876] ? bpf_skb_load_helper_8+0xf0/0xf0 [ 77.370330] ___bpf_prog_run+0x16c0/0x28f0 [ 77.370755] __bpf_prog_run32+0x83/0xc0 [ 77.371153] ? __bpf_prog_run64+0xc0/0xc0 [ 77.371568] ? match_held_lock+0x1b/0x230 [ 77.371984] ? rcu_read_lock_held+0xa1/0xb0 [ 77.372416] ? rcu_is_watching+0x34/0x50 [ 77.372826] sk_filter_trim_cap+0x17c/0x4d0 [ 77.373259] ? sock_kzfree_s+0x40/0x40 [ 77.373648] ? __get_filter+0x150/0x150 [ 77.374059] ? skb_copy_datagram_from_iter+0x80/0x280 [ 77.374581] ? do_raw_spin_unlock+0xa5/0x140 [ 77.375025] unix_dgram_sendmsg+0x33a/0xa70 [ 77.375459] ? do_raw_spin_lock+0x1d0/0x1d0 [ 77.375893] ? unix_peer_get+0xa0/0xa0 [ 77.376287] ? __fget_light+0xa4/0xf0 [ 77.376670] __sys_sendto+0x265/0x280 [ 77.377056] ? __ia32_sys_getpeername+0x50/0x50 [ 77.377523] ? lock_downgrade+0x350/0x350 [ 77.377940] ? __sys_setsockopt+0x2a6/0x2c0 [ 77.378374] ? sock_read_iter+0x240/0x240 [ 77.378789] ? __sys_socketpair+0x22a/0x300 [ 77.379221] ? __ia32_sys_socket+0x50/0x50 [ 77.379649] ? mark_held_locks+0x1d/0x90 [ 77.380059] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 77.380536] __x64_sys_sendto+0x74/0x90 [ 77.380938] do_syscall_64+0x68/0x2a0 [ 77.381324] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 77.381878] RIP: 0033:0x44c070 [...] After further debugging, turns out while in case of other helper functions we disallow passing modified ctx, the special case of ld/abs/ind instruction which has similar semantics (except r6 being the ctx argument) is missing such check. Modified ctx is impossible here as bpf_skb_load_helper_8_no_cache() and others are expecting skb fields in original position, hence, add check_ctx_reg() to reject any modified ctx. Issue was first introduced back in f1174f77b50c ("bpf/verifier: rework value tracking"). Fixes: f1174f77b50c ("bpf/verifier: rework value tracking") Reported-by: Anatoly Trosinenko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200106215157.3553-1-daniel@iogearbox.net Signed-off-by: Greg Kroah-Hartman commit 11c6893b1b23d3a2b74dec5961ebcd6d50bae09e Author: Andrey Konovalov Date: Mon Oct 21 16:20:58 2019 +0200 USB: dummy-hcd: increase max number of devices to 32 commit 8442b02bf3c6770e0d7e7ea17be36c30e95987b6 upstream. When fuzzing the USB subsystem with syzkaller, we currently use 8 testing processes within one VM. To isolate testing processes from one another it is desirable to assign a dedicated USB bus to each of those, which means we need at least 8 Dummy UDC/HCD devices. This patch increases the maximum number of Dummy UDC/HCD devices to 32 (more than 8 in case we need more of them in the future). Signed-off-by: Andrey Konovalov Link: https://lore.kernel.org/r/665578f904484069bb6100fb20283b22a046ad9b.1571667489.git.andreyknvl@google.com Signed-off-by: Greg Kroah-Hartman commit 41f78c38ed9c8007d7f03493e82b159d6b9a0044 Author: Andrey Konovalov Date: Mon Oct 21 16:20:59 2019 +0200 USB: dummy-hcd: use usb_urb_dir_in instead of usb_pipein commit 6dabeb891c001c592645df2f477fed9f5d959987 upstream. Commit fea3409112a9 ("USB: add direction bit to urb->transfer_flags") has added a usb_urb_dir_in() helper function that can be used to determine the direction of the URB. With that patch USB_DIR_IN control requests with wLength == 0 are considered out requests by real USB HCDs. This patch changes dummy-hcd to use the usb_urb_dir_in() helper to match that behavior. Signed-off-by: Andrey Konovalov Link: https://lore.kernel.org/r/4ae9e68ebca02f08a93ac61fe065057c9a01f0a8.1571667489.git.andreyknvl@google.com Signed-off-by: Greg Kroah-Hartman