- 01 Jul, 2019 13 commits
-
-
Kailang Yang authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 607ca3bd upstream. Let EAPD turn on after set pin output. [ NOTE: This change is supposed to reduce the possible click noises at (runtime) PM resume. The functionality should be same (i.e. the verbs are executed correctly) no matter which order is, so this should be safe to apply for all codecs -- tiwai ] Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> 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>
-
Hui Wang authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit 7f641e26 upstream. On the machines with AMD GPU or Nvidia GPU, we often meet this issue: after s3, there are 4 HDMI/DP audio devices in the gnome-sound-setting even there is no any monitors plugged. When this problem happens, we check the /proc/asound/cardX/eld#N.M, we will find the monitor_present=1, eld_valid=0. The root cause is BIOS or GPU driver makes the PRESENCE valid even no monitor plugged, and of course the driver will not get the valid eld_data subsequently. In this situation, we should not report the jack_plugged event, to do so, let us change the function hdmi_present_sense_via_verbs(). In this function, it reads the pin_sense via snd_hda_pin_sense(), after calling this function, the jack_dirty is 0, and before exiting via_verbs(), we change the shadow pin_sense according to both monitor_present and eld_valid, then in the snd_hda_jack_report_sync(), since the jack_dirty is still 0, it will report jack event according to this modified shadow pin_sense. After this change, the driver will not report Jack_is_plugged event through hdmi_present_sense_via_verbs() if monitor_present is 1 and eld_valid is 0. Signed-off-by:
Hui Wang <hui.wang@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Wenwen Wang authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit cb517359 upstream. In parse_audio_selector_unit(), the string array 'namelist' is allocated through kmalloc_array(), and each string pointer in this array, i.e., 'namelist[]', is allocated through kmalloc() in the following for loop. Then, a control instance 'kctl' is created by invoking snd_ctl_new1(). If an error occurs during the creation process, the string array 'namelist', including all string pointers in the array 'namelist[]', should be freed, before the error code ENOMEM is returned. However, the current code does not free 'namelist[]', resulting in memory leaks. To fix the above issue, free all string pointers 'namelist[]' in a loop. Signed-off-by:
Wenwen Wang <wang6495@umn.edu> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1832661 commit dec3d0b1 upstream. The ->digest() method of crct10dif-pclmul 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. Fixes: 0b95a7f8 ("crypto: crct10dif - Glue code to cast accelerated CRCT10DIF assembly as a crypto transform") 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:
-
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:
-
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 20 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:
-
