- 19 Feb, 2020 22 commits
-
-
Sean Christopherson authored
commit 148d735e upstream. Hardcode the EPT page-walk level for L2 to be 4 levels, as KVM's MMU currently also hardcodes the page walk level for nested EPT to be 4 levels. The L2 guest is all but guaranteed to soft hang on its first instruction when L1 is using EPT, as KVM will construct 4-level page tables and then tell hardware to use 5-level page tables. Fixes: 855feb67 ("KVM: MMU: Add 5 level EPT & Shadow page table support.") Cc: stable@vger.kernel.org Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
commit fca3d33d upstream. When all CPUs in the system implement the SSBS extension, the SSBS field in PSTATE is the definitive indication of the mitigation state. Further, when the CPUs implement the SSBS manipulation instructions (advertised to userspace via an HWCAP), EL0 can toggle the SSBS field directly and so we cannot rely on any shadow state such as TIF_SSBD at all. Avoid forcing the SSBS field in context-switch on such a system, and simply rely on the PSTATE register instead. Cc: <stable@vger.kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Srinivas Ramana <sramana@codeaurora.org> Fixes: cbdf8a18 ("arm64: Force SSBS on context switch") Reviewed-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
commit e383e871 upstream. The CONFIG_ARCH_REQUIRE_GPIOLIB is gone since commit 65053e1a ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB") and all platforms should explicitly select GPIOLIB to have it. Link: https://lore.kernel.org/r/20200130195525.4525-1-krzk@kernel.org Cc: <stable@vger.kernel.org> Fixes: 65053e1a ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB") Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
David Sterba authored
commit 10a3a3ed upstream. A remount to a read-write filesystem is not safe when there's tree-log to be replayed. Files that could be opened until now might be affected by the changes in the tree-log. A regular mount is needed to replay the log so the filesystem presents the consistent view with the pending changes included. CC: stable@vger.kernel.org # 4.4+ Reviewed-by:
Anand Jain <anand.jain@oracle.com> Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
David Sterba authored
commit e8294f2f upstream. There's no logged information about tree-log replay although this is something that points to previous unclean unmount. Other filesystems report that as well. Suggested-by:
Chris Murphy <lists@colorremedies.com> CC: stable@vger.kernel.org # 4.4+ Reviewed-by:
-
Wenwen Wang authored
commit f311ade3 upstream. In btrfs_ref_tree_mod(), 'ref' and 'ra' are allocated through kzalloc() and kmalloc(), respectively. In the following code, if an error occurs, the execution will be redirected to 'out' or 'out_unlock' and the function will be exited. However, on some of the paths, 'ref' and 'ra' are not deallocated, leading to memory leaks. For example, if 'action' is BTRFS_ADD_DELAYED_EXTENT, add_block_entry() will be invoked. If the return value indicates an error, the execution will be redirected to 'out'. But, 'ref' is not deallocated on this path, causing a memory leak. To fix the above issues, deallocate both 'ref' and 'ra' before exiting from the function when an error is encountered. CC: stable@vger.kernel.org # 4.15+ Signed-off-by:
Wenwen Wang <wenwen@cs.uga.edu> Reviewed-by:
-
Filipe Manana authored
commit ac05ca91 upstream. We have a few cases where we allow an extent map that is in an extent map tree to be merged with other extents in the tree. Such cases include the unpinning of an extent after the respective ordered extent completed or after logging an extent during a fast fsync. This can lead to subtle and dangerous problems because when doing the merge some other task might be using the same extent map and as consequence see an inconsistent state of the extent map - for example sees the new length but has seen the old start offset. With luck this triggers a BUG_ON(), and not some silent bug, such as the following one in __do_readpage(): $ cat -n fs/btrfs/extent_io.c 3061 static int __do_readpage(struct extent_io_tree *tree, 3062 struct page *page, (...) 3127 em = __get_extent_map(inode, page, pg_offset, cur, 3128 end - cur + 1, get_extent, em_cached); 3129 if (IS_ERR_OR_NULL(em)) { 3130 SetPageError(page); 3131 unlock_extent(tree, cur, end); 3132 break; 3133 } 3134 extent_offset = cur - em->start; 3135 BUG_ON(extent_map_end(em) <= cur); (...) Consider the following example scenario, where we end up hitting the BUG_ON() in __do_readpage(). We have an inode with a size of 8KiB and 2 extent maps: extent A: file offset 0, length 4KiB, disk_bytenr = X, persisted on disk by a previous transaction extent B: file offset 4KiB, length 4KiB, disk_bytenr = X + 4KiB, not yet persisted but writeback started for it already. The extent map is pinned since there's writeback and an ordered extent in progress, so it can not be merged with extent map A yet The following sequence of steps leads to the BUG_ON(): 1) The ordered extent for extent B completes, the respective page gets its writeback bit cleared and the extent map is unpinned, at that point it is not yet merged with extent map A because it's in the list of modified extents; 2) Due to memory pressure, or some other reason, the MM subsystem releases the page corresponding to extent B - btrfs_releasepage() is called and returns 1, meaning the page can be released as it's not dirty, not under writeback anymore and the extent range is not locked in the inode's iotree. However the extent map is not released, either because we are not in a context that allows memory allocations to block or because the inode's size is smaller than 16MiB - in this case our inode has a size of 8KiB; 3) Task B needs to read extent B and ends up __do_readpage() through the btrfs_readpage() callback. At __do_readpage() it gets a reference to extent map B; 4) Task A, doing a fast fsync, calls clear_em_loggin() against extent map B while holding the write lock on the inode's extent map tree - this results in try_merge_map() being called and since it's possible to merge extent map B with extent map A now (the extent map B was removed from the list of modified extents), the merging begins - it sets extent map B's start offset to 0 (was 4KiB), but before it increments the map's length to 8KiB (4kb + 4KiB), task A is at: BUG_ON(extent_map_end(em) <= cur); The call to extent_map_end() sees the extent map has a start of 0 and a length still at 4KiB, so it returns 4KiB and 'cur' is 4KiB, so the BUG_ON() is triggered. So it's dangerous to modify an extent map that is in the tree, because some other task might have got a reference to it before and still using it, and needs to see a consistent map while using it. Generally this is very rare since most paths that lookup and use extent maps also have the file range locked in the inode's iotree. The fsync path is pretty much the only exception where we don't do it to avoid serialization with concurrent reads. Fix this by not allowing an extent map do be merged if if it's being used by tasks other then the one attempting to merge the extent map (when the reference count of the extent map is greater than 2). Reported-by:
ryusuke1925 <st13s20@gm.ibaraki-ct.ac.jp> Reported-by:
Koki Mitani <koki.mitani.xg@hco.ntt.co.jp> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206211 CC: stable@vger.kernel.org # 4.4+ Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
-
Theodore Ts'o authored
commit d65d87a0 upstream. If CONFIG_QFMT_V2 is not enabled, but CONFIG_QUOTA is enabled, when a user tries to mount a file system with the quota or project quota enabled, the kernel will emit a very confusing messsage: EXT4-fs warning (device vdc): ext4_enable_quotas:5914: Failed to enable quota tracking (type=0, err=-3). Please run e2fsck to fix. EXT4-fs (vdc): mount failed We will now report an explanatory message indicating which kernel configuration options have to be enabled, to avoid customer/sysadmin confusion. Link: https://lore.kernel.org/r/20200215012738.565735-1-tytso@mit.edu Google-Bug-Id: 149093531 Fixes: 7c319d32 ("ext4: make quota as first class supported feature") Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
-
Shijie Luo authored
commit af133ade upstream. When journal size is set too big by "mkfs.ext4 -J size=", or when we mount a crafted image to make journal inode->i_size too big, the loop, "while (i < num)", holds cpu too long. This could cause soft lockup. [ 529.357541] Call trace: [ 529.357551] dump_backtrace+0x0/0x198 [ 529.357555] show_stack+0x24/0x30 [ 529.357562] dump_stack+0xa4/0xcc [ 529.357568] watchdog_timer_fn+0x300/0x3e8 [ 529.357574] __hrtimer_run_queues+0x114/0x358 [ 529.357576] hrtimer_interrupt+0x104/0x2d8 [ 529.357580] arch_timer_handler_virt+0x38/0x58 [ 529.357584] handle_percpu_devid_irq+0x90/0x248 [ 529.357588] generic_handle_irq+0x34/0x50 [ 529.357590] __handle_domain_irq+0x68/0xc0 [ 529.357593] gic_handle_irq+0x6c/0x150 [ 529.357595] el1_irq+0xb8/0x140 [ 529.357599] __ll_sc_atomic_add_return_acquire+0x14/0x20 [ 529.357668] ext4_map_blocks+0x64/0x5c0 [ext4] [ 529.357693] ext4_setup_system_zone+0x330/0x458 [ext4] [ 529.357717] ext4_fill_super+0x2170/0x2ba8 [ext4] [ 529.357722] mount_bdev+0x1a8/0x1e8 [ 529.357746] ext4_mount+0x44/0x58 [ext4] [ 529.357748] mount_fs+0x50/0x170 [ 529.357752] vfs_kern_mount.part.9+0x54/0x188 [ 529.357755] do_mount+0x5ac/0xd78 [ 529.357758] ksys_mount+0x9c/0x118 [ 529.357760] __arm64_sys_mount+0x28/0x38 [ 529.357764] el0_svc_common+0x78/0x130 [ 529.357766] el0_svc_handler+0x38/0x78 [ 529.357769] el0_svc+0x8/0xc [ 541.356516] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [mount:18674] Link: https://lore.kernel.org/r/20200211011752.29242-1-luoshijie1@huawei.comReviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Shijie Luo <luoshijie1@huawei.com> Signed-off-by:
-
Jan Kara authored
commit 48a34311 upstream. DIR_INDEX has been introduced as a compat ext4 feature. That means that even kernels / tools that don't understand the feature may modify the filesystem. This works because for kernels not understanding indexed dir format, internal htree nodes appear just as empty directory entries. Index dir aware kernels then check the htree structure is still consistent before using the data. This all worked reasonably well until metadata checksums were introduced. The problem is that these effectively made DIR_INDEX only ro-compatible because internal htree nodes store checksums in a different place than normal directory blocks. Thus any modification ignorant to DIR_INDEX (or just clearing EXT4_INDEX_FL from the inode) will effectively cause checksum mismatch and trigger kernel errors. So we have to be more careful when dealing with indexed directories on filesystems with checksumming enabled. 1) We just disallow loading any directory inodes with EXT4_INDEX_FL when DIR_INDEX is not enabled. This is harsh but it should be very rare (it means someone disabled DIR_INDEX on existing filesystem and didn't run e2fsck), e2fsck can fix the problem, and we don't want to answer the difficult question: "Should we rather corrupt the directory more or should we ignore that DIR_INDEX feature is not set?" 2) When we find out htree structure is corrupted (but the filesystem and the directory should in support htrees), we continue just ignoring htree information for reading but we refuse to add new entries to the directory to avoid corrupting it more. Link: https://lore.kernel.org/r/20200210144316.22081-1-jack@suse.cz Fixes: dbe89444 ("ext4: Calculate and verify checksums for htree nodes") Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Signed-off-by:
-
Theodore Ts'o authored
commit 4f97a681 upstream. A recent commit, 9803387c ("ext4: validate the debug_want_extra_isize mount option at parse time"), moved mount-time checks around. One of those changes moved the inode size check before the blocksize variable was set to the blocksize of the file system. After 9803387c was set to the minimum allowable blocksize, which in practice on most systems would be 1024 bytes. This cuased file systems with inode sizes larger than 1024 bytes to be rejected with a message: EXT4-fs (sdXX): unsupported inode size: 4096 Fixes: 9803387c ("ext4: validate the debug_want_extra_isize mount option at parse time") Link: https://lore.kernel.org/r/20200206225252.GA3673@mit.eduReported-by:
Herbert Poetzl <herbert@13thfloor.at> Signed-off-by:
-
Andreas Dilger authored
commit 14c9ca05 upstream. Don't assume that the mmp_nodename and mmp_bdevname strings are NUL terminated, since they are filled in by snprintf(), which is not guaranteed to do so. Link: https://lore.kernel.org/r/1580076215-1048-1-git-send-email-adilger@dilger.caSigned-off-by:
-
Alexander Tsoy authored
commit 9f35a312 upstream. It should be safe to ignore clock validity check result if the following conditions are met: - only one single sample rate is supported; - the terminal is directly connected to the clock source; - the clock type is internal. This is to deal with some Denon DJ controllers that always reports that clock is invalid. Tested-by:
Tobias Oszlanyi <toszlanyi@yahoo.de> Signed-off-by:
Alexander Tsoy <alexander@tsoy.me> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200212235450.697348-1-alexander@tsoy.meSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Saurav Girepunje authored
commit 1d4961d9 upstream. Use true/false for bool type return in uac_clock_source_is_valid(). Signed-off-by:
Saurav Girepunje <saurav.girepunje@gmail.com> Link: https://lore.kernel.org/r/20191029175200.GA7320@sauravSigned-off-by:
-
Suzuki K Poulose authored
commit 52f73c38 upstream We detect the absence of FP/SIMD after an incapable CPU is brought up, and by then we have kernel threads running already with TIF_FOREIGN_FPSTATE set which could be set for early userspace applications (e.g, modprobe triggered from initramfs) and init. This could cause the applications to loop forever in do_nofity_resume() as we never clear the TIF flag, once we now know that we don't support FP. Fix this by making sure that we clear the TIF_FOREIGN_FPSTATE flag for tasks which may have them set, as we would have done in the normal case, but avoiding touching the hardware state (since we don't support any). Also to make sure we handle the cases seemlessly we categorise the helper functions to two : 1) Helpers for common core code, which calls into take appropriate actions without knowing the current FPSIMD state of the CPU/task. e.g fpsimd_restore_current_state(), fpsimd_flush_task_state(), fpsimd_save_and_flush_cpu_state(). We bail out early for these functions, taking any appropriate actions (e.g, clearing the TIF flag) where necessary to hide the handling from core code. 2) Helpers used when the presence of FP/SIMD is apparent. i.e, save/restore the FP/SIMD register state, modify the CPU/task FP/SIMD state. e.g, fpsimd_save(), task_fpsimd_load() - save/restore task FP/SIMD registers fpsimd_bind_task_to_cpu() \ - Update the "state" metadata for CPU/task. fpsimd_bind_state_to_cpu() / fpsimd_update_current_state() - Update the fp/simd state for the current task from memory. These must not be called in the absence of FP/SIMD. Put in a WARNING to make sure they are not invoked in the absence of FP/SIMD. KVM also uses the TIF_FOREIGN_FPSTATE flag to manage the FP/SIMD state on the CPU. However, without FP/SIMD support we trap all accesses and inject undefined instruction. Thus we should never "load" guest state. Add a sanity check to make sure this is valid. Cc: stable@vger.kernel.org # v4.19 Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Suzuki K Poulose authored
commit 7559950a upstream We set the compat_elf_hwcap bits unconditionally on arm64 to include the VFP and NEON support. However, the FP/SIMD unit is optional on Arm v8 and thus could be missing. We already handle this properly in the kernel, but still advertise to the COMPAT applications that the VFP is available. Fix this to make sure we only advertise when we really have them. Cc: stable@vger.kernel.org # v4.19 Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by:
-
Arvind Sankar authored
commit 93f9d1a4 upstream. The Audioengine D1 (0x2912:0x30c8) does support reading the sample rate, but it returns the rate in byte-reversed order. When setting sampling rate, the driver produces these warning messages: [168840.944226] usb 3-2.2: current rate 4500480 is different from the runtime rate 44100 [168854.930414] usb 3-2.2: current rate 8436480 is different from the runtime rate 48000 [168905.185825] usb 3-2.1.2: current rate 30465 is different from the runtime rate 96000 As can be seen from the hexadecimal conversion, the current rate read back is byte-reversed from the rate that was set. 44100 == 0x00ac44, 4500480 == 0x44ac00 48000 == 0x00bb80, 8436480 == 0x80bb00 96000 == 0x017700, 30465 == 0x007701 Rather than implementing a new quirk to reverse the order, just skip checking the rate to avoid spamming the log. Signed-off-by:
Arvind Sankar <nivedita@alum.mit.edu> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200211162235.1639889-1-nivedita@alum.mit.eduSigned-off-by:
-
Takashi Iwai authored
commit 7dafba37 upstream. MSI-GL73 laptop with ALC1220 codec requires a similar workaround for Clevo laptops to enforce the DAC/mixer connection path. Set up a quirk entry for that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204159 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200212081047.27727-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
commit d75a170f upstream. We've got a regression report about M-Audio Fast Track C400 device, and the git bisection resulted in the commit e0ccdef9 ("ALSA: usb-audio: Clean up check_input_term()"). This commit was about the rewrite of the input terminal parser, and it's not too obvious from the change what really broke. The answer is: it's the interpretation of UAC2/3 effect units. In the original code, UAC2 effect unit is as if through UAC1 processing unit because both UAC1 PU and UAC2/3 EU share the same number (0x07). The old code went through a complex switch-case fallthrough, finally bailing out in the middle: if (protocol == UAC_VERSION_2 && hdr[2] == UAC2_EFFECT_UNIT) { /* UAC2/UAC1 unit IDs overlap here in an * uncompatible way. Ignore this unit for now. */ return 0; } ... and this special handling was missing in the new code; the new code treats UAC2/3 effect unit as if it were equivalent with the processing unit. Actually, the old code was too confusing. The effect unit has an incompatible unit description with the processing unit, so we shouldn't have dealt with EU in the same way. This patch addresses the regression by changing the effect unit handling to the own parser function. The own parser function makes the clear distinct with PU, so it improves the readability, too. The EU parser just sets the type and the id like the old kernels. Once when the proper effect unit support is added, we can revisit this parser function, but for now, let's keep this simple setup as is. Fixes: e0ccdef9 ("ALSA: usb-audio: Clean up check_input_term()") Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206147 Link: https://lore.kernel.org/r/20200211160521.31990-1-tiwai@suse.deSigned-off-by:
-
Benjamin Tissoires authored
commit 5179a9df upstream. The Yoga 11e is using LEN0049, but it doesn't have a trackstick. Thus, there is no need to create a software top buttons row. However, it seems that the device works under SMBus, so keep it as part of the smbus_pnp_ids. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200115013023.9710-1-benjamin.tissoires@redhat.comSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Gaurav Agrawal authored
commit b8a3d819 upstream. Add touchpad LEN2044 to the list, as it is capable of working with psmouse.synaptics_intertouch=1 Signed-off-by:
Gaurav Agrawal <agrawalgaurav@gnome.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/CADdtggVzVJq5gGNmFhKSz2MBwjTpdN5YVOdr4D3Hkkv=KZRc9g@mail.gmail.comSigned-off-by:
-
Lyude Paul authored
commit bf502391 upstream. This supports RMI4 and everything seems to work, including the touchpad buttons. So, let's enable this by default. Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200204194322.112638-1-lyude@redhat.comSigned-off-by:
-
- 14 Feb, 2020 18 commits
-
-
Greg Kroah-Hartman authored
-
Daniel Jordan authored
The 4.19 backport dc34710a ("padata: Remove broken queue flushing") removed padata_alloc_pd()'s assignment to pd->pinst, resulting in: Unable to handle kernel NULL pointer dereference ... ... pc : padata_reorder+0x144/0x2e0 ... Call trace: padata_reorder+0x144/0x2e0 padata_do_serial+0xc8/0x128 pcrypt_aead_enc+0x60/0x70 [pcrypt] padata_parallel_worker+0xd8/0x138 process_one_work+0x1bc/0x4b8 worker_thread+0x164/0x580 kthread+0x134/0x138 ret_from_fork+0x10/0x18 This happened because the backport was based on an enhancement that moved this assignment but isn't in 4.19: bfde23ce ("padata: unbind parallel jobs from specific CPUs") Simply restore the assignment to fix the crash. Fixes: dc34710a ("padata: Remove broken queue flushing") Reported-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Sasha Levin <sashal@kernel.org> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by:
-
Shubhrajyoti Datta authored
commit 10747568 upstream. Currently we are doing a read of the status register. Move the spinlock after that as the reads need not be spinlock protected. This patch prevents relaxing the cpu with spinlock held. Signed-off-by:
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Cc: Pavel Machek <pavel@denx.de> Signed-off-by:
-
Peter Zijlstra authored
commit ea1ed38d upstream. When CONFIG_FRAME_POINTER, we should mark pt_regs frames. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> [4.19 backport; added user-visible changelog] Signed-off-by:
Dmitry Safonov <dima@arista.com> Signed-off-by:
-
Peter Zijlstra authored
commit a9b3c699 upstream. In preparation for wider use, move the ENCODE_FRAME_POINTER macros to a common header and provide inline asm versions. These macros are used to encode a pt_regs frame for the unwinder; see unwind_frame.c:decode_frame_pointer(). Signed-off-by:
-
Anand Lodnoor authored
commit 6d753727 upstream. Driver initiates OCR if a DCMD command times out. But there is a deadlock if the driver attempts to invoke another OCR before the mutex lock (reset_mutex) is released from the previous session of OCR. This patch takes care of the above scenario using new flag MEGASAS_FUSION_OCR_NOT_POSSIBLE to indicate if OCR is possible. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1579000882-20246-9-git-send-email-anand.lodnoor@broadcom.comSigned-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by:
Anand Lodnoor <anand.lodnoor@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Nicolai Stange authored
[ Upstream commit 1754c4f6 ] Commit e5e884b4 ("libertas: Fix two buffer overflows at parsing bss descriptor") introduced a bounds check on the number of supplied rates to lbs_ibss_join_existing() and made it to return on overflow. However, the aforementioned commit doesn't set the return value accordingly and thus, lbs_ibss_join_existing() would return with zero even though it failed. Make lbs_ibss_join_existing return -EINVAL in case the bounds check on the number of supplied rates fails. Fixes: e5e884b4 ("libertas: Fix two buffer overflows at parsing bss descriptor") Signed-off-by:
Nicolai Stange <nstange@suse.de> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Nicolai Stange authored
[ Upstream commit c7bf1fb7 ] Commit e5e884b4 ("libertas: Fix two buffer overflows at parsing bss descriptor") introduced a bounds check on the number of supplied rates to lbs_ibss_join_existing(). Unfortunately, it introduced a return path from within a RCU read side critical section without a corresponding rcu_read_unlock(). Fix this. Fixes: e5e884b4 ("libertas: Fix two buffer overflows at parsing bss descriptor") Signed-off-by:
-
Qing Xu authored
[ Upstream commit b70261a2 ] mwifiex_cmd_append_vsie_tlv() calls memcpy() without checking the destination size may trigger a buffer overflower, which a local user could use to cause denial of service or the execution of arbitrary code. Fix it by putting the length check before calling memcpy(). Signed-off-by:
Qing Xu <m1s5p6688@gmail.com> Signed-off-by:
-
Qing Xu authored
[ Upstream commit 3a9b153c ] mwifiex_ret_wmm_get_status() calls memcpy() without checking the destination size.Since the source is given from remote AP which contains illegal wmm elements , this may trigger a heap buffer overflow. Fix it by putting the length check before calling memcpy(). Signed-off-by:
-
Geert Uytterhoeven authored
commit 805f6357 upstream. The FN_SDSELF_B and FN_SD1_CLK_B enum IDs are used twice, which means one set of users must be wrong. Replace them by the correct enum IDs. Fixes: 87f8c988 ("sh-pfc: Add r8a7778 pinmux support") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191218194812.12741-2-geert+renesas@glider.beSigned-off-by:
-
Gustavo A. R. Silva authored
commit 0d962e06 upstream. Enclose multiple macro parameters in parentheses in order to make such macros safer and fix the Clang warning below: drivers/media/i2c/adv748x/adv748x-afe.c:452:12: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] ret = sdp_clrset(state, ADV748X_SDP_FRP, ADV748X_SDP_FRP_MASK, enable ? ctrl->val - 1 : 0); Fixes: 3e89586a ("media: i2c: adv748x: add adv748x driver") Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Eric Biggers authored
commit b529f198 upstream. HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only fail due to -ENOMEM. But atmel_sha_hmac_setkey() incorrectly treated any error as a "bad key length" error. Fix it to correctly propagate the -ENOMEM error code and not set any tfm result flags. Fixes: 81d8750b ("crypto: atmel-sha - add support to hmac(shaX)") Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Eric Biggers authored
commit b828f905 upstream. ->setkey() is supposed to retun -EINVAL for invalid key lengths, not -1. Fixes: a21eb94f ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver") Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Lars Persson <lars.persson@axis.com> Signed-off-by:
Lars Persson <lars.persson@axis.com> Signed-off-by:
-
YueHaibing authored
commit f33113b5 upstream. The unsigned variable log_num is being assigned a return value from the call to sharpsl_nand_get_logical_num that can return -EINVAL. Detected using Coccinelle: ./drivers/mtd/parsers/sharpslpart.c:207:6-13: WARNING: Unsigned expression compared with zero: log_num > 0 Fixes: 8a4580e4 ("mtd: sharpslpart: Add sharpslpart partition parser") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Nathan Chancellor authored
commit 0e7ca83e upstream. Clang warns: ../drivers/mtd/nand/onenand/onenand_base.c:1269:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] while (!ret) { ^ ../drivers/mtd/nand/onenand/onenand_base.c:1266:2: note: previous statement is here if (column + thislen > writesize) ^ 1 warning generated. This warning occurs because there is a space before the tab of the while loop. There are spaces at the beginning of a lot of the lines in this block, remove them so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. Fixes: a8de85d5 ("[MTD] OneNAND: Implement read-while-load") Link: https://github.com/ClangBuiltLinux/linux/issues/794Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Eric Auger authored
commit 3837407c upstream. The specification says PMSWINC increments PMEVCNTR<n>_EL1 by 1 if PMEVCNTR<n>_EL0 is enabled and configured to count SW_INCR. For PMEVCNTR<n>_EL0 to be enabled, we need both PMCNTENSET to be set for the corresponding event counter but we also need the PMCR.E bit to be set. Fixes: 7a0adc70 ("arm64: KVM: Add access handler for PMSWINC register") Signed-off-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Andrew Murray <andrew.murray@arm.com> Acked-by:
-
James Morse authored
commit 21aecdbd upstream. KVM's inject_abt64() injects an external-abort into an aarch64 guest. The KVM_CAP_ARM_INJECT_EXT_DABT is intended to do exactly this, but for an aarch32 guest inject_abt32() injects an implementation-defined exception, 'Lockdown fault'. Change this to external abort. For non-LPAE we now get the documented: | Unhandled fault: external abort on non-linefetch (0x008) at 0x9c800f00 and for LPAE: | Unhandled fault: synchronous external abort (0x210) at 0x9c800f00 Fixes: 74a64a98 ("KVM: arm/arm64: Unify 32bit fault injection") Reported-by:
Beata Michalska <beata.michalska@linaro.org> Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
-
