- 28 Jun, 2019 4 commits
-
-
Al Viro authored
BugLink: http://bugs.launchpad.net/bugs/1834499 we want the one passed to it advanced, anyway Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> (cherry picked from commit 98a09d61) Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Dan Streetman authored
BugLink: https://bugs.launchpad.net/bugs/1824864 All other archs have this value set higher, and the low value of 14 results in a log buffer so small it fills up before systemd-journald can start and read all the boot time kernel log messages. Increasing this will result in more memory reserved for the log buffer, but will avoid missed kernel log messages. This changes all 64 bit archs to use a shift of 18, which is what amd64 has been using. Signed-off-by:
Dan Streetman <ddstreet@canonical.com> Cc: Dimitri John Ledkov <xnox@ubuntu.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> [ kleber: fixed subject line. ] Signed-off-by:
-
Sriram Rajagopalan authored
CVE-2019-11833 This commit zeroes out the unused memory region in the buffer_head corresponding to the extent metablock after writing the extent header and the corresponding extent node entries. This is done to prevent random uninitialized data from getting into the filesystem when the extent block is synced. This fixes CVE-2019-11833. Signed-off-by:
Sriram Rajagopalan <sriramr@arista.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org (cherry picked from commit 592acbf1) Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Acked-by:
Connor Kuehl <connor.kuehl@canonical.com> Acked-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1833410 Currently the calcuation of end_pfn can round up the pfn number to more than the actual maximum number of pfns, causing an Oops. Fix this by ensuring end_pfn is never more than max_pfn. This can be easily triggered when on systems where the end_pfn gets rounded up to more than max_pfn using the idle-page stress-ng stress test: sudo stress-ng --idle-page 0 [ 3812.222790] BUG: unable to handle kernel paging request at 00000000000020d8 [ 3812.224341] #PF error: [normal kernel read fault] [ 3812.225144] PGD 0 P4D 0 [ 3812.225626] Oops: 0000 [#1] SMP PTI [ 3812.226264] CPU: 1 PID: 11039 Comm: stress-ng-idle- Not tainted 5.0.0-5-generic #6-Ubuntu [ 3812.227643] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 3812.229286] RIP: 0010:page_idle_get_page+0xc8/0x1a0 [ 3812.230173] Code: 0f b1 0a 75 7d 48 8b 03 48 89 c2 48 c1 e8 33 83 e0 07 48 c1 ea 36 48 8d 0c 40 4c 8d 24 88 49 c1 e4 07 4c 03 24 d5 00 89 c3 be <49> 8b 44 24 58 48 8d b8 80 a1 02 00 e8 07 d5 77 00 48 8b 53 08 48 [ 3812.234641] RSP: 0018:ffffafd7c672fde8 EFLAGS: 00010202 [ 3812.235792] RAX: 0000000000000005 RBX: ffffe36341fff700 RCX: 000000000000000f [ 3812.237739] RDX: 0000000000000284 RSI: 0000000000000275 RDI: 0000000001fff700 [ 3812.239225] RBP: ffffafd7c672fe00 R08: ffffa0bc34056410 R09: 0000000000000276 [ 3812.241027] R10: ffffa0bc754e9b40 R11: ffffa0bc330f6400 R12: 0000000000002080 [ 3812.242555] R13: ffffe36341fff700 R14: 0000000000080000 R15: ffffa0bc330f6400 [ 3812.244073] FS: 00007f0ec1ea5740(0000) GS:ffffa0bc7db00000(0000) knlGS:0000000000000000 [ 3812.245968] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3812.247162] CR2: 00000000000020d8 CR3: 0000000077d68000 CR4: 00000000000006e0 [ 3812.249045] Call Trace: [ 3812.249625] page_idle_bitmap_write+0x8c/0x140 [ 3812.250567] sysfs_kf_bin_write+0x5c/0x70 [ 3812.251406] kernfs_fop_write+0x12e/0x1b0 [ 3812.252282] __vfs_write+0x1b/0x40 [ 3812.253002] vfs_write+0xab/0x1b0 [ 3812.253941] ksys_write+0x55/0xc0 [ 3812.254660] __x64_sys_write+0x1a/0x20 [ 3812.255446] do_syscall_64+0x5a/0x110 [ 3812.256254] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Link: http://lkml.kernel.org/r/20190618124352.28307-1-colin.king@canonical.com Fixes: 33c3fc71 ("mm: introduce idle page tracking") Signed-off-by:
Colin Ian King <colin.king@canonical.com> (cherry picked from commit d96d6145d9796d5f1eac242538d45559e9a23404 linux-next) Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Acked-by:
Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> (cherry picked from commit d96d6145d9796d5f1eac242538d45559e9a23404 linux-next) Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Andrea Righi <andrea.righi@canonical.com> Signed-off-by:
-
- 27 Jun, 2019 1 commit
-
-
Keith Busch authored
BugLink: https://bugs.launchpad.net/bugs/1833319 It is generally more efficient to submit larger IO. Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from commit ef2d4615) Signed-off-by:
Matthew Ruffell <matthew.ruffell@canonical.com> Acked-by:
-
- 25 Jun, 2019 35 commits
-
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1833698 This reverts commit 07e38998 which is commit d5bb334a upstream. Lots of people have reported issues with this patch, and as there does not seem to be a fix going into Linus's kernel tree any time soon, revert the commit in the stable trees so as to get people's machines working properly again. Reported-by:
Vasily Khoruzhick <anarsoul@gmail.com> Reported-by:
Hans de Goede <hdegoede@redhat.com> Cc: Jeremy Cline <jeremy@jcline.org> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit b528880e linux-5.1.y) Signed-off-by:
-
Stefan Bader authored
BugLink: https://bugs.launchpad.net/bugs/1824687 The backport of 05c0b86b ("ipv6: frags: rewrite ip6_expire_frag_queue()") to linux-4.4.y stable changed ip6_expire_frag_queue() to be similar to ip_expire(). However, using skb_get() leads to a crash while sending the ICMP message due to a check for shared SKBs. kernel BUG at linux-4.4.0/net/core/skbuff.c:1207! RIP: 0010:[<ffffffff81740953>] [<ffffffff81740953>] pskb_expand_head+0x243/0x250 [<ffffffff81740e50>] __pskb_pull_tail+0x50/0x350 [<ffffffff8183939a>] _decode_session6+0x26a/0x400 [<ffffffff817ec719>] __xfrm_decode_session+0x39/0x50 [<ffffffff818239d0>] icmpv6_route_lookup+0xf0/0x1c0 [<ffffffff81824421>] icmp6_send+0x5e1/0x940 [<ffffffff8183d431>] icmpv6_send+0x21/0x30 [<ffffffff8182b500>] ip6_expire_frag_queue+0xe0/0x120 For IPv4 the ip_expire() function however did change considerably since then. In fa0f5273 ("ip: use rb trees for IP frag queue.") the SKB might be taken from a rbtree (use of rbtrees for IPv4 was backported to 4.4.y upstream). Along with those obvious changes, the code also is modified to actually de-queue the SKB from whichever source it was taken. This also got rid of the skb_get() which causes problems in icmpv6_send(). And latest upstream code uses inet_frag_pull_head() which does the same. To fix the crash in IPv6, we use the same modifications added to ip_expire() by fa0f5273. This might be too much change for now because IPv6 only starts using rbtrees for frags with 997dd964 ("net: IP6 defrag: use rbtrees in nf_conntrack_reasm.c") which has not been backported to 4.4.y. Testing by a reporter was showing good results. Likely the else part never gets used until 997dd964 is backported, too. And that needs more changes. Some upstream (stable) discussion was started but has not yet resulted in any usable results. So adding this as SAUCE for now to get the kernel stable (based on testing). Fixes: bf8187348f ("ipv6: frags: rewrite ip6_expire_frag_queue()") in the linux-4.4.y stable tree. (based-on: f78a3f45e7 ("ip: use rb trees for IP frag queue." 4.4.y)) Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1826416 [Fixes upstream in a much larger set of patches that are not worth backporting to 4.9 - gregkh] When the space available before start of reading (cached_write_sz) is the same as the host required space (pending_sz), we need to still signal host. Fixes: 433e19cf ("Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()") Signed-off-by:
John Starks <jon.Starks@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1830176 Add info about the default mitigation which is part of upstream commit f21b53b2 ("x86/speculation: Make "seccomp" the default mode for Speculative Store Bypass"). Fixes: 37e59563 ("UBUNTU: SAUCE: x86/speculation: Make "seccomp" the default mode for Speculative Store Bypass") Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
-
Stefan Bader authored
BugLink: https://bugs.launchpad.net/bugs/1830176 Since commit d5c98ddc "tools include: Adopt linux/bits.h", the copy of bits.h in tools/include already defines a BIT() macro. The re-definition of it in tools/perf/bench/numa.c breaks the build if enabled. This should go into the master kernel, too but went undetected because it is not enabled anywhere else. Fixes: d5c98ddc "tools include: Adopt linux/bits.h" Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1830176 ...to be consistent with later kernels. Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1830176 The update to stable 4.4.180 added x86 Spectre v2 user mitigation, so update the documentation accordingly. From upstream commit d68be4c4 ("x86/speculation: Support 'mitigations=' cmdline option"). Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1830176 The update to stable 4.4.180 added powerpc Spectre v1 and v2 mitigations, so configure them with the 'mitigations=' cmdline option. From upstream commit 782e69ef ("powerpc/speculation: Support 'mitigations=' cmdline option"). Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1830176 ...to match upstream. No functional changes. Signed-off-by:
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1830176 The Ubuntu kernel contains runtime controls to enable/disable IBRS and IBPB which emit messages on state changes. In 4.4.180 upstream added Spectre v2 user space mitigation which also emits a message. Modify the Ubuntu-only messages to differentiate them from the regular upstream message. Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1830176Signed-off-by:
-
Christophe Leroy authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit b45ba4a5 upstream. Commit 51c3c62b ("powerpc: Avoid code patching freed init sections") accesses 'init_mem_is_free' flag too early, before the kernel is relocated. This provokes early boot failure (before the console is active). As it is not necessary to do this verification that early, this patch moves the test into patch_instruction() instead of __patch_instruction(). This modification also has the advantage of avoiding unnecessary remappings. Fixes: 51c3c62b ("powerpc: Avoid code patching freed init sections") Cc: stable@vger.kernel.org # 4.13+ Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Laurentiu Tudor authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 5266e58d upstream. Set RI in the default kernel's MSR so that the architected way of detecting unrecoverable machine check interrupts has a chance to work. This is inline with the MSR setup of the rest of booke powerpc architectures configured here. Signed-off-by:
Laurentiu Tudor <laurentiu.tudor@nxp.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 6a024330 upstream. The "param.count" value is a u64 thatcomes from the user. The code later in the function assumes that param.count is at least one and if it's not then it leads to an Oops when we dereference the ZERO_SIZE_PTR. Also the addition can have an integer overflow which would lead us to allocate a smaller "pages" array than required. I can't immediately tell what the possible run times implications are, but it's safest to prevent the overflow. Link: http://lkml.kernel.org/r/20181218082129.GE32567@kadam Fixes: 6db71994 ("drivers/virt: introduce Freescale hypervisor management driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit c8ea3663 upstream. strndup_user() returns error pointers on error, and then in the error handling we pass the error pointers to kfree(). It will cause an Oops. Link: http://lkml.kernel.org/r/20181218082003.GD32567@kadam Fixes: 6db71994 ("drivers/virt: introduce Freescale hypervisor management driver") Signed-off-by:
-
Jarod Wilson authored
BugLink: https://bugs.launchpad.net/bugs/1830176 [ Upstream commit a9b8a2b3 ] There's currently a problem with toggling arp_validate on and off with an active-backup bond. At the moment, you can start up a bond, like so: modprobe bonding mode=1 arp_interval=100 arp_validate=0 arp_ip_targets=192.168.1.1 ip link set bond0 down echo "ens4f0" > /sys/class/net/bond0/bonding/slaves echo "ens4f1" > /sys/class/net/bond0/bonding/slaves ip link set bond0 up ip addr add 192.168.1.2/24 dev bond0 Pings to 192.168.1.1 work just fine. Now turn on arp_validate: echo 1 > /sys/class/net/bond0/bonding/arp_validate Pings to 192.168.1.1 continue to work just fine. Now when you go to turn arp_validate off again, the link falls flat on it's face: echo 0 > /sys/class/net/bond0/bonding/arp_validate dmesg ... [133191.911987] bond0: Setting arp_validate to none (0) [133194.257793] bond0: bond_should_notify_peers: slave ens4f0 [133194.258031] bond0: link status definitely down for interface ens4f0, disabling it [133194.259000] bond0: making interface ens4f1 the new active one [133197.330130] bond0: link status definitely down for interface ens4f1, disabling it [133197.331191] bond0: now running without any active interface! The problem lies in bond_options.c, where passing in arp_validate=0 results in bond->recv_probe getting set to NULL. This flies directly in the face of commit 3fe68df9, which says we need to set recv_probe = bond_arp_recv, even if we're not using arp_validate. Said commit fixed this in bond_option_arp_interval_set, but missed that we can get to that same state in bond_option_arp_validate_set as well. One solution would be to universally set recv_probe = bond_arp_recv here as well, but I don't think bond_option_arp_validate_set has any business touching recv_probe at all, and that should be left to the arp_interval code, so we can just make things much tidier here. Fixes: 3fe68df9 ("bonding: always set recv_probe to bond_arp_rcv in arp monitor") CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: "David S. Miller" <davem@davemloft.net> CC: netdev@vger.kernel.org Signed-off-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Ahern authored
BugLink: https://bugs.launchpad.net/bugs/1830176 [ Upstream commit 19e4e768 ] inet_iif should be used for the raw socket lookup. inet_iif considers rt_iif which handles the case of local traffic. As it stands, ping to a local address with the '-I <dev>' option fails ever since ping was changed to use SO_BINDTODEVICE instead of cmsg + IP_PKTINFO. IPv6 works fine. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Stephen Suryaputra authored
BugLink: https://bugs.launchpad.net/bugs/1830176 [ Upstream commit ff6ab32b ] VRF netdev mtu isn't typically set and have an mtu of 65536. When the link of a tunnel is set, the tunnel mtu is changed from 1480 to the link mtu minus tunnel header. In the case of VRF netdev is the link, then the tunnel mtu becomes 65516. So, fix it by not setting the tunnel mtu in this case. Signed-off-by:
Stephen Suryaputra <ssuryaextr@gmail.com> Reviewed-by:
-
Hangbin Liu authored
BugLink: https://bugs.launchpad.net/bugs/1830176 [ Upstream commit 873017af ] With NET_ADMIN enabled in container, a normal user could be mapped to root and is able to change the real device's rx filter via ioctl on vlan, which would affect the other ptp process on host. Fix it by disabling SIOCSHWTSTAMP in container. Fixes: a6111d3c ("vlan: Pass SIOC[SG]HWTSTAMP ioctls to real device") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1830176 [ Upstream commit 36096f2f ] kernel BUG at lib/list_debug.c:47! invalid opcode: 0000 [#1 CPU: 0 PID: 12914 Comm: rmmod Tainted: G W 5.1.0+ #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:__list_del_entry_valid+0x53/0x90 Code: 48 8b 32 48 39 fe 75 35 48 8b 50 08 48 39 f2 75 40 b8 01 00 00 00 5d c3 48 89 fe 48 89 c2 48 c7 c7 18 75 fe 82 e8 cb 34 78 ff <0f> 0b 48 89 fe 48 c7 c7 50 75 fe 82 e8 ba 34 78 ff 0f 0b 48 89 f2 RSP: 0018:ffffc90001c2fe40 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffffffffa0184000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff888237a17788 RDI: 00000000ffffffff RBP: ffffc90001c2fe40 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90001c2fe10 R11: 0000000000000000 R12: 0000000000000000 R13: ffffc90001c2fe50 R14: ffffffffa0184000 R15: 0000000000000000 FS: 00007f3d83634540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555c350ea818 CR3: 0000000231677000 CR4: 00000000000006f0 Call Trace: unregister_pernet_operations+0x34/0x120 unregister_pernet_subsys+0x1c/0x30 packet_exit+0x1c/0x369 [af_packet __x64_sys_delete_module+0x156/0x260 ? lockdep_hardirqs_on+0x133/0x1b0 ? do_syscall_64+0x12/0x1f0 do_syscall_64+0x6e/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe When modprobe af_packet, register_pernet_subsys fails and does a cleanup, ops->list is set to LIST_POISON1, but the module init is considered to success, then while rmmod it, BUG() is triggered in __list_del_entry_valid which is called from unregister_pernet_subsys. This patch fix error handing path in packet_init to avoid possilbe issue if some error occur. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Christophe Leroy authored
BugLink: https://bugs.launchpad.net/bugs/1830176 [ Upstream commit ee0df193 ] When changing the number of buffers in the RX ring while the interface is running, the following Oops is encountered due to the new number of buffers being taken into account immediately while their allocation is done when opening the device only. [ 69.882706] Unable to handle kernel paging request for data at address 0xf0000100 [ 69.890172] Faulting instruction address: 0xc033e164 [ 69.895122] Oops: Kernel access of bad area, sig: 11 [#1] [ 69.900494] BE PREEMPT CMPCPRO [ 69.907120] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.115-00006-g179ade8ce3-dirty #269 [ 69.915956] task: c0684310 task.stack: c06da000 [ 69.920470] NIP: c033e164 LR: c02e44d0 CTR: c02e41fc [ 69.925504] REGS: dfff1e20 TRAP: 0300 Not tainted (4.14.115-00006-g179ade8ce3-dirty) [ 69.934161] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 22004428 XER: 20000000 [ 69.940869] DAR: f0000100 DSISR: 20000000 [ 69.940869] GPR00: c0352d70 dfff1ed0 c0684310 f00000a4 00000040 dfff1f68 00000000 0000001f [ 69.940869] GPR08: df53f410 1cc00040 00000021 c0781640 42004424 100c82b6 f00000a4 df53f5b0 [ 69.940869] GPR16: df53f6c0 c05daf84 00000040 00000000 00000040 c0782be4 00000000 00000001 [ 69.940869] GPR24: 00000000 df53f400 000001b0 df53f410 df53f000 0000003f df708220 1cc00044 [ 69.978348] NIP [c033e164] skb_put+0x0/0x5c [ 69.982528] LR [c02e44d0] ucc_geth_poll+0x2d4/0x3f8 [ 69.987384] Call Trace: [ 69.989830] [dfff1ed0] [c02e4554] ucc_geth_poll+0x358/0x3f8 (unreliable) [ 69.996522] [dfff1f20] [c0352d70] net_rx_action+0x248/0x30c [ 70.002099] [dfff1f80] [c04e93e4] __do_softirq+0xfc/0x310 [ 70.007492] [dfff1fe0] [c0021124] irq_exit+0xd0/0xd4 [ 70.012458] [dfff1ff0] [c000e7e0] call_do_irq+0x24/0x3c [ 70.017683] [c06dbe80] [c0006bac] do_IRQ+0x64/0xc4 [ 70.022474] [c06dbea0] [c001097c] ret_from_except+0x0/0x14 [ 70.027964] --- interrupt: 501 at rcu_idle_exit+0x84/0x90 [ 70.027964] LR = rcu_idle_exit+0x74/0x90 [ 70.037585] [c06dbf60] [20000000] 0x20000000 (unreliable) [ 70.042984] [c06dbf80] [c004bb0c] do_idle+0xb4/0x11c [ 70.047945] [c06dbfa0] [c004bd14] cpu_startup_entry+0x18/0x1c [ 70.053682] [c06dbfb0] [c05fb034] start_kernel+0x370/0x384 [ 70.059153] [c06dbff0] [00003438] 0x3438 [ 70.063062] Instruction dump: [ 70.066023] 38a00000 38800000 90010014 4bfff015 80010014 7c0803a6 3123ffff 7c691910 [ 70.073767] 38210010 4e800020 38600000 4e800020 <80e3005c> 80c30098 3107ffff 7d083910 [ 70.081690] ---[ end trace be7ccd9c1e1a9f12 ]--- This patch forbids the modification of the number of buffers in the ring while the interface is running. Fixes: ac421852 ("ucc_geth: add ethtool support") Signed-off-by:
-
Tobin C. Harding authored
BugLink: https://bugs.launchpad.net/bugs/1830176 [ Upstream commit bdfad5ae ] Currently error return from kobject_init_and_add() is not followed by a call to kobject_put(). This means there is a memory leak. We currently set p to NULL so that kfree() may be called on it as a noop, the code is arguably clearer if we move the kfree() up closer to where it is called (instead of after goto jump). Remove a goto label 'err1' and jump to call to kobject_put() in error return from kobject_init_and_add() fixing the memory leak. Re-name goto label 'put_back' to 'err1' now that we don't use err1, following current nomenclature (err1, err2 ...). Move call to kfree out of the error code at bottom of function up to closer to where memory was allocated. Add comment to clarify call to kfree(). Signed-off-by:
Tobin C. Harding <tobin@kernel.org> Signed-off-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1830176 [ Upstream commit 3f5edd58 ] Fix two long-standing bugs which could potentially lead to memory corruption or leave the port throttled until it is reopened (on weakly ordered systems), respectively, when read-URB completion races with unthrottle(). First, the URB must not be marked as free before processing is complete to prevent it from being submitted by unthrottle() on another CPU. CPU 1 CPU 2 ================ ================ complete() unthrottle() process_urb(); smp_mb__before_atomic(); set_bit(i, free); if (test_and_clear_bit(i, free)) submit_urb(); Second, the URB must be marked as free before checking the throttled flag to prevent unthrottle() on another CPU from failing to observe that the URB needs to be submitted if complete() sees that the throttled flag is set. CPU 1 CPU 2 ================ ================ complete() unthrottle() set_bit(i, free); throttled = 0; smp_mb__after_atomic(); smp_mb(); if (throttled) if (test_and_clear_bit(i, free)) return; submit_urb(); Note that test_and_clear_bit() only implies barriers when the test is successful. To handle the case where the URB is still in use an explicit barrier needs to be added to unthrottle() for the second race condition. Fixes: d83b4053 ("USB: serial: add support for multiple read urbs") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Oliver Neukum authored
BugLink: https://bugs.launchpad.net/bugs/1830176 [ Upstream commit 3161da97 ] This patch turns status in a variable read once from the URB. The long term plan is to deliver status to the callback. In addition it makes the code a bit more elegant. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
-
Andi Kleen authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 1de7edbb upstream. Some of the recently added const tables use __initdata which causes section attribute conflicts. Use __initconst instead. Fixes: fa1202ef ("x86/speculation: Add command line control") Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20190330004743.29541-9-andi@firstfloor.orgSigned-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 55a97402 upstream. Provide the possibility to enable IBPB always in combination with 'prctl' and 'seccomp'. Add the extra command line options and rework the IBPB selection to evaluate the command instead of the mode selected by the STIPB switch case. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Casey Schaufler <casey.schaufler@intel.com> Cc: Asit Mallick <asit.k.mallick@intel.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Jon Masters <jcm@redhat.com> Cc: Waiman Long <longman9394@gmail.com> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Dave Stewart <david.c.stewart@intel.com> Cc: Kees Cook <keescook@chromium.org> Link: https://lkml.kernel.org/r/20181125185006.144047038@linutronix.de [bwh: Backported to 4.4: adjust filename] Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 6b3e64c2 upstream. If 'prctl' mode of user space protection from spectre v2 is selected on the kernel command-line, STIBP and IBPB are applied on tasks which restrict their indirect branch speculation via prctl. SECCOMP enables the SSBD mitigation for sandboxed tasks already, so it makes sense to prevent spectre v2 user space to user space attacks as well. The Intel mitigation guide documents how STIPB works: Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor prevents the predicted targets of indirect branches on any logical processor of that core from being controlled by software that executes (or executed previously) on another logical processor of the same core. Ergo setting STIBP protects the task itself from being attacked from a task running on a different hyper-thread and protects the tasks running on different hyper-threads from being attacked. While the document suggests that the branch predictors are shielded between the logical processors, the observed performance regressions suggest that STIBP simply disables the branch predictor more or less completely. Of course the document wording is vague, but the fact that there is also no requirement for issuing IBPB when STIBP is used points clearly in that direction. The kernel still issues IBPB even when STIBP is used until Intel clarifies the whole mechanism. IBPB is issued when the task switches out, so malicious sandbox code cannot mistrain the branch predictor for the next user space task on the same logical processor. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 7cc765a6 upstream. Now that all prerequisites are in place: - Add the prctl command line option - Default the 'auto' mode to 'prctl' - When SMT state changes, update the static key which controls the conditional STIBP evaluation on context switch. - At init update the static key which controls the conditional IBPB evaluation on context switch. Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 9137bb27 upstream. Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of indirect branch speculation via STIBP and IBPB. Invocations: Check indirect branch speculation status with - prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0); Enable indirect branch speculation with - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0, 0); Disable indirect branch speculation with - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0, 0); Force disable indirect branch speculation with - prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0); See Documentation/userspace-api/spec_ctrl.rst. Signed-off-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 6d991ba5 upstream. The seccomp speculation control operates on all tasks of a process, but only the current task of a process can update the MSR immediately. For the other threads the update is deferred to the next context switch. This creates the following situation with Process A and B: Process A task 2 and Process B task 1 are pinned on CPU1. Process A task 2 does not have the speculation control TIF bit set. Process B task 1 has the speculation control TIF bit set. CPU0 CPU1 MSR bit is set ProcB.T1 schedules out ProcA.T2 schedules in MSR bit is cleared ProcA.T1 seccomp_update() set TIF bit on ProcA.T2 ProcB.T1 schedules in MSR is not updated <-- FAIL This happens because the context switch code tries to avoid the MSR update if the speculation control TIF bits of the incoming and the outgoing task are the same. In the worst case ProcB.T1 and ProcA.T2 are the only tasks scheduling back and forth on CPU1, which keeps the MSR stale forever. In theory this could be remedied by IPIs, but chasing the remote task which could be migrated is complex and full of races. The straight forward solution is to avoid the asychronous update of the TIF bit and defer it to the next context switch. The speculation control state is stored in task_struct::atomic_flags by the prctl and seccomp updates already. Add a new TIF_SPEC_FORCE_UPDATE bit and set this after updating the atomic_flags. Check the bit on context switch and force a synchronous update of the speculation control if set. Use the same mechanism for updating the current task. Reported-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 6893a959 upstream. The upcoming fine grained per task STIBP control needs to be updated on CPU hotplug as well. Split out the code which controls the strict mode so the prctl control code can be added later. Mark the SMP function call argument __unused while at it. Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit e6da8bb6 upstream. The update of the TIF_SSBD flag and the conditional speculation control MSR update is done in the ssb_prctl_set() function directly. The upcoming prctl support for controlling indirect branch speculation via STIBP needs the same mechanism. Split the code out and make it reusable. Reword the comment about updates for other tasks. Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 4c71a2b6 upstream. The IBPB speculation barrier is issued from switch_mm() when the kernel switches to a user space task with a different mm than the user space task which ran last on the same CPU. An additional optimization is to avoid IBPB when the incoming task can be ptraced by the outgoing task. This optimization only works when switching directly between two user space tasks. When switching from a kernel task to a user space task the optimization fails because the previous task cannot be accessed anymore. So for quite some scenarios the optimization is just adding overhead. The upcoming conditional IBPB support will issue IBPB only for user space tasks which have the TIF_SPEC_IB bit set. This requires to handle the following cases: 1) Switch from a user space task (potential attacker) which has TIF_SPEC_IB set to a user space task (potential victim) which has TIF_SPEC_IB not set. 2) Switch from a user space task (potential attacker) which has TIF_SPEC_IB not set to a user space task (potential victim) which has TIF_SPEC_IB set. This needs to be optimized for the case where the IBPB can be avoided when only kernel threads ran in between user space tasks which belong to the same process. The current check whether two tasks belong to the same context is using the tasks context id. While correct, it's simpler to use the mm pointer because it allows to mangle the TIF_SPEC_IB bit into it. The context id based mechanism requires extra storage, which creates worse code. When a task is scheduled out its TIF_SPEC_IB bit is mangled as bit 0 into the per CPU storage which is used to track the last user space mm which was running on a CPU. This bit can be used together with the TIF_SPEC_IB bit of the incoming task to make the decision whether IBPB needs to be issued or not to cover the two cases above. As conditional IBPB is going to be the default, remove the dubious ptrace check for the IBPB always case and simply issue IBPB always when the process changes. Move the storage to a different place in the struct as the original one created a hole. Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit 5635d999 upstream. The TIF_SPEC_IB bit does not need to be evaluated in the decision to invoke __switch_to_xtra() when: - CONFIG_SMP is disabled - The conditional STIPB mode is disabled The TIF_SPEC_IB bit still controls IBPB in both cases so the TIF work mask checks might invoke __switch_to_xtra() for nothing if TIF_SPEC_IB is the only set bit in the work masks. Optimize it out by masking the bit at compile time for CONFIG_SMP=n and at run time when the static key controlling the conditional STIBP mode is disabled. Signed-off-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1830176 commit ff16701a upstream. Move the conditional invocation of __switch_to_xtra() into an inline function so the logic can be shared between 32 and 64 bit. Remove the handthrough of the TSS pointer and retrieve the pointer directly in the bitmap handling function. Use this_cpu_ptr() instead of the per_cpu() indirection. This is a preparatory change so integration of conditional indirect branch speculation optimization happens only in one place. Signed-off-by:
-
