- 15 Sep, 2021 40 commits
-
-
Sean Christopherson authored
commit f7782bb8 upstream. Clear nested.pi_pending on nested VM-Enter even if L2 will run without posted interrupts enabled. If nested.pi_pending is left set from a previous L2, vmx_complete_nested_posted_interrupt() will pick up the stale flag and exit to userspace with an "internal emulation error" due the new L2 not having a valid nested.pi_desc. Arguably, vmx_complete_nested_posted_interrupt() should first check for posted interrupts being enabled, but it's also completely reasonable that KVM wouldn't screw up a fundamental flag. Not to mention that the mere existence of nested.pi_pending is a long-standing bug as KVM shouldn't move the posted interrupt out of the IRR until it's actually processed, e.g. KVM effectively drops an interrupt when it performs a nested VM-Exit with a "pending" posted interrupt. Fixing the mess is a future problem. Prior to vmx_complete_nested_posted_interrupt() interpreting a null PI descriptor as an error, this was a benign bug as the null PI descriptor effectively served as a check on PI not being enabled. Even then, the new flow did not become problematic until KVM started checking the result of kvm_check_nested_events(). Fixes: 705699a1 ("KVM: nVMX: Enable nested posted interrupt processing") Fixes: 966eefb8 ("KVM: nVMX: Disable vmcs02 posted interrupts if vmcs12 PID isn't mappable") Fixes: 47d3530f86c0 ("KVM: x86: Exit to userspace when kvm_check_nested_events fails") Cc: stable@vger.kernel.org Cc: Jim Mattson <jmattson@google.com> Signed-off-by:
Sean Christopherson <seanjc@google.com> Message-Id: <20210810144526.2662272-1-seanjc@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Maxim Levitsky authored
commit 81b4b56d upstream. If we are emulating an invalid guest state, we don't have a correct exit reason, and thus we shouldn't do anything in this function. Signed-off-by:
Maxim Levitsky <mlevitsk@redhat.com> Message-Id: <20210826095750.1650467-2-mlevitsk@redhat.com> Cc: stable@vger.kernel.org Fixes: 95b5a48c ("KVM: VMX: Handle NMIs, #MCs and async #PFs in common irqs-disabled fn", 2019-06-18) Signed-off-by:
-
Zelin Deng authored
commit d9130a2d upstream. When MSR_IA32_TSC_ADJUST is written by guest due to TSC ADJUST feature especially there's a big tsc warp (like a new vCPU is hot-added into VM which has been up for a long time), tsc_offset is added by a large value then go back to guest. This causes system time jump as tsc_timestamp is not adjusted in the meantime and pvclock monotonic character. To fix this, just notify kvm to update vCPU's guest time before back to guest. Cc: stable@vger.kernel.org Signed-off-by:
Zelin Deng <zelin.deng@linux.alibaba.com> Signed-off-by:
-
Halil Pasic authored
commit a3e03bc1 upstream. While in practice vcpu->vcpu_idx == vcpu->vcp_id is often true, it may not always be, and we must not rely on this. Reason is that KVM decides the vcpu_idx, userspace decides the vcpu_id, thus the two might not match. Currently kvm->arch.idle_mask is indexed by vcpu_id, which implies that code like for_each_set_bit(vcpu_id, kvm->arch.idle_mask, online_vcpus) { vcpu = kvm_get_vcpu(kvm, vcpu_id); do_stuff(vcpu); } is not legit. Reason is that kvm_get_vcpu expects an vcpu_idx, not an vcpu_id. The trouble is, we do actually use kvm->arch.idle_mask like this. To fix this problem we have two options. Either use kvm_get_vcpu_by_id(vcpu_id), which would loop to find the right vcpu_id, or switch to indexing via vcpu_idx. The latter is preferable for obvious reasons. Let us make switch from indexing kvm->arch.idle_mask by vcpu_id to indexing it by vcpu_idx. To keep gisa_int.kicked_mask indexed by the same index as idle_mask lets make the same change for it as well. Fixes: 1ee0bc55 ("KVM: s390: get rid of local_int array") Signed-off-by:
Halil Pasic <pasic@linux.ibm.com> Reviewed-by:
Christian Bornträger <borntraeger@de.ibm.com> Reviewed-by:
Claudio Imbrenda <imbrenda@linux.ibm.com> Cc: <stable@vger.kernel.org> # 3.15+ Link: https://lore.kernel.org/r/20210827125429.1912577-1-pasic@linux.ibm.com Signed-off-by:
-
Sean Christopherson authored
commit e7177339 upstream. Revert a misguided illegal GPA check when "translating" a non-nested GPA. The check is woefully incomplete as it does not fill in @exception as expected by all callers, which leads to KVM attempting to inject a bogus exception, potentially exposing kernel stack information in the process. WARNING: CPU: 0 PID: 8469 at arch/x86/kvm/x86.c:525 exception_type+0x98/0xb0 arch/x86/kvm/x86.c:525 CPU: 1 PID: 8469 Comm: syz-executor531 Not tainted 5.14.0-rc7-syzkaller #0 RIP: 0010:exception_type+0x98/0xb0 arch/x86/kvm/x86.c:525 Call Trace: x86_emulate_instruction+0xef6/0x1460 arch/x86/kvm/x86.c:7853 kvm_mmu_page_fault+0x2f0/0x1810 arch/x86/kvm/mmu/mmu.c:5199 handle_ept_misconfig+0xdf/0x3e0 arch/x86/kvm/vmx/vmx.c:5336 __vmx_handle_exit arch/x86/kvm/vmx/vmx.c:6021 [inline] vmx_handle_exit+0x336/0x1800 arch/x86/kvm/vmx/vmx.c:6038 vcpu_enter_guest+0x2a1c/0x4430 arch/x86/kvm/x86.c:9712 vcpu_run arch/x86/kvm/x86.c:9779 [inline] kvm_arch_vcpu_ioctl_run+0x47d/0x1b20 arch/x86/kvm/x86.c:10010 kvm_vcpu_ioctl+0x49e/0xe50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3652 The bug has escaped notice because practically speaking the GPA check is useless. The GPA check in question only comes into play when KVM is walking guest page tables (or "translating" CR3), and KVM already handles illegal GPA checks by setting reserved bits in rsvd_bits_mask for each PxE, or in the case of CR3 for loading PTDPTRs, manually checks for an illegal CR3. This particular failure doesn't hit the existing reserved bits checks because syzbot sets guest.MAXPHYADDR=1, and IA32 architecture simply doesn't allow for such an absurd MAXPHYADDR, e.g. 32-bit paging doesn't define any reserved PA bits checks, which KVM emulates by only incorporating the reserved PA bits into the "high" bits, i.e. bits 63:32. Simply remove the bogus check. There is zero meaningful value and no architectural justification for supporting guest.MAXPHYADDR < 32, and properly filling the exception would introduce non-trivial complexity. This reverts commit ec7771ab. Fixes: ec7771ab ("KVM: x86: mmu: Add guest physical address check in translate_gpa()") Cc: stable@vger.kernel.org Reported-by: syzbot+200c08e88ae818f849ce@syzkaller.appspotmail.com Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Babu Moger authored
commit 527f7214 upstream. The recent commit 064855a6 ("x86/resctrl: Fix default monitoring groups reporting") caused a RHEL build failure with an uninitialized variable warning treated as an error because it removed the default case snippet. The RHEL Makefile uses '-Werror=maybe-uninitialized' to force possibly uninitialized variable warnings to be treated as errors. This is also reported by smatch via the 0day robot. The error from the RHEL build is: arch/x86/kernel/cpu/resctrl/monitor.c: In function ‘__mon_event_count’: arch/x86/kernel/cpu/resctrl/monitor.c:261:12: error: ‘m’ may be used uninitialized in this function [-Werror=maybe-uninitialized] m->chunks += chunks; ^~ The upstream Makefile does not build using '-Werror=maybe-uninitialized'. So, the problem is not seen there. Fix the problem by putting back the default case snippet. [ bp: note that there's nothing wrong with the code and other compilers do not trigger this warning - this is being done just so the RHEL compiler is happy. ] Fixes: 064855a6 ("x86/resctrl: Fix default monitoring groups reporting") Reported-by:
Terry Bowman <Terry.Bowman@amd.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Babu Moger <babu.moger@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Reinette Chatre <reinette.chatre@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/162949631908.23903.17090272726012848523.stgit@bmoger-ubuntu Signed-off-by:
-
Kim Phillips authored
commit f11dd0d8 upstream. Commit: 2ff40250 ("perf/core, arch/x86: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable PMUs") neglected to do so. Fixes: 2ff40250 ("perf/core, arch/x86: Use PERF_PMU_CAP_NO_EXCLUDE for exclusion incapable PMUs") Signed-off-by:
Kim Phillips <kim.phillips@amd.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210817221048.88063-2-kim.phillips@amd.com Signed-off-by:
-
Nguyen Dinh Phi authored
commit bb2853a6 upstream. The ops->receive_buf() may be accessed concurrently from these two functions. If the driver flushes data to the line discipline receive_buf() method while tiocsti() is waiting for the ops->receive_buf() to finish its work, the data race will happen. For example: tty_ioctl |tty_ldisc_receive_buf ->tioctsi | ->tty_port_default_receive_buf | ->tty_ldisc_receive_buf ->hci_uart_tty_receive | ->hci_uart_tty_receive ->h4_recv | ->h4_recv In this case, the h4 receive buffer will be overwritten by the latecomer, and we will lost the data. Hence, change tioctsi() function to use the exclusive lock interface from tty_buffer to avoid the data race. Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
Nguyen Dinh Phi <phind.uet@gmail.com> Link: https://lore.kernel.org/r/20210823000641.2082292-1-phind.uet@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Pavel Begunkov authored
commit d9cf3bd5 upstream. __bio_iov_append_get_pages() doesn't put not appended pages on bio_add_hw_page() failure, so potentially leaking them, fix it. Also, do the same for __bio_iov_iter_get_pages(), even though it looks like it can't be triggered by userspace in this case. Fixes: 0512a75b ("block: Introduce REQ_OP_ZONE_APPEND") Cc: stable@vger.kernel.org # 5.8+ Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/1edfa6a2ffd66d55e6345a477df5387d2c1415d0.1626653825.git.asml.silence@gmail.com Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Jens Axboe authored
commit 7b3188e7 upstream. During some testing, it became evident that using IORING_OP_WRITE doesn't hash buffered writes like the other writes commands do. That's simply an oversight, and can cause performance regressions when doing buffered writes with this command. Correct that and add the flag, so that buffered writes are correctly hashed when using the non-iovec based write command. Cc: stable@vger.kernel.org Fixes: 3a6820f2 ("io_uring: add non-vectored read/write commands") Signed-off-by:
-
Lukas Hannen authored
commit 39ff83f2 upstream. timespec64_ns() prevents multiplication overflows by comparing the seconds value of the timespec to KTIME_SEC_MAX. If the value is greater or equal it returns KTIME_MAX. But that check casts the signed seconds value to unsigned which makes the comparision true for all negative values and therefore return wrongly KTIME_MAX. Negative second values are perfectly valid and required in some places, e.g. ptp_clock_adjtime(). Remove the cast and add a check for the negative boundary which is required to prevent undefined behaviour due to multiplication underflow. Fixes: cb477557 ("time: Prevent undefined behaviour in timespec64_to_ns()")' Signed-off-by:
Lukas Hannen <lukas.hannen@opensource.tttech-industrial.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/AM6PR01MB541637BD6F336B8FFB72AF80EEC69@AM6PR01MB5416.eurprd01.prod.exchangelabs.com Signed-off-by:
-
Jaegeuk Kim authored
commit dddd3d65 upstream. We must flush all the dirty data when enabling checkpoint back. Let's guarantee that first by adding a retry logic on sync_inodes_sb(). In addition to that, this patch adds to flush data in fsync when checkpoint is disabled, which can mitigate the sync_inodes_sb() failures in advance. Reviewed-by:
Chao Yu <chao@kernel.org> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Justin M. Forbes authored
commit 2f32c147 upstream. The Samsung Galaxy Book Flex2 Alpha uses an ax201 with the ID a0f0/6074. This works fine with the existing driver once it knows to claim it. Simple patch to add the device. Signed-off-by:
Justin M. Forbes <jforbes@fedoraproject.org> Reviewed-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210702223155.1981510-1-jforbes@fedoraproject.org Signed-off-by:
-
Douglas Anderson authored
commit a1ea0572 upstream. In commit 772d4452 ("ASoC: rt5682: Properly turn off regulators if wrong device ID") I deleted code but forgot to delete a variable that's now unused. Delete it. Fixes: 772d4452 ("ASoC: rt5682: Properly turn off regulators if wrong device ID") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210813073402.1.Iaa9425cfab80f5233afa78b32d02b6dc23256eb3@changeid Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 92548b0e ] The UDP length field should be in network order. This removes the following sparse error: net/ipv4/route.c:3173:27: warning: incorrect type in assignment (different base types) net/ipv4/route.c:3173:27: expected restricted __be16 [usertype] len net/ipv4/route.c:3173:27: got unsigned long Fixes: 404eb77e ("ipv4: support sport, dport and ip_proto in RTM_GETROUTE") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Roopa Prabhu <roopa@nvidia.com> Cc: David Ahern <dsahern@kernel.org> Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Sunil Goutham authored
[ Upstream commit 1e4428b6 ] With current config, for packets with IPv4 checksum errors, errorcode is being set to UNKNOWN. Hence added a separate errorcodes for outer and inner IPv4 checksum and changed NPC configuration accordingly. Also turn on L2 multicast address check in NPC protocol check block. Fixes: 6b3321ba ("octeontx2-af: Enable packet length and csum validation") Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
-
Subbaraya Sundeep authored
[ Upstream commit 698a82eb ] This patch fixes the static code analyzer reported issues in rvu_npc.c. The reported errors are different sizes of operands in bitops and returning uninitialized values. Fixes: 651cd265 ("octeontx2-af: MCAM entry installation support") Signed-off-by:
-
Subbaraya Sundeep authored
[ Upstream commit 6537e96d ] When the given counter does not belong to the entry then code ends up in infinite loop because the loop cursor, entry is not getting updated further. This patch fixes that by updating entry for every iteration. Fixes: a958dd59 ("octeontx2-af: Map or unmap NPC MCAM entry and counter") Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit 429205da ] Based on tests the QCA7000 doesn't support checksum offloading. So assume ip_summed is CHECKSUM_NONE and let the kernel take care of the checksum handling. This fixes data transfer issues in noisy environments. Reported-by:
Michael Heimpold <michael.heimpold@in-tech.com> Fixes: 291ab06e ("net: qualcomm: new Ethernet over SPI driver for QCA7000") Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Xiyu Yang authored
[ Upstream commit c6607012 ] The reference counting issue happens in one exception handling path of cbq_change_class(). When failing to get tcf_block, the function forgets to decrease the refcount of "rtab" increased by qdisc_put_rtab(), causing a refcount leak. Fix this issue by jumping to "failure" label when get tcf_block failed. Fixes: 6529eaba ("net: sched: introduce tcf block infractructure") Signed-off-by:
Xiyu Yang <xiyuyang19@fudan.edu.cn> Reviewed-by:
Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/1630252681-71588-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 67d6d681 ] Even after commit 6457378f ("ipv4: use siphash instead of Jenkins in fnhe_hashfun()"), an attacker can still use brute force to learn some secrets from a victim linux host. One way to defeat these attacks is to make the max depth of the hash table bucket a random value. Before this patch, each bucket of the hash table used to store exceptions could contain 6 items under attack. After the patch, each bucket would contains a random number of items, between 6 and 10. The attacker can no longer infer secrets. This is slightly increasing memory size used by the hash table, by 50% in average, we do not expect this to be a problem. This patch is more complex than the prior one (IPv6 equivalent), because IPv4 was reusing the oldest entry. Since we need to be able to evict more than one entry per update_or_create_fnhe() call, I had to replace fnhe_oldest() with fnhe_remove_oldest(). Also note that we will queue extra kfree_rcu() calls under stress, which hopefully wont be a too big issue. Fixes: 4895c771 ("ipv4: Add FIB nexthop exceptions.") Signed-off-by:
Keyu Man <kman001@ucr.edu> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit a00df2ca ] Even after commit 4785305c ("ipv6: use siphash in rt6_exception_hash()"), an attacker can still use brute force to learn some secrets from a victim linux host. One way to defeat these attacks is to make the max depth of the hash table bucket a random value. Before this patch, each bucket of the hash table used to store exceptions could contain 6 items under attack. After the patch, each bucket would contains a random number of items, between 6 and 10. The attacker can no longer infer secrets. This is slightly increasing memory size used by the hash table, we do not expect this to be a problem. Following patch is dealing with the same issue in IPv4. Fixes: 35732d01 ("ipv6: introduce a hash table to store dst cache") Signed-off-by:
-
Ahmad Fatoum authored
[ Upstream commit d745ca4f ] When resuming from suspend, brcmf_pcie_pm_leave_D3 will first attempt a hot resume and then fall back to removing the PCI device and then reprobing. If this probe fails, the kernel will oops, because brcmf_err, which is called to report the failure will dereference the stale bus pointer. Open code and use the default bus-less brcmf_err to avoid this. Fixes: 8602e624 ("brcmfmac: pass bus to the __brcmf_err() in pcie.c") Signed-off-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
-
Zenghui Yu authored
[ Upstream commit b63aed3f ] kmemleak reported that dev_name() of internally-handled cores were leaked on driver unbinding. Let's use device_initialize() to take refcounts for them and put_device() to properly free the related stuff. While looking at it, there's another potential issue for those which should be *registered* into driver core. If device_register() failed, we put device once and freed bcma_device structures. In bcma_unregister_cores(), they're treated as unregistered and we hit both UAF and double-free. That smells not good and has also been fixed now. Fixes: ab54bc84 ("bcma: fill core details for every device") Signed-off-by:
Zenghui Yu <yuzenghui@huawei.com> Signed-off-by:
-
Sudarsana Reddy Kalluru authored
[ Upstream commit 57f780f1 ] Driver crashes when restoring from the Hibernate. In the resume flow, driver need to clean up the older nic/vec objects and re-initialize them. Fixes: 8aaa112a ("net: atlantic: refactoring pm logic") Signed-off-by:
Sudarsana Reddy Kalluru <skalluru@marvell.com> Signed-off-by:
Igor Russkikh <irusskikh@marvell.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit fd6729ec ] This error path is unlikely because of it checked for NULL and returned -ENOMEM earlier in the function. But it should return an error code here as well if we ever do hit it because of a race condition or something. Fixes: bdcd8170 ("Add ath6kl cleaned up driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Brett Creeley authored
[ Upstream commit b357d971 ] commit 3ba7f53f ("ice: don't remove netdev->dev_addr from uc sync list") introduced calls to netif_addr_lock_bh() and netif_addr_unlock_bh() in the driver's ndo_set_mac() callback. This is fine since the driver is updated the netdev's dev_addr, but since this is a spinlock, the driver cannot sleep when the lock is held. Unfortunately the functions to add/delete MAC filters depend on a mutex. This was causing a trace with the lock debug kernel config options enabled when changing the mac address via iproute. [ 203.273059] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281 [ 203.273065] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6698, name: ip [ 203.273068] Preemption disabled at: [ 203.273068] [<ffffffffc04aaeab>] ice_set_mac_address+0x8b/0x1c0 [ice] [ 203.273097] CPU: 31 PID: 6698 Comm: ip Tainted: G S W I 5.14.0-rc4 #2 [ 203.273100] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020 [ 203.273102] Call Trace: [ 203.273107] dump_stack_lvl+0x33/0x42 [ 203.273113] ? ice_set_mac_address+0x8b/0x1c0 [ice] [ 203.273124] ___might_sleep.cold.150+0xda/0xea [ 203.273131] mutex_lock+0x1c/0x40 [ 203.273136] ice_remove_mac+0xe3/0x180 [ice] [ 203.273155] ? ice_fltr_add_mac_list+0x20/0x20 [ice] [ 203.273175] ice_fltr_prepare_mac+0x43/0xa0 [ice] [ 203.273194] ice_set_mac_address+0xab/0x1c0 [ice] [ 203.273206] dev_set_mac_address+0xb8/0x120 [ 203.273210] dev_set_mac_address_user+0x2c/0x50 [ 203.273212] do_setlink+0x1dd/0x10e0 [ 203.273217] ? __nla_validate_parse+0x12d/0x1a0 [ 203.273221] __rtnl_newlink+0x530/0x910 [ 203.273224] ? __kmalloc_node_track_caller+0x17f/0x380 [ 203.273230] ? preempt_count_add+0x68/0xa0 [ 203.273236] ? _raw_spin_lock_irqsave+0x1f/0x30 [ 203.273241] ? kmem_cache_alloc_trace+0x4d/0x440 [ 203.273244] rtnl_newlink+0x43/0x60 [ 203.273245] rtnetlink_rcv_msg+0x13a/0x380 [ 203.273248] ? rtnl_calcit.isra.40+0x130/0x130 [ 203.273250] netlink_rcv_skb+0x4e/0x100 [ 203.273256] netlink_unicast+0x1a2/0x280 [ 203.273258] netlink_sendmsg+0x242/0x490 [ 203.273260] sock_sendmsg+0x58/0x60 [ 203.273263] ____sys_sendmsg+0x1ef/0x260 [ 203.273265] ? copy_msghdr_from_user+0x5c/0x90 [ 203.273268] ? ____sys_recvmsg+0xe6/0x170 [ 203.273270] ___sys_sendmsg+0x7c/0xc0 [ 203.273272] ? copy_msghdr_from_user+0x5c/0x90 [ 203.273274] ? ___sys_recvmsg+0x89/0xc0 [ 203.273276] ? __netlink_sendskb+0x50/0x50 [ 203.273278] ? mod_objcg_state+0xee/0x310 [ 203.273282] ? __dentry_kill+0x114/0x170 [ 203.273286] ? get_max_files+0x10/0x10 [ 203.273288] __sys_sendmsg+0x57/0xa0 [ 203.273290] do_syscall_64+0x37/0x80 [ 203.273295] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 203.273296] RIP: 0033:0x7f8edf96e278 [ 203.273298] Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 63 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55 [ 203.273300] RSP: 002b:00007ffcb8bdac08 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 203.273303] RAX: ffffffffffffffda RBX: 000000006115e0ae RCX: 00007f8edf96e278 [ 203.273304] RDX: 0000000000000000 RSI: 00007ffcb8bdac70 RDI: 0000000000000003 [ 203.273305] RBP: 0000000000000000 R08: 0000000000000001 R09: 00007ffcb8bda5b0 [ 203.273306] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 203.273306] R13: 0000555e10092020 R14: 0000000000000000 R15: 0000000000000005 Fix this by only locking when changing the netdev->dev_addr. Also, make sure to restore the old netdev->dev_addr on any failures. Fixes: 3ba7f53f ("ice: don't remove netdev->dev_addr from uc sync list") Signed-off-by:
Brett Creeley <brett.creeley@intel.com> Tested-by:
Gurucharan G <gurucharanx.g@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by:
-
Abhishek Naik authored
[ Upstream commit 19426d54 ] By mistake we were considering the first element of the WTAS wifi package as part of the data we want to rid, but that element is the wifi package signature (always 0x07), so it should be skipped. Change the code to read the data starting from element 1 instead. Signed-off-by:
Abhishek Naik <abhishek.naik@intel.com> Fixes: 28dd7ccd ("iwlwifi: acpi: read TAS table from ACPI and send it to the FW") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20210805141826.ff8148197b15.I70636c04e37b2b57a5df3ce611511f62203d27a7@changeid Signed-off-by:
-
Emmanuel Grumbach authored
[ Upstream commit cdaba917 ] The new inclusive terminology requires to change a few terms that were used in iwlwifi. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit d3efd26a ] The probe calls 'wcd9335_setup_irqs()' to enable interrupts on all slave ports. This must be undone in the remove function. Add a 'wcd9335_teardown_irqs()' function that undoes 'wcd9335_setup_irqs()' function, and call it from the remove function. Fixes: 20aedafd ("ASoC: wcd9335: add support to wcd9335 codec") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Message-Id: <8f761244d79bd4c098af8a482be9121d3a486d1b.1629091028.git.christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit fc6fc81c ] If 'wcd9335_setup_irqs()' fails, me must release the memory allocated in 'wcd_clsh_ctrl_alloc()', as already done in the remove function. Add an error handling path and the missing 'wcd_clsh_ctrl_free()' call. Fixes: 20aedafd ("ASoC: wcd9335: add support to wcd9335 codec") Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 7a6a723e ] There is no point in calling 'free_irq()' explicitly for 'WCD9335_IRQ_SLIMBUS' in the remove function. The irqs are requested in 'wcd9335_setup_irqs()' using a resource managed function (i.e. 'devm_request_threaded_irq()'). 'wcd9335_setup_irqs()' requests all what is defined in the 'wcd9335_irqs' structure. This structure has only one entry for 'WCD9335_IRQ_SLIMBUS'. So 'devm_request...irq()' + explicit 'free_irq()' would lead to a double free. Remove the unneeded 'free_irq()' from the remove function. Fixes: 20aedafd ("ASoC: wcd9335: add support to wcd9335 codec") Signed-off-by:
-
Andy Duan authored
[ Upstream commit d5c38948 ] Register offset needs to be applied on mapbase also. dma_tx/rx_request use the physical address of UARTDATA. Register offset is currently only applied to membase (the corresponding virtual addr) but not on mapbase. Fixes: 24b1e5f0 ("tty: serial: lpuart: add imx7ulp support") Reviewed-by:
Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by:
Adriana Reus <adriana.reus@nxp.com> Signed-off-by:
Sherry Sun <sherry.sun@nxp.com> Signed-off-by:
Andy Duan <fugang.duan@nxp.com> Link: https://lore.kernel.org/r/20210819021033.32606-1-sherry.sun@nxp.com Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 6f15a2a0 ] If an error occurs after a successful 'clk_prepare_enable()' call, it must be undone by a corresponding 'clk_disable_unprepare()' call. This call is already present in the remove function. Add this call in the error handling path and reorder the code so that the 'clk_prepare_enable()' call happens later in the function. The goal is to have as much managed resources functions as possible before the 'clk_prepare_enable()' call in order to keep the error handling path simple. While at it, remove the now unneeded 'clk' variable. Fixes: c87dca04 ("usb: bdc: Add clock enable for new chips with a separate BDC clock") Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit d2f42e09 ] If no suitable DMA configuration is available, a previous 'bdc_phy_init()' call must be undone by a corresponding 'bdc_phy_exit()' call. Branch to the existing error handling path instead of returning directly. Fixes: cc29d4f6 ("usb: bdc: Add support for USB phy") Acked-by:
-
Evgeny Novikov authored
[ Upstream commit 4720f1bf ] ehci_orion_drv_probe() did not account for possible errors of clk_prepare_enable() that in particular could cause invocation of clk_disable_unprepare() on clocks that were not prepared/enabled yet, e.g. in remove or on handling errors of usb_add_hcd() in probe. Though, there were several patches fixing different issues with clocks in this driver, they did not solve this problem. Add handling of errors of clk_prepare_enable() in ehci_orion_drv_probe() to avoid calls of clk_disable_unprepare() without previous successful invocation of clk_prepare_enable(). Found by Linux Driver Verification project (linuxtesting.org). Fixes: 8c869eda ("ARM: Orion: EHCI: Add support for enabling clocks") Co-developed-by:
Kirill Shilimanov <kirill.shilimanov@huawei.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Evgeny Novikov <novikov@ispras.ru> Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit 661e8a88 ] Iff platform_get_irq() returns 0 for the main IRQ, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: 2bbd681b ("i2c: xlp9xx: Driver for Netlogic XLP9XX/5XX I2C controller") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by:
George Cherian <george.cherian@marvell.com> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit 58fb7c64 ] Iff platform_get_irq() returns 0, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: ce38815d ("I2C: mediatek: Add driver for MediaTek I2C controller") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omprussia.ru> Reviewed-by:
Qii Wang <qii.wang@mediatek.com> Signed-off-by:
-
Len Baker authored
[ Upstream commit f980d055 ] strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated. Also, the strnlen() call does not avoid the read overflow in the strlcpy function when a not NUL-terminated string is passed. So, replace this block by a call to kstrndup() that avoids this type of overflow and does the same. Fixes: 066ce689 ("cifs: rename cifs_strlcpy_to_host and make it use new functions") Signed-off-by:
Len Baker <len.baker@gmx.com> Reviewed-by:
Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Andrey Ignatov authored
[ Upstream commit d7af7e49 ] Fix a verifier bug found by smatch static checker in [0]. This problem has never been seen in prod to my best knowledge. Fixing it still seems to be a good idea since it's hard to say for sure whether it's possible or not to have a scenario where a combination of convert_ctx_access() and a narrow load would lead to an out of bound write. When narrow load is handled, one or two new instructions are added to insn_buf array, but before it was only checked that cnt >= ARRAY_SIZE(insn_buf) And it's safe to add a new instruction to insn_buf[cnt++] only once. The second try will lead to out of bound write. And this is what can happen if `shift` is set. Fix it by making sure that if the BPF_RSH instruction has to be added in addition to BPF_AND then there is enough space for two more instructions in insn_buf. The full report [0] is below: kernel/bpf/verifier.c:12304 convert_ctx_accesses() warn: offset 'cnt' incremented past end of array kernel/bpf/verifier.c:12311 convert_ctx_accesses() warn: offset 'cnt' incremented past end of array kernel/bpf/verifier.c 12282 12283 insn->off = off & ~(size_default - 1); 12284 insn->code = BPF_LDX | BPF_MEM | size_code; 12285 } 12286 12287 target_size = 0; 12288 cnt = convert_ctx_access(type, insn, insn_buf, env->prog, 12289 &target_size); 12290 if (cnt == 0 || cnt >= ARRAY_SIZE(insn_buf) || ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bounds check. 12291 (ctx_field_size && !target_size)) { 12292 verbose(env, "bpf verifier is misconfigured\n"); 12293 return -EINVAL; 12294 } 12295 12296 if (is_narrower_load && size < target_size) { 12297 u8 shift = bpf_ctx_narrow_access_offset( 12298 off, size, size_default) * 8; 12299 if (ctx_field_size <= 4) { 12300 if (shift) 12301 insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH, ^^^^^ increment beyond end of array 12302 insn->dst_reg, 12303 shift); --> 12304 insn_buf[cnt++] = BPF_ALU32_IMM(BPF_AND, insn->dst_reg, ^^^^^ out of bounds write 12305 (1 << size * 8) - 1); 12306 } else { 12307 if (shift) 12308 insn_buf[cnt++] = BPF_ALU64_IMM(BPF_RSH, 12309 insn->dst_reg, 12310 shift); 12311 insn_buf[cnt++] = BPF_ALU64_IMM(BPF_AND, insn->dst_reg, ^^^^^^^^^^^^^^^ Same. 12312 (1ULL << size * 8) - 1); 12313 } 12314 } 12315 12316 new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt); 12317 if (!new_prog) 12318 return -ENOMEM; 12319 12320 delta += cnt - 1; 12321 12322 /* keep walking new program and skip insns we just inserted */ 12323 env->prog = new_prog; 12324 insn = new_prog->insnsi + i + delta; 12325 } 12326 12327 return 0; 12328 } [0] https://lore.kernel.org/bpf/20210817050843.GA21456@kili/ v1->v2: - clarify that problem was only seen by static checker but not in prod; Fixes: 46f53a65 ("bpf: Allow narrow loads with offset > 0") Reported-by:
Andrey Ignatov <rdna@fb.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20210820163935.1902398-1-rdna@fb.com Signed-off-by:
-
