- 01 Jul, 2019 9 commits
-
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 307508d1 upstream. The ->digest() method of crct10dif-generic reads the current CRC value from the shash_desc context. But this value is uninitialized, causing crypto_shash_digest() to compute the wrong result. Fix it. Probably this wasn't noticed before because lib/crc-t10dif.c only uses crypto_shash_update(), not crypto_shash_digest(). Likewise, crypto_shash_digest() is not yet tested by the crypto self-tests because those only test the ahash API which only uses shash init/update/final. This bug was detected by my patches that improve testmgr to fuzz algorithms against their generic implementation. Fixes: 2d31e518 ("crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform framework") Cc: <stable@vger.kernel.org> # v3.11+ Cc: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Daniel Axtens authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit dcf7b482 upstream. The original assembly imported from OpenSSL has two copy-paste errors in handling CTR mode. When dealing with a 2 or 3 block tail, the code branches to the CBC decryption exit path, rather than to the CTR exit path. This leads to corruption of the IV, which leads to subsequent blocks being corrupted. This can be detected with libkcapi test suite, which is available at https://github.com/smuellerDD/libkcapiReported-by:
Ondrej Mosnáček <omosnacek@gmail.com> Fixes: 5c380d62 ("crypto: vmx - Add support for VMS instructions by ASM") Cc: stable@vger.kernel.org Signed-off-by:
Daniel Axtens <dja@axtens.net> Tested-by:
Michael Ellerman <mpe@ellerman.id.au> Tested-by:
-
Wen Yang authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 629266bf upstream. The call to of_get_next_child returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with warnings like: arch/arm/mach-exynos/firmware.c:201:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 193, but without a corresponding object release within this function. Cc: stable@vger.kernel.org Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Andy Lutomirski authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 9d8d0294 upstream. On x86_64, all returns to usermode go through prepare_exit_to_usermode(), with the sole exception of do_nmi(). This even includes machine checks -- this was added several years ago to support MCE recovery. Update the documentation. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@suse.de> Cc: Frederic Weisbecker <frederic@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jon Masters <jcm@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Fixes: 04dcbdb8 ("x86/speculation/mds: Clear CPU buffers on exit to user") Link: http://lkml.kernel.org/r/999fa9e126ba6a48e9d214d2f18dbde5c62ac55c.1557865329.git.luto@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Andy Lutomirski authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 88640e1d upstream. The double fault ESPFIX path doesn't return to user mode at all -- it returns back to the kernel by simulating a #GP fault. prepare_exit_to_usermode() will run on the way out of general_protection before running user code. Signed-off-by:
-
Kees Cook authored
CVE-2019-2054 Close the hole where ptrace can change a syscall out from under seccomp. Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org (cherry picked from commit 0f3912fd) Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Zhenzhong Duan authored
With commit a74cfffb ("x86/speculation: Rework SMT state change"), arch_smt_update() is invoked from each individual CPU hotplug function. Therefore the extra arch_smt_update() call in the sysfs SMT control is redundant. Fixes: a74cfffb ("x86/speculation: Rework SMT state change") Signed-off-by:
Zhenzhong Duan <zhenzhong.duan@oracle.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: <konrad.wilk@oracle.com> Cc: <dwmw@amazon.co.uk> Cc: <bp@suse.de> Cc: <srinivas.eeda@oracle.com> Cc: <peterz@infradead.org> Cc: <hpa@zytor.com> Link: https://lkml.kernel.org/r/e2e064f2-e8ef-42ca-bf4f-76b612964752@default CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 (cherry picked from commit 34d66caf) Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Acked-by:
-
Alex Murray authored
BugLink: https://bugs.launchpad.net/bugs/1834315 This reverts commit 3f8c4bc3 which was commit 379d98dd upstream. This commit, along with the commit which purports to fix it (e8a65003 aka cd01544a upstream), still cause glibc to FTBFS on eoan as noted in https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1830890/comments/7 so revert both commits. Signed-off-by:
Alex Murray <alex.murray@canonical.com> Acked-by:
-
Alex Murray authored
BugLink: https://bugs.launchpad.net/bugs/1834315 This reverts commit e8a65003 which was commit cd01544a upstream. This commit, along with the commit it purports to fix (3f8c4bc3 aka 379d98dd upstream), still cause glibc to FTBFS on eoan as noted in https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1830890/comments/7 so revert both commits. Signed-off-by:
-
- 28 Jun, 2019 6 commits
-
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1834499 We don't need to zero fill the bio if not using kernel allocated pages. Fixes: f3587d76 ("block: Clear kernel memory before copying to user") # v4.20-rc2 Reported-by:
Todd Aiken <taiken@mvtech.ca> Cc: Laurence Oberman <loberman@redhat.com> Cc: stable@vger.kernel.org Cc: Bart Van Assche <bvanassche@acm.org> Tested-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> (cherry picked from commit f55adad6) Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1834499 If the kernel allocates a bounce buffer for user read data, this memory needs to be cleared before copying it to the user, otherwise it may leak kernel memory to user space. Laurence Oberman <loberman@redhat.com> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
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 24 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:
-
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:
-
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:
-
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:
-
