commit 397a88b2cc869c823bf40bc403d36a62afec1edd Author: Greg Kroah-Hartman Date: Wed Mar 3 18:22:57 2021 +0100 Linux 4.14.223 Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210302122237.974772983@linuxfoundation.org Link: https://lore.kernel.org/r/20210301193533.081071873@linuxfoundation.org Link: https://lore.kernel.org/r/20210302192539.408045707@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 1788a8b4f84a6cf22460ab40924d9fe107a71a45 Author: Nikos Tsironis Date: Fri Jan 22 17:19:31 2021 +0200 dm era: Update in-core bitset after committing the metadata commit 2099b145d77c1d53f5711f029c37cc537897cee6 upstream. In case of a system crash, dm-era might fail to mark blocks as written in its metadata, although the corresponding writes to these blocks were passed down to the origin device and completed successfully. Consider the following sequence of events: 1. We write to a block that has not been yet written in the current era 2. era_map() checks the in-core bitmap for the current era and sees that the block is not marked as written. 3. The write is deferred for submission after the metadata have been updated and committed. 4. The worker thread processes the deferred write (process_deferred_bios()) and marks the block as written in the in-core bitmap, **before** committing the metadata. 5. The worker thread starts committing the metadata. 6. We do more writes that map to the same block as the write of step (1) 7. era_map() checks the in-core bitmap and sees that the block is marked as written, **although the metadata have not been committed yet**. 8. These writes are passed down to the origin device immediately and the device reports them as completed. 9. The system crashes, e.g., power failure, before the commit from step (5) finishes. When the system recovers and we query the dm-era target for the list of written blocks it doesn't report the aforementioned block as written, although the writes of step (6) completed successfully. The issue is that era_map() decides whether to defer or not a write based on non committed information. The root cause of the bug is that we update the in-core bitmap, **before** committing the metadata. Fix this by updating the in-core bitmap **after** successfully committing the metadata. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 372fb8e270446213ba51b11bfaa7b9632c0efa90 Author: Jason A. Donenfeld Date: Tue Feb 23 14:18:58 2021 +0100 net: icmp: pass zeroed opts from icmp{,v6}_ndo_send before sending commit ee576c47db60432c37e54b1e2b43a8ca6d3a8dca upstream. The icmp{,v6}_send functions make all sorts of use of skb->cb, casting it with IPCB or IP6CB, assuming the skb to have come directly from the inet layer. But when the packet comes from the ndo layer, especially when forwarded, there's no telling what might be in skb->cb at that point. As a result, the icmp sending code risks reading bogus memory contents, which can result in nasty stack overflows such as this one reported by a user: panic+0x108/0x2ea __stack_chk_fail+0x14/0x20 __icmp_send+0x5bd/0x5c0 icmp_ndo_send+0x148/0x160 In icmp_send, skb->cb is cast with IPCB and an ip_options struct is read from it. The optlen parameter there is of particular note, as it can induce writes beyond bounds. There are quite a few ways that can happen in __ip_options_echo. For example: // sptr/skb are attacker-controlled skb bytes sptr = skb_network_header(skb); // dptr/dopt points to stack memory allocated by __icmp_send dptr = dopt->__data; // sopt is the corrupt skb->cb in question if (sopt->rr) { optlen = sptr[sopt->rr+1]; // corrupt skb->cb + skb->data soffset = sptr[sopt->rr+2]; // corrupt skb->cb + skb->data // this now writes potentially attacker-controlled data, over // flowing the stack: memcpy(dptr, sptr+sopt->rr, optlen); } In the icmpv6_send case, the story is similar, but not as dire, as only IP6CB(skb)->iif and IP6CB(skb)->dsthao are used. The dsthao case is worse than the iif case, but it is passed to ipv6_find_tlv, which does a bit of bounds checking on the value. This is easy to simulate by doing a `memset(skb->cb, 0x41, sizeof(skb->cb));` before calling icmp{,v6}_ndo_send, and it's only by good fortune and the rarity of icmp sending from that context that we've avoided reports like this until now. For example, in KASAN: BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0xa0e/0x12b0 Write of size 38 at addr ffff888006f1f80e by task ping/89 CPU: 2 PID: 89 Comm: ping Not tainted 5.10.0-rc7-debug+ #5 Call Trace: dump_stack+0x9a/0xcc print_address_description.constprop.0+0x1a/0x160 __kasan_report.cold+0x20/0x38 kasan_report+0x32/0x40 check_memory_region+0x145/0x1a0 memcpy+0x39/0x60 __ip_options_echo+0xa0e/0x12b0 __icmp_send+0x744/0x1700 Actually, out of the 4 drivers that do this, only gtp zeroed the cb for the v4 case, while the rest did not. So this commit actually removes the gtp-specific zeroing, while putting the code where it belongs in the shared infrastructure of icmp{,v6}_ndo_send. This commit fixes the issue by passing an empty IPCB or IP6CB along to the functions that actually do the work. For the icmp_send, this was already trivial, thanks to __icmp_send providing the plumbing function. For icmpv6_send, this required a tiny bit of refactoring to make it behave like the v4 case, after which it was straight forward. Fixes: a2b78e9b2cac ("sunvnet: generate ICMP PTMUD messages for smaller port MTUs") Reported-by: SinYu Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/netdev/CAF=yD-LOF116aHub6RMe8vB8ZpnrrnoTdqhobEx+bvoA8AsP0w@mail.gmail.com/T/ Signed-off-by: Jason A. Donenfeld Link: https://lore.kernel.org/r/20210223131858.72082-1-Jason@zx2c4.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 564885afa52041de3ac7a847dc71dbfed41cfebe Author: Leon Romanovsky Date: Wed Feb 3 15:51:09 2021 +0200 ipv6: silence compilation warning for non-IPV6 builds commit 1faba27f11c8da244e793546a1b35a9b1da8208e upstream. The W=1 compilation of allmodconfig generates the following warning: net/ipv6/icmp.c:448:6: warning: no previous prototype for 'icmp6_send' [-Wmissing-prototypes] 448 | void icmp6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info, | ^~~~~~~~~~ Fix it by providing function declaration for builds with ipv6 as a module. Signed-off-by: Leon Romanovsky Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8b779e11bc55616fc100d5cecf3c1d3c317c39e4 Author: Eric Dumazet Date: Fri Jun 19 12:02:59 2020 -0700 ipv6: icmp6: avoid indirect call for icmpv6_send() commit cc7a21b6fbd945f8d8f61422ccd27203c1fafeb7 upstream. If IPv6 is builtin, we do not need an expensive indirect call to reach icmp6_send(). v2: put inline keyword before the type to avoid sparse warnings. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 86b9572a9629d284044a9b09b4aa2346b59d6f1b Author: Jason A. Donenfeld Date: Tue Feb 11 20:47:07 2020 +0100 sunvnet: use icmp_ndo_send helper commit 67c9a7e1e3ac491b5df018803639addc36f154ba upstream. Because sunvnet is calling icmp from network device context, it should use the ndo helper so that the rate limiting applies correctly. While we're at it, doing the additional route lookup before calling icmp_ndo_send is superfluous, since this is the job of the icmp code in the first place. Signed-off-by: Jason A. Donenfeld Cc: Shannon Nelson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 19ca89dd151a5bf05b9be9277dcecc78947be2e3 Author: Jason A. Donenfeld Date: Tue Feb 11 20:47:06 2020 +0100 gtp: use icmp_ndo_send helper commit e0fce6f945a26d4e953a147fe7ca11410322c9fe upstream. Because gtp is calling icmp from network device context, it should use the ndo helper so that the rate limiting applies correctly. Signed-off-by: Jason A. Donenfeld Cc: Harald Welte Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bf42c5461fd9e53978eaf7c2c47b07e5de4887d5 Author: Jason A. Donenfeld Date: Tue Feb 25 18:05:35 2020 +0800 icmp: allow icmpv6_ndo_send to work with CONFIG_IPV6=n commit a8e41f6033a0c5633d55d6e35993c9e2005d872f upstream. The icmpv6_send function has long had a static inline implementation with an empty body for CONFIG_IPV6=n, so that code calling it doesn't need to be ifdef'd. The new icmpv6_ndo_send function, which is intended for drivers as a drop-in replacement with an identical function signature, should follow the same pattern. Without this patch, drivers that used to work with CONFIG_IPV6=n now result in a linker error. Cc: Chen Zhou Reported-by: Hulk Robot Fixes: 0b41713b6066 ("icmp: introduce helper for nat'd source address in network device context") Signed-off-by: Jason A. Donenfeld Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 77c49eeb42c224777d7dd21db3b41fd882a40a65 Author: Jason A. Donenfeld Date: Tue Feb 11 20:47:05 2020 +0100 icmp: introduce helper for nat'd source address in network device context commit 0b41713b606694257b90d61ba7e2712d8457648b upstream. This introduces a helper function to be called only by network drivers that wraps calls to icmp[v6]_send in a conntrack transformation, in case NAT has been used. We don't want to pollute the non-driver path, though, so we introduce this as a helper to be called by places that actually make use of this, as suggested by Florian. Signed-off-by: Jason A. Donenfeld Cc: Florian Westphal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a20118fac889672244c2ce1311049cf5837ba30d Author: Nikos Tsironis Date: Thu Feb 11 16:22:43 2021 +0200 dm era: only resize metadata in preresume commit cca2c6aebe86f68103a8615074b3578e854b5016 upstream. Metadata resize shouldn't happen in the ctr. The ctr loads a temporary (inactive) table that will only become active upon resume. That is why resize should always be done in terms of resume. Otherwise a load (ctr) whose inactive table never becomes active will incorrectly resize the metadata. Also, perform the resize directly in preresume, instead of using the worker to do it. The worker might run other metadata operations, e.g., it could start digestion, before resizing the metadata. These operations will end up using the old size. This could lead to errors, like: device-mapper: era: metadata_digest_transcribe_writeset: dm_array_set_value failed device-mapper: era: process_old_eras: digest step failed, stopping digestion The reason of the above error is that the worker started the digestion of the archived writeset using the old, larger size. As a result, metadata_digest_transcribe_writeset tried to write beyond the end of the era array. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit bbbab123a1942d9852ba7d1f08925f2cc303a164 Author: Nikos Tsironis Date: Fri Jan 22 17:22:04 2021 +0200 dm era: Reinitialize bitset cache before digesting a new writeset commit 2524933307fd0036d5c32357c693c021ab09a0b0 upstream. In case of devices with at most 64 blocks, the digestion of consecutive eras uses the writeset of the first era as the writeset of all eras to digest, leading to lost writes. That is, we lose the information about what blocks were written during the affected eras. The digestion code uses a dm_disk_bitset object to access the archived writesets. This structure includes a one word (64-bit) cache to reduce the number of array lookups. This structure is initialized only once, in metadata_digest_start(), when we kick off digestion. But, when we insert a new writeset into the writeset tree, before the digestion of the previous writeset is done, or equivalently when there are multiple writesets in the writeset tree to digest, then all these writesets are digested using the same cache and the cache is not re-initialized when moving from one writeset to the next. For devices with more than 64 blocks, i.e., the size of the cache, the cache is indirectly invalidated when we move to a next set of blocks, so we avoid the bug. But for devices with at most 64 blocks we end up using the same cached data for digesting all archived writesets, i.e., the cache is loaded when digesting the first writeset and it never gets reloaded, until the digestion is done. As a result, the writeset of the first era to digest is used as the writeset of all the following archived eras, leading to lost writes. Fix this by reinitializing the dm_disk_bitset structure, and thus invalidating the cache, every time the digestion code starts digesting a new writeset. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 9584e2ab01faa9ce544244beae5a72e2766ac003 Author: Nikos Tsironis Date: Fri Jan 22 17:25:55 2021 +0200 dm era: Use correct value size in equality function of writeset tree commit 64f2d15afe7b336aafebdcd14cc835ecf856df4b upstream. Fix the writeset tree equality test function to use the right value size when comparing two btree values. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Reviewed-by: Ming-Hung Tsai Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 3a632be9015443b9ee12dd7c3066d076ee9cdb7d Author: Nikos Tsironis Date: Fri Jan 22 17:25:54 2021 +0200 dm era: Fix bitset memory leaks commit 904e6b266619c2da5c58b5dce14ae30629e39645 upstream. Deallocate the memory allocated for the in-core bitsets when destroying the target and in error paths. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Reviewed-by: Ming-Hung Tsai Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit ed2b54f8093039f2c772463e48bffb4f290f4e35 Author: Nikos Tsironis Date: Fri Jan 22 17:25:53 2021 +0200 dm era: Verify the data block size hasn't changed commit c8e846ff93d5eaa5384f6f325a1687ac5921aade upstream. dm-era doesn't support changing the data block size of existing devices, so check explicitly that the requested block size for a new target matches the one stored in the metadata. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Reviewed-by: Ming-Hung Tsai Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 454dd9c85c296ee158d223dac865c38cd52d1910 Author: Nikos Tsironis Date: Fri Jan 22 17:19:30 2021 +0200 dm era: Recover committed writeset after crash commit de89afc1e40fdfa5f8b666e5d07c43d21a1d3be0 upstream. Following a system crash, dm-era fails to recover the committed writeset for the current era, leading to lost writes. That is, we lose the information about what blocks were written during the affected era. dm-era assumes that the writeset of the current era is archived when the device is suspended. So, when resuming the device, it just moves on to the next era, ignoring the committed writeset. This assumption holds when the device is properly shut down. But, when the system crashes, the code that suspends the target never runs, so the writeset for the current era is not archived. There are three issues that cause the committed writeset to get lost: 1. dm-era doesn't load the committed writeset when opening the metadata 2. The code that resizes the metadata wipes the information about the committed writeset (assuming it was loaded at step 1) 3. era_preresume() starts a new era, without taking into account that the current era might not have been archived, due to a system crash. To fix this: 1. Load the committed writeset when opening the metadata 2. Fix the code that resizes the metadata to make sure it doesn't wipe the loaded writeset 3. Fix era_preresume() to check for a loaded writeset and archive it, before starting a new era. Fixes: eec40579d84873 ("dm: add era target") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Nikos Tsironis Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit eb540057b54334665aca8981e946e09f2b7bf435 Author: Bob Peterson Date: Fri Feb 5 13:50:41 2021 -0500 gfs2: Don't skip dlm unlock if glock has an lvb commit 78178ca844f0eb88f21f31c7fde969384be4c901 upstream. Patch fb6791d100d1 was designed to allow gfs2 to unmount quicker by skipping the step where it tells dlm to unlock glocks in EX with lvbs. This was done because when gfs2 unmounts a file system, it destroys the dlm lockspace shortly after it destroys the glocks so it doesn't need to unlock them all: the unlock is implied when the lockspace is destroyed by dlm. However, that patch introduced a use-after-free in dlm: as part of its normal dlm_recoverd process, it can call ls_recovery to recover dead locks. In so doing, it can call recover_rsbs which calls recover_lvb for any mastered rsbs. Func recover_lvb runs through the list of lkbs queued to the given rsb (if the glock is cached but unlocked, it will still be queued to the lkb, but in NL--Unlocked--mode) and if it has an lvb, copies it to the rsb, thus trying to preserve the lkb. However, when gfs2 skips the dlm unlock step, it frees the glock and its lvb, which means dlm's function recover_lvb references the now freed lvb pointer, copying the freed lvb memory to the rsb. This patch changes the check in gdlm_put_lock so that it calls dlm_unlock for all glocks that contain an lvb pointer. Fixes: fb6791d100d1 ("GFS2: skip dlm_unlock calls in unmount") Cc: stable@vger.kernel.org # v3.8+ Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 7207baf2388b17f3a2fc9e02a87706cad539dac5 Author: Al Viro Date: Mon Jul 20 02:21:51 2020 +0100 sparc32: fix a user-triggerable oops in clear_user() commit 7780918b36489f0b2f9a3749d7be00c2ceaec513 upstream. Back in 2.1.29 the clear_user() guts (__bzero()) had been merged with memset(). Unfortunately, while all exception handlers had been copied, one of the exception table entries got lost. As the result, clear_user() starting at 128*n bytes before the end of page and spanning between 8 and 127 bytes into the next page would oops when the second page is unmapped. It's trivial to reproduce - all it takes is main() { int fd = open("/dev/zero", O_RDONLY); char *p = mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0); munmap(p + 8192, 8192); read(fd, p + 8192 - 128, 192); } which had been oopsing since March 1997. Says something about the quality of test coverage... ;-/ And while today sparc32 port is nearly dead, back in '97 it had been very much alive; in fact, sparc64 had only been in mainline for 3 months by that point... Cc: stable@kernel.org Fixes: v2.1.29 Signed-off-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 24cc055b878f4d5669220d9cf4bef0271c8e6586 Author: Chao Yu Date: Wed Dec 16 17:15:23 2020 +0800 f2fs: fix out-of-repair __setattr_copy() commit 2562515f0ad7342bde6456602c491b64c63fe950 upstream. __setattr_copy() was copied from setattr_copy() in fs/attr.c, there is two missing patches doesn't cover this inner function, fix it. Commit 7fa294c8991c ("userns: Allow chown and setgid preservation") Commit 23adbe12ef7d ("fs,userns: Change inode_capable to capable_wrt_inode_uidgid") Fixes: fbfa2cc58d53 ("f2fs: add file operations") Cc: stable@vger.kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 58e3e3a7f939457930663474e05a799a255d8780 Author: Muchun Song Date: Wed Feb 10 11:48:23 2021 +0800 printk: fix deadlock when kernel panic commit 8a8109f303e25a27f92c1d8edd67d7cbbc60a4eb upstream. printk_safe_flush_on_panic() caused the following deadlock on our server: CPU0: CPU1: panic rcu_dump_cpu_stacks kdump_nmi_shootdown_cpus nmi_trigger_cpumask_backtrace register_nmi_handler(crash_nmi_callback) printk_safe_flush __printk_safe_flush raw_spin_lock_irqsave(&read_lock) // send NMI to other processors apic_send_IPI_allbutself(NMI_VECTOR) // NMI interrupt, dead loop crash_nmi_callback printk_safe_flush_on_panic printk_safe_flush __printk_safe_flush // deadlock raw_spin_lock_irqsave(&read_lock) DEADLOCK: read_lock is taken on CPU1 and will never get released. It happens when panic() stops a CPU by NMI while it has been in the middle of printk_safe_flush(). Handle the lock the same way as logbuf_lock. The printk_safe buffers are flushed only when both locks can be safely taken. It can avoid the deadlock _in this particular case_ at expense of losing contents of printk_safe buffers. Note: It would actually be safe to re-init the locks when all CPUs were stopped by NMI. But it would require passing this information from arch-specific code. It is not worth the complexity. Especially because logbuf_lock and printk_safe buffers have been obsoleted by the lockless ring buffer. Fixes: cf9b1106c81c ("printk/nmi: flush NMI messages on the system panic") Signed-off-by: Muchun Song Reviewed-by: Petr Mladek Cc: Acked-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210210034823.64867-1-songmuchun@bytedance.com Signed-off-by: Greg Kroah-Hartman commit 9c6ca2d4f1f8fe72741f4edea1cc9c5e811c4c9d Author: Maxim Kiselev Date: Wed Feb 17 14:10:00 2021 +0100 gpio: pcf857x: Fix missing first interrupt commit a8002a35935aaefcd6a42ad3289f62bab947f2ca upstream. If no n_latch value will be provided at driver probe then all pins will be used as an input: gpio->out = ~n_latch; In that case initial state for all pins is "one": gpio->status = gpio->out; So if pcf857x IRQ happens with change pin value from "zero" to "one" then we miss it, because of "one" from IRQ and "one" from initial state leaves corresponding pin unchanged: change = (gpio->status ^ status) & gpio->irq_enabled; The right solution will be to read actual state at driver probe. Cc: stable@vger.kernel.org Fixes: 6e20a0a429bd ("gpio: pcf857x: enable gpio_to_irq() support") Signed-off-by: Maxim Kiselev Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 6114593030b711311177126e4cae63278fde6b42 Author: Frank Li Date: Wed Feb 10 12:19:33 2021 -0600 mmc: sdhci-esdhc-imx: fix kernel panic when remove module commit a56f44138a2c57047f1ea94ea121af31c595132b upstream. In sdhci_esdhc_imx_remove() the SDHCI_INT_STATUS in read. Under some circumstances, this may be done while the device is runtime suspended, triggering the below splat. Fix the problem by adding a pm_runtime_get_sync(), before reading the register, which will turn on clocks etc making the device accessible again. [ 1811.323148] mmc1: card aaaa removed [ 1811.347483] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP [ 1811.354988] Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm sdhci cqhci mmc_block mmc_core [last unloaded: mmc_core] [ 1811.365726] CPU: 0 PID: 3464 Comm: rmmod Not tainted 5.10.1-sd-99871-g53835a2e8186 #5 [ 1811.373559] Hardware name: Freescale i.MX8DXL EVK (DT) [ 1811.378705] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 1811.384723] pc : sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx] [ 1811.391090] lr : platform_drv_remove+0x2c/0x50 [ 1811.395536] sp : ffff800012c7bcb0 [ 1811.398855] x29: ffff800012c7bcb0 x28: ffff00002c72b900 [ 1811.404181] x27: 0000000000000000 x26: 0000000000000000 [ 1811.409497] x25: 0000000000000000 x24: 0000000000000000 [ 1811.414814] x23: ffff0000042b3890 x22: ffff800009127120 [ 1811.420131] x21: ffff00002c4c9580 x20: ffff0000042d0810 [ 1811.425456] x19: ffff0000042d0800 x18: 0000000000000020 [ 1811.430773] x17: 0000000000000000 x16: 0000000000000000 [ 1811.436089] x15: 0000000000000004 x14: ffff000004019c10 [ 1811.441406] x13: 0000000000000000 x12: 0000000000000020 [ 1811.446723] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f [ 1811.452040] x9 : fefefeff6364626d x8 : 7f7f7f7f7f7f7f7f [ 1811.457356] x7 : 78725e6473607372 x6 : 0000000080808080 [ 1811.462673] x5 : 0000000000000000 x4 : 0000000000000000 [ 1811.467990] x3 : ffff800011ac1cb0 x2 : 0000000000000000 [ 1811.473307] x1 : ffff8000091214d4 x0 : ffff8000133a0030 [ 1811.478624] Call trace: [ 1811.481081] sdhci_esdhc_imx_remove+0x28/0x15c [sdhci_esdhc_imx] [ 1811.487098] platform_drv_remove+0x2c/0x50 [ 1811.491198] __device_release_driver+0x188/0x230 [ 1811.495818] driver_detach+0xc0/0x14c [ 1811.499487] bus_remove_driver+0x5c/0xb0 [ 1811.503413] driver_unregister+0x30/0x60 [ 1811.507341] platform_driver_unregister+0x14/0x20 [ 1811.512048] sdhci_esdhc_imx_driver_exit+0x1c/0x3a8 [sdhci_esdhc_imx] [ 1811.518495] __arm64_sys_delete_module+0x19c/0x230 [ 1811.523291] el0_svc_common.constprop.0+0x78/0x1a0 [ 1811.528086] do_el0_svc+0x24/0x90 [ 1811.531405] el0_svc+0x14/0x20 [ 1811.534461] el0_sync_handler+0x1a4/0x1b0 [ 1811.538474] el0_sync+0x174/0x180 [ 1811.541801] Code: a9025bf5 f9403e95 f9400ea0 9100c000 (b9400000) [ 1811.547902] ---[ end trace 3fb1a3bd48ff7be5 ]--- Signed-off-by: Frank Li Cc: stable@vger.kernel.org # v4.0+ Link: https://lore.kernel.org/r/20210210181933.29263-1-Frank.Li@nxp.com [Ulf: Clarified the commit message a bit] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 8e3ff5aa87ad4c317bb28fcebf2a8dbf672d4206 Author: Fangrui Song Date: Fri Jan 15 11:52:22 2021 -0800 module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols commit ebfac7b778fac8b0e8e92ec91d0b055f046b4604 upstream. clang-12 -fno-pic (since https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6) can emit `call __stack_chk_fail@PLT` instead of `call __stack_chk_fail` on x86. The two forms should have identical behaviors on x86-64 but the former causes GNU as<2.37 to produce an unreferenced undefined symbol _GLOBAL_OFFSET_TABLE_. (On x86-32, there is an R_386_PC32 vs R_386_PLT32 difference but the linker behavior is identical as far as Linux kernel is concerned.) Simply ignore _GLOBAL_OFFSET_TABLE_ for now, like what scripts/mod/modpost.c:ignore_undef_symbol does. This also fixes the problem for gcc/clang -fpie and -fpic, which may emit `call foo@PLT` for external function calls on x86. Note: ld -z defs and dynamic loaders do not error for unreferenced undefined symbols so the module loader is reading too much. If we ever need to ignore more symbols, the code should be refactored to ignore unreferenced symbols. Cc: Link: https://github.com/ClangBuiltLinux/linux/issues/1250 Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27178 Reported-by: Marco Elver Reviewed-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Tested-by: Marco Elver Signed-off-by: Fangrui Song Signed-off-by: Jessica Yu Signed-off-by: Greg Kroah-Hartman commit a7db24bcee1b8690ed78230cbf17500c1bf52943 Author: Dan Williams Date: Mon Feb 1 16:20:40 2021 -0800 libnvdimm/dimm: Avoid race between probe and available_slots_show() commit 7018c897c2f243d4b5f1b94bc6b4831a7eab80fb upstream Richard reports that the following test: (while true; do cat /sys/bus/nd/devices/nmem*/available_slots 2>&1 > /dev/null done) & while true; do for i in $(seq 0 4); do echo nmem$i > /sys/bus/nd/drivers/nvdimm/bind done for i in $(seq 0 4); do echo nmem$i > /sys/bus/nd/drivers/nvdimm/unbind done done ...fails with a crash signature like: divide error: 0000 [#1] SMP KASAN PTI RIP: 0010:nd_label_nfree+0x134/0x1a0 [libnvdimm] [..] Call Trace: available_slots_show+0x4e/0x120 [libnvdimm] dev_attr_show+0x42/0x80 ? memset+0x20/0x40 sysfs_kf_seq_show+0x218/0x410 The root cause is that available_slots_show() consults driver-data, but fails to synchronize against device-unbind setting up a TOCTOU race to access uninitialized memory. Validate driver-data under the device-lock. Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure") Cc: Cc: Vishal Verma Cc: Dave Jiang Cc: Ira Weiny Cc: Coly Li Reported-by: Richard Palethorpe Acked-by: Richard Palethorpe Signed-off-by: Dan Williams [sudip: use device_lock()] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit fd9a5ca4df2ce459787db0249ac6b4896766e9c5 Author: Yoshihiro Shimoda Date: Mon Feb 1 21:47:20 2021 +0900 usb: renesas_usbhs: Clear pipe running flag in usbhs_pkt_pop() commit 9917f0e3cdba7b9f1a23f70e3f70b1a106be54a8 upstream Should clear the pipe running flag in usbhs_pkt_pop(). Otherwise, we cannot use this pipe after dequeue was called while the pipe was running. Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle") Reported-by: Tho Vu Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/1612183640-8898-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Cc: stable Signed-off-by: Greg Kroah-Hartman [sudip: adjust context] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 8be16169cd664157023ad4391a494f13dc52c96d Author: Muchun Song Date: Thu Feb 4 18:32:06 2021 -0800 mm: hugetlb: fix a race between freeing and dissolving the page commit 7ffddd499ba6122b1a07828f023d1d67629aa017 upstream There is a race condition between __free_huge_page() and dissolve_free_huge_page(). CPU0: CPU1: // page_count(page) == 1 put_page(page) __free_huge_page(page) dissolve_free_huge_page(page) spin_lock(&hugetlb_lock) // PageHuge(page) && !page_count(page) update_and_free_page(page) // page is freed to the buddy spin_unlock(&hugetlb_lock) spin_lock(&hugetlb_lock) clear_page_huge_active(page) enqueue_huge_page(page) // It is wrong, the page is already freed spin_unlock(&hugetlb_lock) The race window is between put_page() and dissolve_free_huge_page(). We should make sure that the page is already on the free list when it is dissolved. As a result __free_huge_page would corrupt page(s) already in the buddy allocator. Link: https://lkml.kernel.org/r/20210115124942.46403-4-songmuchun@bytedance.com Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage") Signed-off-by: Muchun Song Reviewed-by: Mike Kravetz Reviewed-by: Oscar Salvador Acked-by: Michal Hocko Cc: David Hildenbrand Cc: Yang Shi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [sudip: adjust context] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 597a02e42c1337620fcf7ffe03749bfb8b7535c9 Author: Mike Kravetz Date: Wed Feb 24 12:07:54 2021 -0800 hugetlb: fix copy_huge_page_from_user contig page struct assumption commit 3272cfc2525b3a2810a59312d7a1e6f04a0ca3ef upstream. page structs are not guaranteed to be contiguous for gigantic pages. The routine copy_huge_page_from_user can encounter gigantic pages, yet it assumes page structs are contiguous when copying pages from user space. Since page structs for the target gigantic page are not contiguous, the data copied from user space could overwrite other pages not associated with the gigantic page and cause data corruption. Non-contiguous page structs are generally not an issue. However, they can exist with a specific kernel configuration and hotplug operations. For example: Configure the kernel with CONFIG_SPARSEMEM and !CONFIG_SPARSEMEM_VMEMMAP. Then, hotplug add memory for the area where the gigantic page will be allocated. Link: https://lkml.kernel.org/r/20210217184926.33567-2-mike.kravetz@oracle.com Fixes: 8fb5debc5fcd ("userfaultfd: hugetlbfs: add hugetlb_mcopy_atomic_pte for userfaultfd support") Signed-off-by: Mike Kravetz Cc: Zi Yan Cc: Davidlohr Bueso Cc: "Kirill A . Shutemov" Cc: Andrea Arcangeli Cc: Matthew Wilcox Cc: Oscar Salvador Cc: Joao Martins Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9c9245912c91dde361a1e2e26900f5baeb14d3eb Author: Pan Bian Date: Wed Jan 20 00:51:13 2021 -0800 fs/affs: release old buffer head on error path commit 70779b897395b330ba5a47bed84f94178da599f9 upstream. The reference count of the old buffer head should be decremented on path that fails to get the new buffer head. Fixes: 6b4657667ba0 ("fs/affs: add rename exchange") CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Pan Bian Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 112534dc1eba5b6965b594e0c78482b795e630d3 Author: Pan Bian Date: Thu Jan 21 01:18:47 2021 -0800 mtd: spi-nor: hisi-sfc: Put child node np on error path commit fe6653460ee7a7dbe0cd5fd322992af862ce5ab0 upstream. Put the child node np when it fails to get or register device. Fixes: e523f11141bd ("mtd: spi-nor: add hisilicon spi-nor flash controller driver") Cc: stable@vger.kernel.org Signed-off-by: Pan Bian [ta: Add Fixes tag and Cc stable] Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20210121091847.85362-1-bianpan2016@163.com Signed-off-by: Greg Kroah-Hartman commit 494be89f67059787ef637629a3f2dbe3af0cb3b5 Author: Alexander Usyskin Date: Sun Jan 24 13:49:38 2021 +0200 watchdog: mei_wdt: request stop on unregister commit 740c0a57b8f1e36301218bf549f3c9cc833a60be upstream. The MEI bus has a special behavior on suspend it destroys all the attached devices, this is due to the fact that also firmware context is not persistent across power flows. If watchdog on MEI bus is ticking before suspending the firmware times out and reports that the OS is missing watchdog tick. Send the stop command to the firmware on watchdog unregistered to eliminate the false event on suspend. This does not make the things worse from the user-space perspective as a user-space should re-open watchdog device after suspending before this patch. Cc: Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20210124114938.373885-1-tomas.winkler@intel.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit ebd65a917eef4859e0067af20d837dfa9e9b6534 Author: He Zhe Date: Tue Feb 23 16:25:34 2021 +0800 arm64: uprobe: Return EOPNOTSUPP for AARCH32 instruction probing commit d47422d953e258ad587b5edf2274eb95d08bdc7d upstream. As stated in linux/errno.h, ENOTSUPP should never be seen by user programs. When we set up uprobe with 32-bit perf and arm64 kernel, we would see the following vague error without useful hint. The sys_perf_event_open() syscall returned with 524 (INTERNAL ERROR: strerror_r(524, [buf], 128)=22) Use EOPNOTSUPP instead to indicate such cases. Signed-off-by: He Zhe Link: https://lore.kernel.org/r/20210223082535.48730-1-zhe.he@windriver.com Cc: Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 3dea563626c5b464b7305c882f2809915030c134 Author: Jiri Kosina Date: Fri Jan 22 12:13:20 2021 +0100 floppy: reintroduce O_NDELAY fix commit 8a0c014cd20516ade9654fc13b51345ec58e7be8 upstream. This issue was originally fixed in 09954bad4 ("floppy: refactor open() flags handling"). The fix as a side-effect, however, introduce issue for open(O_ACCMODE) that is being used for ioctl-only open. I wrote a fix for that, but instead of it being merged, full revert of 09954bad4 was performed, re-introducing the O_NDELAY / O_NONBLOCK issue, and it strikes again. This is a forward-port of the original fix to current codebase; the original submission had the changelog below: ==== Commit 09954bad4 ("floppy: refactor open() flags handling"), as a side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that this is being used setfdprm userspace for ioctl-only open(). Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE) modes, while still keeping the original O_NDELAY bug fixed. Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2101221209060.5622@cbobk.fhfr.pm Cc: stable@vger.kernel.org Reported-by: Wim Osterholt Tested-by: Wim Osterholt Reported-and-tested-by: Kurt Garloff Fixes: 09954bad4 ("floppy: refactor open() flags handling") Fixes: f2791e7ead ("Revert "floppy: refactor open() flags handling"") Signed-off-by: Jiri Kosina Signed-off-by: Denis Efremov Signed-off-by: Greg Kroah-Hartman commit 40e09c567e6551dbca8ae0f9f488178fe40bbe4d Author: Sean Christopherson Date: Wed Dec 30 16:26:55 2020 -0800 x86/reboot: Force all cpus to exit VMX root if VMX is supported commit ed72736183c45a413a8d6974dd04be90f514cb6b upstream. Force all CPUs to do VMXOFF (via NMI shootdown) during an emergency reboot if VMX is _supported_, as VMX being off on the current CPU does not prevent other CPUs from being in VMX root (post-VMXON). This fixes a bug where a crash/panic reboot could leave other CPUs in VMX root and prevent them from being woken via INIT-SIPI-SIPI in the new kernel. Fixes: d176720d34c7 ("x86: disable VMX on all CPUs on reboot") Cc: stable@vger.kernel.org Suggested-by: Sean Christopherson Signed-off-by: David P. Reed [sean: reworked changelog and further tweaked comment] Signed-off-by: Sean Christopherson Message-Id: <20201231002702.2223707-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 334981701c4289b0a36156efabc32a777737462e Author: Martin Kaiser Date: Thu Feb 4 09:52:17 2021 +0100 staging: rtl8188eu: Add Edimax EW-7811UN V2 to device table commit 7a8d2f1908a59003e55ef8691d09efb7fbc51625 upstream. The Edimax EW-7811UN V2 uses an RTL8188EU chipset and works with this driver. Signed-off-by: Martin Kaiser Cc: stable Link: https://lore.kernel.org/r/20210204085217.9743-1-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman commit bd95c8db6b8e74623a1787335a8bfb5e1940e886 Author: Sabyrzhan Tasbolatov Date: Tue Feb 9 16:26:12 2021 +0600 drivers/misc/vmw_vmci: restrict too big queue size in qp_host_alloc_queue commit 2fd10bcf0310b9525b2af9e1f7aa9ddd87c3772e upstream. syzbot found WARNING in qp_broker_alloc[1] in qp_host_alloc_queue() when num_pages is 0x100001, giving queue_size + queue_page_size bigger than KMALLOC_MAX_SIZE for kzalloc(), resulting order >= MAX_ORDER condition. queue_size + queue_page_size=0x8000d8, where KMALLOC_MAX_SIZE=0x400000. [1] Call Trace: alloc_pages include/linux/gfp.h:547 [inline] kmalloc_order+0x40/0x130 mm/slab_common.c:837 kmalloc_order_trace+0x15/0x70 mm/slab_common.c:853 kmalloc_large include/linux/slab.h:481 [inline] __kmalloc+0x257/0x330 mm/slub.c:3959 kmalloc include/linux/slab.h:557 [inline] kzalloc include/linux/slab.h:682 [inline] qp_host_alloc_queue drivers/misc/vmw_vmci/vmci_queue_pair.c:540 [inline] qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1351 [inline] qp_broker_alloc+0x936/0x2740 drivers/misc/vmw_vmci/vmci_queue_pair.c:1739 Reported-by: syzbot+15ec7391f3d6a1a7cc7d@syzkaller.appspotmail.com Signed-off-by: Sabyrzhan Tasbolatov Link: https://lore.kernel.org/r/20210209102612.2112247-1-snovitoll@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 44ae9254ce7a50b565f7699d5059effc0476eb50 Author: Paul Cercueil Date: Mon Jan 11 17:28:39 2021 +0000 seccomp: Add missing return in non-void function commit 04b38d012556199ba4c31195940160e0c44c64f0 upstream. We don't actually care about the value, since the kernel will panic before that; but a value should nonetheless be returned, otherwise the compiler will complain. Fixes: 8112c4f140fa ("seccomp: remove 2-phase API") Cc: stable@vger.kernel.org # 4.7+ Signed-off-by: Paul Cercueil Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210111172839.640914-1-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman commit e398b74730437ba71abbd6500ad13ade3dd22352 Author: Corentin Labbe Date: Mon Dec 14 20:02:28 2020 +0000 crypto: sun4i-ss - handle BigEndian for cipher commit 5ab6177fa02df15cd8a02a1f1fb361d2d5d8b946 upstream. Ciphers produce invalid results on BE. Key and IV need to be written in LE. Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Cc: Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e11a57b6c9da9b5b13dfbb6be18e472932d1acff Author: Corentin Labbe Date: Mon Dec 14 20:02:26 2020 +0000 crypto: sun4i-ss - checking sg length is not sufficient commit 7bdcd851fa7eb66e8922aa7f6cba9e2f2427a7cf upstream. The optimized cipher function need length multiple of 4 bytes. But it get sometimes odd length. This is due to SG data could be stored with an offset. So the fix is to check also if the offset is aligned with 4 bytes. Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Cc: Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 335241c0d985666b25761cb98c1468613af67117 Author: Filipe Manana Date: Thu Feb 4 14:35:44 2021 +0000 btrfs: fix extent buffer leak on failure to copy root commit 72c9925f87c8b74f36f8e75a4cd93d964538d3ca upstream. At btrfs_copy_root(), if the call to btrfs_inc_ref() fails we end up returning without unlocking and releasing our reference on the extent buffer named "cow" we previously allocated with btrfs_alloc_tree_block(). So fix that by unlocking the extent buffer and dropping our reference on it before returning. Fixes: be20aa9dbadc8c ("Btrfs: Add mount option to turn off data cow") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 605689701f3b347f45baedec65162c2f778a4eb7 Author: Josef Bacik Date: Thu Jan 14 14:02:42 2021 -0500 btrfs: fix reloc root leak with 0 ref reloc roots on recovery commit c78a10aebb275c38d0cfccae129a803fe622e305 upstream. When recovering a relocation, if we run into a reloc root that has 0 refs we simply add it to the reloc_control->reloc_roots list, and then clean it up later. The problem with this is __del_reloc_root() doesn't do anything if the root isn't in the radix tree, which in this case it won't be because we never call __add_reloc_root() on the reloc_root. This exit condition simply isn't correct really. During normal operation we can remove ourselves from the rb tree and then we're meant to clean up later at merge_reloc_roots() time, and this happens correctly. During recovery we're depending on free_reloc_roots() to drop our references, but we're short-circuiting. Fix this by continuing to check if we're on the list and dropping ourselves from the reloc_control root list and dropping our reference appropriately. Change the corresponding BUG_ON() to an ASSERT() that does the correct thing if we aren't in the rb tree. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 338ad043a5909d78be3a313339ea4417f5fdd38c Author: Josef Bacik Date: Thu Jan 14 14:02:46 2021 -0500 btrfs: abort the transaction if we fail to inc ref in btrfs_copy_root commit 867ed321f90d06aaba84e2c91de51cd3038825ef upstream. While testing my error handling patches, I added a error injection site at btrfs_inc_extent_ref, to validate the error handling I added was doing the correct thing. However I hit a pretty ugly corruption while doing this check, with the following error injection stack trace: btrfs_inc_extent_ref btrfs_copy_root create_reloc_root btrfs_init_reloc_root btrfs_record_root_in_trans btrfs_start_transaction btrfs_update_inode btrfs_update_time touch_atime file_accessed btrfs_file_mmap This is because we do not catch the error from btrfs_inc_extent_ref, which in practice would be ENOMEM, which means we lose the extent references for a root that has already been allocated and inserted, which is the problem. Fix this by aborting the transaction if we fail to do the reference modification. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5bbec09f881ac2e19685efa3f18b704043afcede Author: Jarkko Sakkinen Date: Fri Jan 29 01:56:20 2021 +0200 KEYS: trusted: Fix migratable=1 failing commit 8da7520c80468c48f981f0b81fc1be6599e3b0ad upstream. Consider the following transcript: $ keyctl add trusted kmk "new 32 blobauth=helloworld keyhandle=80000000 migratable=1" @u add_key: Invalid argument The documentation has the following description: migratable= 0|1 indicating permission to reseal to new PCR values, default 1 (resealing allowed) The consequence is that "migratable=1" should succeed. Fix this by allowing this condition to pass instead of return -EINVAL. [*] Documentation/security/keys/trusted-encrypted.rst Cc: stable@vger.kernel.org Cc: "James E.J. Bottomley" Cc: Mimi Zohar Cc: David Howells Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 7ba5ff552d4b4c81c6fff81f41954e27a6468aa1 Author: James Bottomley Date: Thu Oct 1 11:09:21 2020 -0700 tpm_tis: Fix check_locality for correct locality acquisition commit 3d9ae54af1d02a7c0edc55c77d7df2b921e58a87 upstream. The TPM TIS specification says the TPM signals the acquisition of locality when the TMP_ACCESS_REQUEST_USE bit goes to one *and* the TPM_ACCESS_REQUEST_USE bit goes to zero. Currently we only check the former not the latter, so check both. Adding the check on TPM_ACCESS_REQUEST_USE should fix the case where the locality is re-requested before the TPM has released it. In this case the locality may get released briefly before it is reacquired, which causes all sorts of problems. However, with the added check, TPM_ACCESS_REQUEST_USE should remain 1 until the second request for the locality is granted. Cc: stable@ger.kernel.org Fixes: 27084efee0c3 ("[PATCH] tpm: driver for next generation TPM chips") Signed-off-by: James Bottomley Reviewed-by: Jerry Snitselaar Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 47476d3903d6796bbcd997a141807f425f49acd5 Author: PeiSen Hou Date: Tue Feb 2 10:30:22 2021 +0100 ALSA: hda/realtek: modify EAPD in the ALC886 commit 4841b8e6318a7f0ae57c4e5ec09032ea057c97a8 upstream. Modify 0x20 index 7 bit 5 to 1, make the 0x15 EAPD the same as 0x14. Signed-off-by: PeiSen Hou Cc: Link: https://lore.kernel.org/r/e62c5058957f48d8b8953e97135ff108@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 415cfe556a63b01852b63a30431b749e9d6733ff Author: Thinh Nguyen Date: Mon Feb 8 13:53:16 2021 -0800 usb: dwc3: gadget: Fix dep->interval for fullspeed interrupt commit 4b049f55ed95cd889bcdb3034fd75e1f01852b38 upstream. The dep->interval captures the number of frames/microframes per interval from bInterval. Fullspeed interrupt endpoint bInterval is the number of frames per interval and not 2^(bInterval - 1). So fix it here. This change is only for debugging purpose and should not affect the interrupt endpoint operation. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/1263b563dedc4ab8b0fb854fba06ce4bc56bd495.1612820995.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit f323b51938668fbee4ab85a591ae439a7bcb2fe1 Author: Thinh Nguyen Date: Mon Feb 8 13:53:10 2021 -0800 usb: dwc3: gadget: Fix setting of DEPCFG.bInterval_m1 commit a1679af85b2ae35a2b78ad04c18bb069c37330cc upstream. Valid range for DEPCFG.bInterval_m1 is from 0 to 13, and it must be set to 0 when the controller operates in full-speed. See the programming guide for DEPCFG command section 3.2.2.1 (v3.30a). Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/3f57026f993c0ce71498dbb06e49b3a47c4d0265.1612820995.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 5abbfbe0da0fe639422cad710ef190ad012bcd78 Author: Dan Carpenter Date: Thu Jan 28 12:35:23 2021 +0300 USB: serial: mos7720: fix error code in mos7720_write() commit fea7372cbc40869876df0f045e367f6f97a1666c upstream. This code should return -ENOMEM if the kmalloc() fails but instead it returns success. Signed-off-by: Dan Carpenter Fixes: 0f64478cbc7a ("USB: add USB serial mos7720 driver") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 3f5bbe24acc4bd29832c3e4c77594d28590c70da Author: Dan Carpenter Date: Tue Jan 26 13:26:54 2021 +0300 USB: serial: mos7840: fix error code in mos7840_write() commit a70aa7dc60099bbdcbd6faca42a915d80f31161e upstream. This should return -ENOMEM instead of 0 if the kmalloc() fails. Fixes: 3f5429746d91 ("USB: Moschip 7840 USB-Serial Driver") Signed-off-by: Dan Carpenter Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 68deb52948e1bde0c951e1fa842c8426d0088e2d Author: Paul Cercueil Date: Sat Jan 23 14:24:59 2021 +0000 usb: musb: Fix runtime PM race in musb_queue_resume_work commit 0eaa1a3714db34a59ce121de5733c3909c529463 upstream. musb_queue_resume_work() would call the provided callback if the runtime PM status was 'active'. Otherwise, it would enqueue the request if the hardware was still suspended (musb->is_runtime_suspended is true). This causes a race with the runtime PM handlers, as it is possible to be in the case where the runtime PM status is not yet 'active', but the hardware has been awaken (PM resume function has been called). When hitting the race, the resume work was not enqueued, which probably triggered other bugs further down the stack. For instance, a telnet connection on Ingenic SoCs would result in a 50/50 chance of a segmentation fault somewhere in the musb code. Rework the code so that either we call the callback directly if (musb->is_runtime_suspended == 0), or enqueue the query otherwise. Fixes: ea2f35c01d5e ("usb: musb: Fix sleeping function called from invalid context for hdrc glue") Cc: stable@vger.kernel.org # v4.9+ Tested-by: Tony Lindgren Reviewed-by: Tony Lindgren Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20210123142502.16980-1-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman commit 107faef1dc2fd593472609ad21b0ef7152986def Author: Lech Perczak Date: Sun Feb 7 01:54:43 2021 +0100 USB: serial: option: update interface mapping for ZTE P685M commit 6420a569504e212d618d4a4736e2c59ed80a8478 upstream. This patch prepares for qmi_wwan driver support for the device. Previously "option" driver mapped itself to interfaces 0 and 3 (matching ff/ff/ff), while interface 3 is in fact a QMI port. Interfaces 1 and 2 (matching ff/00/00) expose AT commands, and weren't supported previously at all. Without this patch, a possible conflict would exist if device ID was added to qmi_wwan driver for interface 3. Update and simplify device ID to match interfaces 0-2 directly, to expose QCDM (0), PCUI (1), and modem (2) ports and avoid conflict with QMI (3), and ADB (4). The modem is used inside ZTE MF283+ router and carriers identify it as such. Interface mapping is: 0: QCDM, 1: AT (PCUI), 2: AT (Modem), 3: QMI, 4: ADB T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=1275 Rev=f0.00 S: Manufacturer=ZTE,Incorporated S: Product=ZTE Technologies MSM S: SerialNumber=P685M510ZTED0000CP&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&0 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=87(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: Johan Hovold Cc: Bjørn Mork Signed-off-by: Lech Perczak Link: https://lore.kernel.org/r/20210207005443.12936-1-lech.perczak@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit fe8723646063f92479f920a486e50b4d50b28e40 Author: Marcos Paulo de Souza Date: Fri Feb 19 10:37:13 2021 -0800 Input: i8042 - add ASUS Zenbook Flip to noselftest list commit b5d6e7ab7fe7d186878142e9fc1a05e4c3b65eb9 upstream. After commit 77b425399f6d ("Input: i8042 - use chassis info to skip selftest on Asus laptops"), all modern Asus laptops have the i8042 selftest disabled. It has done by using chassys type "10" (laptop). The Asus Zenbook Flip suffers from similar suspend/resume issues, but it _sometimes_ work and sometimes it doesn't. Setting noselftest makes it work reliably. In this case, we need to add chassis type "31" (convertible) in order to avoid selftest in this device. Reported-by: Ludvig Norgren Guldhag Signed-off-by: Marcos Paulo de Souza Link: https://lore.kernel.org/r/20210219164638.761-1-mpdesouza@suse.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d4b7440883871cbcaf6c1cd95a76048a86b005c7 Author: Dan Carpenter Date: Wed Feb 17 12:21:10 2021 -0800 Input: joydev - prevent potential read overflow in ioctl commit 182d679b2298d62bf42bb14b12a8067b8e17b617 upstream. The problem here is that "len" might be less than "joydev->nabs" so the loops which verfy abspam[i] and keypam[] might read beyond the buffer. Fixes: 999b874f4aa3 ("Input: joydev - validate axis/button maps before clobbering current ones") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YCyzR8WvFRw4HWw6@mwanda [dtor: additional check for len being even in joydev_handle_JSIOCSBTNMAP] Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1d79ad8ec2fc4c9a83acf8e19d3519d682a0c5f4 Author: Olivier Crête Date: Fri Feb 5 11:59:08 2021 -0800 Input: xpad - add support for PowerA Enhanced Wired Controller for Xbox Series X|S commit 42ffcd1dba1796bcda386eb6f260df9fc23c90af upstream. Signed-off-by: Olivier Crête Link: https://lore.kernel.org/r/20210204005318.615647-1-olivier.crete@collabora.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 011d22989439fb48ff36b5e208a88345da1aa4e1 Author: jeffrey.lin Date: Tue Dec 15 10:50:12 2020 -0800 Input: raydium_ts_i2c - do not send zero length commit fafd320ae51b9c72d371585b2501f86640ea7b7d upstream. Add default write command package to prevent i2c quirk error of zero data length as Raydium touch firmware update is executed. Signed-off-by: jeffrey.lin Link: https://lore.kernel.org/r/1608031217-7247-1-git-send-email-jeffrey.lin@raydium.corp-partner.google.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 91f3d5e5b6efacfb39a0485e2b4b00bf034c4c48 Author: Jason Gerecke Date: Tue Feb 16 11:41:54 2021 -0800 HID: wacom: Ignore attempts to overwrite the touch_max value from HID commit 88f38846bfb1a452a3d47e38aeab20a4ceb74294 upstream. The `wacom_feature_mapping` function is careful to only set the the touch_max value a single time, but this care does not extend to the `wacom_wac_finger_event` function. In particular, if a device sends multiple HID_DG_CONTACTMAX items in a single feature report, the driver will end up retaining the value of last item. The HID descriptor for the Cintiq Companion 2 does exactly this. It incorrectly sets a "Report Count" of 2, which will cause the driver to process two HID_DG_CONTACTCOUNT items. The first item has the actual count, while the second item should have been declared as a constant zero. The constant zero is the value the driver ends up using, however, since it is the last HID_DG_CONTACTCOUNT in the report. Report ID (16), Usage (Contact Count Maximum), ; Contact count maximum (55h, static value) Report Count (2), Logical Maximum (10), Feature (Variable), To address this, we add a check that the touch_max is not already set within the `wacom_wac_finger_event` function that processes the HID_DG_TOUCHMAX item. We emit a warning if the value is set and ignore the updated value. This could potentially cause problems if there is a tablet which has a similar issue but requires the last item to be used. This is unlikely, however, since it would have to have a different non-zero value for HID_DG_CONTACTMAX earlier in the same report, which makes no sense except in the case of a firmware bug. Note that cases where the HID_DG_CONTACTMAX items are in different reports is already handled (and similarly ignored) by `wacom_feature_mapping` as mentioned above. Link: https://github.com/linuxwacom/input-wacom/issues/223 Fixes: 184eccd40389 ("HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report") Signed-off-by: Jason Gerecke CC: stable@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit f598593ad5bbc5ded9ca54bd93212cbf7778ef44 Author: Qinglang Miao Date: Fri Jan 15 10:22:50 2021 +0800 ACPI: configfs: add missing check after configfs_register_default_group() commit 67e40054de86aae520ddc2a072d7f6951812a14f upstream. A list_add corruption is reported by Hulk Robot like this: ============== list_add corruption. Call Trace: link_obj+0xc0/0x1c0 link_group+0x21/0x140 configfs_register_subsystem+0xdb/0x380 acpi_configfs_init+0x25/0x1000 [acpi_configfs] do_one_initcall+0x149/0x820 do_init_module+0x1ef/0x720 load_module+0x35c8/0x4380 __do_sys_finit_module+0x10d/0x1a0 do_syscall_64+0x34/0x80 It's because of the missing check after configfs_register_default_group, where configfs_unregister_subsystem should be called once failure. Fixes: 612bd01fc6e0 ("ACPI: add support for loading SSDTs via configfs") Reported-by: Hulk Robot Suggested-by: Hanjun Guo Signed-off-by: Qinglang Miao Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit d525c395e7067ca1dca4eb807674cbb7b925b2db Author: Rafael J. Wysocki Date: Thu Feb 11 19:30:01 2021 +0100 ACPI: property: Fix fwnode string properties matching commit e1e6bd2995ac0e1ad0c2a2d906a06f59ce2ed293 upstream. Property matching does not work for ACPI fwnodes if the value of the given property is not represented as a package in the _DSD package containing it. For example, the "compatible" property in the _DSD below Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"compatible", "ethernet-phy-ieee802.3-c45"} } }) will not be found by fwnode_property_match_string(), because the ACPI code handling device properties does not regard the single value as a "list" in that case. Namely, fwnode_property_match_string() invoked to match a given string property value first calls fwnode_property_read_string_array() with the last two arguments equal to NULL and 0, respectively, in order to count the items in the value of the given property, with the assumption that this value may be an array. For ACPI fwnodes, that operation is carried out by acpi_node_prop_read() which calls acpi_data_prop_read() for this purpose. However, when the return (val) pointer is NULL, that function only looks for a property whose value is a package without checking the single-value case at all. To fix that, make acpi_data_prop_read() check the single-value case if its return pointer argument is NULL and modify acpi_data_prop_read_single() handling that case to attempt to read the value of the property if the return pointer is NULL and return 1 if that succeeds. Fixes: 3708184afc77 ("device property: Move FW type specific functionality to FW specific files") Reported-by: Calvin Johnson Cc: 4.13+ # 4.13+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Sakari Ailus Reviewed-by: Mika Westerberg Reviewed-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 736437a741fca2d92af0833c5647c509d57deb0d Author: Mikulas Patocka Date: Tue Feb 23 19:25:30 2021 -0700 blk-settings: align max_sectors on "logical_block_size" boundary commit 97f433c3601a24d3513d06f575a389a2ca4e11e4 upstream. We get I/O errors when we run md-raid1 on the top of dm-integrity on the top of ramdisk. device-mapper: integrity: Bio not aligned on 8 sectors: 0xff00, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0xff00, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0xffff, 0x1 device-mapper: integrity: Bio not aligned on 8 sectors: 0xffff, 0x1 device-mapper: integrity: Bio not aligned on 8 sectors: 0x8048, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0x8147, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0x8246, 0xff device-mapper: integrity: Bio not aligned on 8 sectors: 0x8345, 0xbb The ramdisk device has logical_block_size 512 and max_sectors 255. The dm-integrity device uses logical_block_size 4096 and it doesn't affect the "max_sectors" value - thus, it inherits 255 from the ramdisk. So, we have a device with max_sectors not aligned on logical_block_size. The md-raid device sees that the underlying leg has max_sectors 255 and it will split the bios on 255-sector boundary, making the bios unaligned on logical_block_size. In order to fix the bug, we round down max_sectors to logical_block_size. Cc: stable@vger.kernel.org Reviewed-by: Ming Lei Signed-off-by: Mikulas Patocka Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9b296d137cbf3c45b05b1c6807bd5438b6b3b439 Author: Randy Dunlap Date: Sat Feb 13 11:24:28 2021 -0800 scsi: bnx2fc: Fix Kconfig warning & CNIC build errors [ Upstream commit eefb816acb0162e94a85a857f3a55148f671d5a5 ] CNIC depends on MMU, but since 'select' does not follow any dependency chains, SCSI_BNX2X_FCOE also needs to depend on MMU, so that erroneous configs are not generated, which cause build errors in cnic. WARNING: unmet direct dependencies detected for CNIC Depends on [n]: NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_BROADCOM [=y] && PCI [=y] && (IPV6 [=n] || IPV6 [=n]=n) && MMU [=n] Selected by [y]: - SCSI_BNX2X_FCOE [=y] && SCSI_LOWLEVEL [=y] && SCSI [=y] && PCI [=y] && (IPV6 [=n] || IPV6 [=n]=n) && LIBFC [=y] && LIBFCOE [=y] riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L154': cnic.c:(.text+0x1094): undefined reference to `uio_event_notify' riscv64-linux-ld: cnic.c:(.text+0x10bc): undefined reference to `uio_event_notify' riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L1442': cnic.c:(.text+0x96a8): undefined reference to `__uio_register_device' riscv64-linux-ld: drivers/net/ethernet/broadcom/cnic.o: in function `.L0 ': cnic.c:(.text.unlikely+0x68): undefined reference to `uio_unregister_device' Link: https://lore.kernel.org/r/20210213192428.22537-1-rdunlap@infradead.org Fixes: 853e2bd2103a ("[SCSI] bnx2fc: Broadcom FCoE offload driver") Cc: Saurav Kashyap Cc: Javed Hasan Cc: GR-QLogic-Storage-Upstream@marvell.com Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: linux-scsi@vger.kernel.org Reported-by: kernel test robot Signed-off-by: Randy Dunlap Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 843fadf8f2b0ae4f0aa79ac0807f974ca750cf0c Author: Miaohe Lin Date: Thu Feb 25 17:18:09 2021 -0800 mm/rmap: fix potential pte_unmap on an not mapped pte [ Upstream commit 5d5d19eda6b0ee790af89c45e3f678345be6f50f ] For PMD-mapped page (usually THP), pvmw->pte is NULL. For PTE-mapped THP, pvmw->pte is mapped. But for HugeTLB pages, pvmw->pte is not mapped and set to the relevant page table entry. So in page_vma_mapped_walk_done(), we may do pte_unmap() for HugeTLB pte which is not mapped. Fix this by checking pvmw->page against PageHuge before trying to do pte_unmap(). Link: https://lkml.kernel.org/r/20210127093349.39081-1-linmiaohe@huawei.com Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()") Signed-off-by: Hongxiang Lou Signed-off-by: Miaohe Lin Tested-by: Sedat Dilek Cc: Kees Cook Cc: Nathan Chancellor Cc: Mike Kravetz Cc: Shakeel Butt Cc: Johannes Weiner Cc: Vlastimil Babka Cc: Michel Lespinasse Cc: Nick Desaulniers Cc: "Kirill A. Shutemov" Cc: Wei Yang Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Brian Geffon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4ac0d31a1f0bd7b3ec91452f1df24fc459c0438d Author: Maxime Ripard Date: Thu Feb 25 17:11:01 2021 +0100 i2c: brcmstb: Fix brcmstd_send_i2c_cmd condition [ Upstream commit a1858ce0cfe31368b23ba55794e409fb57ced4a4 ] The brcmstb_send_i2c_cmd currently has a condition that is (CMD_RD || CMD_WR) which always evaluates to true, while the obvious fix is to test whether the cmd variable passed as parameter holds one of these two values. Fixes: dd1aa2524bc5 ("i2c: brcmstb: Add Broadcom settop SoC i2c controller driver") Reported-by: Dave Stevenson Signed-off-by: Maxime Ripard Acked-by: Florian Fainelli Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 9d0305928c8037effb702abec99f500c73b7eea6 Author: Marc Zyngier Date: Wed Feb 24 09:37:37 2021 +0000 arm64: Add missing ISB after invalidating TLB in __primary_switch [ Upstream commit 9d41053e8dc115c92b8002c3db5f545d7602498b ] Although there has been a bit of back and forth on the subject, it appears that invalidating TLBs requires an ISB instruction when FEAT_ETS is not implemented by the CPU. From the bible: | In an implementation that does not implement FEAT_ETS, a TLB | maintenance instruction executed by a PE, PEx, can complete at any | time after it is issued, but is only guaranteed to be finished for a | PE, PEx, after the execution of DSB by the PEx followed by a Context | synchronization event Add the missing ISB in __primary_switch, just in case. Fixes: 3c5e9f238bc4 ("arm64: head.S: move KASLR processing out of __enable_mmu()") Suggested-by: Will Deacon Signed-off-by: Marc Zyngier Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20210224093738.3629662-3-maz@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 3da9eadf6172ce67fe5260cf7cdb96dcdd8ec107 Author: Miaohe Lin Date: Wed Feb 24 12:06:50 2021 -0800 mm/hugetlb: fix potential double free in hugetlb_register_node() error path [ Upstream commit cc2205a67dec5a700227a693fc113441e73e4641 ] In hugetlb_sysfs_add_hstate(), we would do kobject_put() on hstate_kobjs when failed to create sysfs group but forget to set hstate_kobjs to NULL. Then in hugetlb_register_node() error path, we may free it again via hugetlb_unregister_node(). Link: https://lkml.kernel.org/r/20210107123249.36964-1-linmiaohe@huawei.com Fixes: a3437870160c ("hugetlb: new sysfs interface") Signed-off-by: Miaohe Lin Reviewed-by: Mike Kravetz Reviewed-by: Muchun Song Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ff1dcb760d0f43eaed5782788eac95b83961fa5d Author: Miaohe Lin Date: Wed Feb 24 12:04:33 2021 -0800 mm/memory.c: fix potential pte_unmap_unlock pte error [ Upstream commit 90a3e375d324b2255b83e3dd29e99e2b05d82aaf ] Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed, we would break the loop with pte unchanged. Then the wrong pte - 1 would be passed to pte_unmap_unlock. Andi said: "While the fix is correct, I'm not sure if it actually is a real bug. Is there any architecture that would do something else than unlocking the underlying page? If it's just the underlying page then it should be always the same page, so no bug" Link: https://lkml.kernel.org/r/20210109080118.20885-1-linmiaohe@huawei.com Fixes: 42e4089c789 ("x86/speculation/l1tf: Disallow non privileged high MMIO PROT_NONE mappings") Signed-off-by: Hongxiang Lou Signed-off-by: Miaohe Lin Cc: Thomas Gleixner Cc: Dave Hansen Cc: Andi Kleen Cc: Josh Poimboeuf Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5813c03b80b20d72d95efa8fde35207da26c161f Author: Dan Carpenter Date: Wed Feb 24 12:00:41 2021 -0800 ocfs2: fix a use after free on error [ Upstream commit c57d117f2b2f2a19b570c36f2819ef8d8210af20 ] The error handling in this function frees "reg" but it is still on the "o2hb_all_regions" list so it will lead to a use after freew. Joseph Qi points out that we need to clear the bit in the "o2hb_region_bitmap" as well Link: https://lkml.kernel.org/r/YBk4M6HUG8jB/jc7@mwanda Fixes: 1cf257f51191 ("ocfs2: fix memory leak") Signed-off-by: Dan Carpenter Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9c0366dbd33a5c792abee6a04cda198ed950b5fb Author: Chuhong Yuan Date: Sun Feb 21 22:35:59 2021 +0800 net/mlx4_core: Add missed mlx4_free_cmd_mailbox() [ Upstream commit 8eb65fda4a6dbd59cd5de24b106a10b6ee0d2176 ] mlx4_do_mirror_rule() forgets to call mlx4_free_cmd_mailbox() to free the memory region allocated by mlx4_alloc_cmd_mailbox() before an exit. Add the missed call to fix it. Fixes: 78efed275117 ("net/mlx4_core: Support mirroring VF DMFS rules on both ports") Signed-off-by: Chuhong Yuan Reviewed-by: Tariq Toukan Link: https://lore.kernel.org/r/20210221143559.390277-1-hslester96@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 04cb57e6e760413c2013dbe7656f2ceddb5b35fe Author: Mateusz Palczewski Date: Tue Nov 24 15:08:27 2020 +0000 i40e: Fix overwriting flow control settings during driver loading [ Upstream commit 4cdb9f80dcd46aab3c0020b4a6920c22735c5d6e ] During driver loading flow control settings were written to FW using a variable which was always zero, since it was being set only by ethtool. This behavior has been corrected and driver no longer overwrites the default FW/NVM settings. Fixes: 373149fc99a0 ("i40e: Decrease the scope of rtnl lock") Signed-off-by: Dawid Lukwinski Signed-off-by: Mateusz Palczewski Reviewed-by: Aleksandr Loktionov Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit aca4b7a21b90d4f87683d0756a15b415a1ce04ca Author: Slawomir Laba Date: Thu Sep 10 07:57:04 2020 +0000 i40e: Fix flow for IPv6 next header (extension header) [ Upstream commit 92c6058024e87087cf1b99b0389d67c0a886360e ] When a packet contains an IPv6 header with next header which is an extension header and not a protocol one, the kernel function skb_transport_header called with such sk_buff will return a pointer to the extension header and not to the TCP one. The above explained call caused a problem with packet processing for skb with encapsulation for tunnel with I40E_TX_CTX_EXT_IP_IPV6. The extension header was not skipped at all. The ipv6_skip_exthdr function does check if next header of the IPV6 header is an extension header and doesn't modify the l4_proto pointer if it points to a protocol header value so its safe to omit the comparison of exthdr and l4.hdr pointers. The ipv6_skip_exthdr can return value -1. This means that the skipping process failed and there is something wrong with the packet so it will be dropped. Fixes: a3fd9d8876a5 ("i40e/i40evf: Handle IPv6 extension headers in checksum offload") Signed-off-by: Slawomir Laba Signed-off-by: Przemyslaw Patynowski Reviewed-by: Aleksandr Loktionov Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ced734445378e4d39de51e6bf0a599f7a130c39e Author: Theodore Ts'o Date: Thu Feb 4 00:05:20 2021 -0500 ext4: fix potential htree index checksum corruption [ Upstream commit b5776e7524afbd4569978ff790864755c438bba7 ] In the case where we need to do an interior node split, and immediately afterwards, we are unable to allocate a new directory leaf block due to ENOSPC, the directory index checksum's will not be filled in correctly (and indeed, will not be correctly journalled). This looks like a bug that was introduced when we added largedir support. The original code doesn't make any sense (and should have been caught in code review), but it was hidden because most of the time, the index node checksum will be set by do_split(). But if do_split bails out due to ENOSPC, then ext4_handle_dirty_dx_node() won't get called, and so the directory index checksum field will not get set, leading to: EXT4-fs error (device sdb): dx_probe:858: inode #6635543: block 4022: comm nfsd: Directory index failed checksum Google-Bug-Id: 176345532 Fixes: e08ac99fa2a2 ("ext4: add largedir feature") Cc: Artem Blagodarenko Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 62945941fe77c84ddc8a874b5f41d1868de3fc50 Author: Konrad Dybcio Date: Mon Jan 18 17:15:58 2021 +0100 drm/msm/dsi: Correct io_start for MSM8994 (20nm PHY) [ Upstream commit 33a7808ce1aea6e2edc1af25db25928137940c02 ] The previous registers were *almost* correct, but instead of PHYs, they were pointing at DSI PLLs, resulting in the PHY id autodetection failing miserably. Fixes: dcefc117cc19 ("drm/msm/dsi: Add support for msm8x94") Signed-off-by: Konrad Dybcio Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 82f363777a441edebeccdc1acb99ccb872cd3b2d Author: Heiner Kallweit Date: Sun Jan 24 16:39:32 2021 +0100 PCI: Align checking of syscall user config accessors [ Upstream commit ef9e4005cbaf022c6251263aa27836acccaef65d ] After 34e3207205ef ("PCI: handle positive error codes"), pci_user_read_config_*() and pci_user_write_config_*() return 0 or negative errno values, not PCIBIOS_* values like PCIBIOS_SUCCESSFUL or PCIBIOS_BAD_REGISTER_NUMBER. Remove comparisons with PCIBIOS_SUCCESSFUL and check only for non-zero. It happens that PCIBIOS_SUCCESSFUL is zero, so this is not a functional change, but it aligns this code with the user accessors. [bhelgaas: commit log] Fixes: 34e3207205ef ("PCI: handle positive error codes") Link: https://lore.kernel.org/r/f1220314-e518-1e18-bf94-8e6f8c703758@gmail.com Signed-off-by: Heiner Kallweit Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 371bbd20821b2f803b6fa33692b4f585dce0fa6b Author: Jorgen Hansen Date: Wed Jan 20 08:32:40 2021 -0800 VMCI: Use set_page_dirty_lock() when unregistering guest memory [ Upstream commit 5a16c535409f8dcb7568e20737309e3027ae3e49 ] When the VMCI host support releases guest memory in the case where the VM was killed, the pinned guest pages aren't locked. Use set_page_dirty_lock() instead of set_page_dirty(). Testing done: Killed VM while having an active VMCI based vSocket connection and observed warning from ext4. With this fix, no warning was observed. Ran various vSocket tests without issues. Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Reviewed-by: Vishnu Dasa Signed-off-by: Jorgen Hansen Link: https://lore.kernel.org/r/1611160360-30299-1-git-send-email-jhansen@vmware.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 57153e5e9f970b2ea5ad2e2f5e1dd0aa3fe83986 Author: Simon South Date: Tue Jan 19 11:12:06 2021 -0500 pwm: rockchip: rockchip_pwm_probe(): Remove superfluous clk_unprepare() [ Upstream commit d5d8d675865ccddfe4da26c85f22c55cec663bf2 ] If rockchip_pwm_probe() fails to register a PWM device it calls clk_unprepare() for the device's PWM clock, without having first disabled the clock and before jumping to an error handler that also unprepares it. This is likely to produce warnings from the kernel about the clock being unprepared when it is still enabled, and then being unprepared when it has already been unprepared. Prevent these warnings by removing this unnecessary call to clk_unprepare(). Fixes: 48cf973cae33 ("pwm: rockchip: Avoid glitches on already running PWMs") Signed-off-by: Simon South Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 33b32770e48861489e22caf621772cc1a27be7d6 Author: Aswath Govindraju Date: Wed Jan 13 10:42:52 2021 +0530 misc: eeprom_93xx46: Add module alias to avoid breaking support for non device tree users [ Upstream commit 4540b9fbd8ebb21bb3735796d300a1589ee5fbf2 ] Module alias "spi:93xx46" is used by non device tree users like drivers/misc/eeprom/digsy_mtc_eeprom.c and removing it will break support for them. Fix this by adding back the module alias "spi:93xx46". Fixes: 13613a2246bf ("misc: eeprom_93xx46: Fix module alias to enable module autoprobe") Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20210113051253.15061-1-a-govindraju@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8a610927ce26e52b6e6414befa90238ea38e921b Author: Aswath Govindraju Date: Thu Jan 7 22:09:53 2021 +0530 misc: eeprom_93xx46: Fix module alias to enable module autoprobe [ Upstream commit 13613a2246bf531f5fc04e8e62e8f21a3d39bf1c ] Fix module autoprobe by correcting module alias to match the string from /sys/class/.../spi1.0/modalias content. Fixes: 06b4501e88ad ("misc/eeprom: add driver for microwire 93xx46 EEPROMs") Signed-off-by: Aswath Govindraju Link: https://lore.kernel.org/r/20210107163957.28664-2-a-govindraju@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8193f1a44ab8ce54c6a5bdd429b5406d674463e0 Author: Randy Dunlap Date: Wed Nov 25 16:40:11 2020 -0800 sparc64: only select COMPAT_BINFMT_ELF if BINFMT_ELF is set [ Upstream commit 80bddf5c93a99e11fc9faf7e4b575d01cecd45d3 ] Currently COMPAT on SPARC64 selects COMPAT_BINFMT_ELF unconditionally, even when BINFMT_ELF is not enabled. This causes a kconfig warning. Instead, just select COMPAT_BINFMT_ELF if BINFMT_ELF is enabled. This builds cleanly with no kconfig warnings. WARNING: unmet direct dependencies detected for COMPAT_BINFMT_ELF Depends on [n]: COMPAT [=y] && BINFMT_ELF [=n] Selected by [y]: - COMPAT [=y] && SPARC64 [=y] Fixes: 26b4c912185a ("sparc,sparc64: unify Kconfig files") Signed-off-by: Randy Dunlap Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Cc: Sam Ravnborg Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8645ba68f6b0ce90de6f54875f553f8ae073bb8e Author: Dan Carpenter Date: Tue Feb 16 20:29:05 2021 -0800 Input: elo - fix an error code in elo_connect() [ Upstream commit 0958351e93fa0ac142f6dd8bd844441594f30a57 ] If elo_setup_10() fails then this should return an error code instead of success. Fixes: fae3006e4b42 ("Input: elo - add support for non-pressure-sensitive touchscreens") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YBKFd5CvDu+jVmfW@mwanda Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit c15587fc621ee1a574222dc4d793d5611127a4f5 Author: Namhyung Kim Date: Sun Feb 14 18:16:38 2021 +0900 perf test: Fix unaligned access in sample parsing test [ Upstream commit c5c97cadd7ed13381cb6b4bef5c841a66938d350 ] The ubsan reported the following error. It was because sample's raw data missed u32 padding at the end. So it broke the alignment of the array after it. The raw data contains an u32 size prefix so the data size should have an u32 padding after 8-byte aligned data. 27: Sample parsing :util/synthetic-events.c:1539:4: runtime error: store to misaligned address 0x62100006b9bc for type '__u64' (aka 'unsigned long long'), which requires 8 byte alignment 0x62100006b9bc: note: pointer points here 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ #0 0x561532a9fc96 in perf_event__synthesize_sample util/synthetic-events.c:1539:13 #1 0x5615327f4a4f in do_test tests/sample-parsing.c:284:8 #2 0x5615327f3f50 in test__sample_parsing tests/sample-parsing.c:381:9 #3 0x56153279d3a1 in run_test tests/builtin-test.c:424:9 #4 0x56153279c836 in test_and_print tests/builtin-test.c:454:9 #5 0x56153279b7eb in __cmd_test tests/builtin-test.c:675:4 #6 0x56153279abf0 in cmd_test tests/builtin-test.c:821:9 #7 0x56153264e796 in run_builtin perf.c:312:11 #8 0x56153264cf03 in handle_internal_command perf.c:364:8 #9 0x56153264e47d in run_argv perf.c:408:2 #10 0x56153264c9a9 in main perf.c:538:3 #11 0x7f137ab6fbbc in __libc_start_main (/lib64/libc.so.6+0x38bbc) #12 0x561532596828 in _start ... SUMMARY: UndefinedBehaviorSanitizer: misaligned-pointer-use util/synthetic-events.c:1539:4 in Fixes: 045f8cd8542d ("perf tests: Add a sample parsing test") Signed-off-by: Namhyung Kim Acked-by: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Cc: Stephane Eranian Link: https://lore.kernel.org/r/20210214091638.519643-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 06c51c11d686ebdf14ead56b0deec2f7347e7302 Author: Adrian Hunter Date: Fri Feb 5 19:53:47 2021 +0200 perf intel-pt: Fix missing CYC processing in PSB [ Upstream commit 03fb0f859b45d1eb05c984ab4bd3bef67e45ede2 ] Add missing CYC packet processing when walking through PSB+. This improves the accuracy of timestamps that follow PSB+, until the next MTC. Fixes: 3d49807870f08 ("perf tools: Add new Intel PT packet definitions") Signed-off-by: Adrian Hunter Reviewed-by: Andi Kleen Cc: Jiri Olsa Link: https://lore.kernel.org/r/20210205175350.23817-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ba6565b407e45272af92dbff3cc5aa3df4379fe6 Author: Andy Shevchenko Date: Mon Feb 8 18:38:15 2021 +0200 spi: pxa2xx: Fix the controller numbering for Wildcat Point [ Upstream commit 54c5d3bfb0cfb7b31259765524567871dee11615 ] Wildcat Point has two SPI controllers and added one is actually second one. Fix the numbering by adding the description of the first one. Fixes: caba248db286 ("spi: spi-pxa2xx-pci: Add ID and driver type for WildcatPoint PCH") Cc: Leif Liddy Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210208163816.22147-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5cc821b7845244c1bebab23954edf810dce343ff Author: Christophe Leroy Date: Fri Feb 5 08:56:13 2021 +0000 powerpc/8xx: Fix software emulation interrupt [ Upstream commit 903178d0ce6bb30ef80a3604ab9ee2b57869fbc9 ] For unimplemented instructions or unimplemented SPRs, the 8xx triggers a "Software Emulation Exception" (0x1000). That interrupt doesn't set reason bits in SRR1 as the "Program Check Exception" does. Go through emulation_assist_interrupt() to set REASON_ILLEGAL. Fixes: fbbcc3bb139e ("powerpc/8xx: Remove SoftwareEmulation()") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/ad782af87a222efc79cfb06079b0fd23d4224eaf.1612515180.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 4e162c19cd747228173100492b5a451dbc485d80 Author: Nathan Lynch Date: Wed Jan 6 20:59:00 2021 -0600 powerpc/pseries/dlpar: handle ibm, configure-connector delay status [ Upstream commit 768d70e19ba525debd571b36e6d0ab19956c63d7 ] dlpar_configure_connector() has two problems in its handling of ibm,configure-connector's return status: 1. When the status is -2 (busy, call again), we call ibm,configure-connector again immediately without checking whether to schedule, which can result in monopolizing the CPU. 2. Extended delay status (9900..9905) goes completely unhandled, causing the configuration to unnecessarily terminate. Fix both of these issues by using rtas_busy_delay(). Fixes: ab519a011caa ("powerpc/pseries: Kernel DLPAR Infrastructure") Signed-off-by: Nathan Lynch Reviewed-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210107025900.410369-1-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit 13b69e2dfd7ca0a2ae117bc1ee2c2ec00d26022d Author: Dan Carpenter Date: Fri Jan 29 17:37:24 2021 +0300 mfd: wm831x-auxadc: Prevent use after free in wm831x_auxadc_read_irq() [ Upstream commit 26783d74cc6a440ee3ef9836a008a697981013d0 ] The "req" struct is always added to the "wm831x->auxadc_pending" list, but it's only removed from the list on the success path. If a failure occurs then the "req" struct is freed but it's still on the list, leading to a use after free. Fixes: 78bb3688ea18 ("mfd: Support multiple active WM831x AUXADC conversions") Signed-off-by: Dan Carpenter Acked-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 7ca753238809a6766d27c72fb3aa329b96c31a33 Author: Alain Volmat Date: Fri Feb 5 19:59:25 2021 +0100 spi: stm32: properly handle 0 byte transfer [ Upstream commit 2269f5a8b1a7b38651d62676b98182828f29d11a ] On 0 byte transfer request, return straight from the xfer function after finalizing the transfer. Fixes: dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller") Signed-off-by: Alain Volmat Link: https://lore.kernel.org/r/1612551572-495-2-git-send-email-alain.volmat@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5873b3a5fde23dd95d8b4a3f8306cf6643d30060 Author: Bob Pearson Date: Wed Jan 27 15:45:01 2021 -0600 RDMA/rxe: Fix coding error in rxe_recv.c [ Upstream commit 7d9ae80e31df57dd3253e1ec514f0000aa588a81 ] check_type_state() in rxe_recv.c is written as if the type bits in the packet opcode were a bit mask which is not correct. This patch corrects this code to compare all 3 type bits to the required type. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20210127214500.3707-1-rpearson@hpe.com Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 78c9fad3fdde75cbfe0fd4f3c8bb410e25d529a7 Author: Arnaldo Carvalho de Melo Date: Thu Jan 28 09:52:47 2021 -0300 perf tools: Fix DSO filtering when not finding a map for a sampled address [ Upstream commit c69bf11ad3d30b6bf01cfa538ddff1a59467c734 ] When we lookup an address and don't find a map we should filter that sample if the user specified a list of --dso entries to filter on, fix it. Before: $ perf script sleep 274800 2843.556162: 1 cycles:u: ffffffffbb26bff4 [unknown] ([unknown]) sleep 274800 2843.556168: 1 cycles:u: ffffffffbb2b047d [unknown] ([unknown]) sleep 274800 2843.556171: 1 cycles:u: ffffffffbb2706b2 [unknown] ([unknown]) sleep 274800 2843.556174: 6 cycles:u: ffffffffbb2b0267 [unknown] ([unknown]) sleep 274800 2843.556176: 59 cycles:u: ffffffffbb2b03b1 [unknown] ([unknown]) sleep 274800 2843.556180: 691 cycles:u: ffffffffbb26bff4 [unknown] ([unknown]) sleep 274800 2843.556189: 9160 cycles:u: 7fa9550eeaa3 __GI___tunables_init+0xf3 (/usr/lib64/ld-2.32.so) sleep 274800 2843.556312: 86937 cycles:u: 7fa9550e157b _dl_lookup_symbol_x+0x4b (/usr/lib64/ld-2.32.so) $ So we have some samples we somehow didn't find in a map for, if we now do: $ perf report --stdio --dso /usr/lib64/ld-2.32.so # dso: /usr/lib64/ld-2.32.so # # Total Lost Samples: 0 # # Samples: 8 of event 'cycles:u' # Event count (approx.): 96856 # # Overhead Command Symbol # ........ ....... ........................ # 89.76% sleep [.] _dl_lookup_symbol_x 9.46% sleep [.] __GI___tunables_init 0.71% sleep [k] 0xffffffffbb26bff4 0.06% sleep [k] 0xffffffffbb2b03b1 0.01% sleep [k] 0xffffffffbb2b0267 0.00% sleep [k] 0xffffffffbb2706b2 0.00% sleep [k] 0xffffffffbb2b047d $ After this patch we get the right output with just entries for the DSOs specified in --dso: $ perf report --stdio --dso /usr/lib64/ld-2.32.so # dso: /usr/lib64/ld-2.32.so # # Total Lost Samples: 0 # # Samples: 8 of event 'cycles:u' # Event count (approx.): 96856 # # Overhead Command Symbol # ........ ....... ........................ # 89.76% sleep [.] _dl_lookup_symbol_x 9.46% sleep [.] __GI___tunables_init $ # Fixes: 96415e4d3f5fdf9c ("perf symbols: Avoid unnecessary symbol loading when dso list is specified") Cc: Alexander Shishkin Cc: Andi Kleen Cc: Ingo Molnar Cc: Jin Yao Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210128131209.GD775562@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5d8daeb5b793b38d7d0be4a673566e07bbeb5e50 Author: Steven Rostedt (VMware) Date: Wed Nov 18 09:34:05 2020 -0500 tracepoint: Do not fail unregistering a probe due to memory failure [ Upstream commit befe6d946551d65cddbd32b9cb0170b0249fd5ed ] The list of tracepoint callbacks is managed by an array that is protected by RCU. To update this array, a new array is allocated, the updates are copied over to the new array, and then the list of functions for the tracepoint is switched over to the new array. After a completion of an RCU grace period, the old array is freed. This process happens for both adding a callback as well as removing one. But on removing a callback, if the new array fails to be allocated, the callback is not removed, and may be used after it is freed by the clients of the tracepoint. There's really no reason to fail if the allocation for a new array fails when removing a function. Instead, the function can simply be replaced by a stub function that could be cleaned up on the next modification of the array. That is, instead of calling the function registered to the tracepoint, it would call a stub function in its place. Link: https://lore.kernel.org/r/20201115055256.65625-1-mmullins@mmlx.us Link: https://lore.kernel.org/r/20201116175107.02db396d@gandalf.local.home Link: https://lore.kernel.org/r/20201117211836.54acaef2@oasis.local.home Link: https://lkml.kernel.org/r/20201118093405.7a6d2290@gandalf.local.home [ Note, this version does use undefined compiler behavior (assuming that a stub function with no parameters or return, can be called by a location that thinks it has parameters but still no return value. Static calls do the same thing, so this trick is not without precedent. There's another solution that uses RCU tricks and is more complex, but can be an alternative if this solution becomes an issue. Link: https://lore.kernel.org/lkml/20210127170721.58bce7cc@gandalf.local.home/ ] Cc: Peter Zijlstra Cc: Josh Poimboeuf Cc: Mathieu Desnoyers Cc: Ingo Molnar Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Dmitry Vyukov Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: Andrii Nakryiko Cc: John Fastabend Cc: KP Singh Cc: netdev Cc: bpf Cc: Kees Cook Cc: Florian Weimer Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints") Reported-by: syzbot+83aa762ef23b6f0d1991@syzkaller.appspotmail.com Reported-by: syzbot+d29e58bb557324e55e5e@syzkaller.appspotmail.com Reported-by: Matt Mullins Signed-off-by: Steven Rostedt (VMware) Tested-by: Matt Mullins Signed-off-by: Sasha Levin commit 970fdcf6c7c8c573f47fe8d2b1803140934208e5 Author: Uwe Kleine-König Date: Tue Jan 26 17:58:31 2021 +0100 amba: Fix resource leak for drivers without .remove [ Upstream commit de5d7adb89367bbc87b4e5ce7afe7ae9bd86dc12 ] Consider an amba driver with a .probe but without a .remove callback (e.g. pl061_gpio_driver). The function amba_probe() is called to bind a device and so dev_pm_domain_attach() and others are called. As there is no remove callback amba_remove() isn't called at unbind time however and so calling dev_pm_domain_detach() is missed and the pm domain keeps active. To fix this always use the core driver callbacks and handle missing amba callbacks there. For probe refuse registration as a driver without probe doesn't make sense. Fixes: 7cfe249475fd ("ARM: AMBA: Add pclk support to AMBA bus infrastructure") Reviewed-by: Ulf Hansson Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210126165835.687514-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 087e96beecddc67d5189934a09f150da33f64f0d Author: Vladimir Murzin Date: Thu Jan 7 10:47:24 2021 +0100 ARM: 9046/1: decompressor: Do not clear SCTLR.nTLSMD for ARMv7+ cores [ Upstream commit 2acb909750431030b65a0a2a17fd8afcbd813a84 ] It was observed that decompressor running on hardware implementing ARM v8.2 Load/Store Multiple Atomicity and Ordering Control (LSMAOC), say, as guest, would stuck just after: Uncompressing Linux... done, booting the kernel. The reason is that it clears nTLSMD bit when disabling caches: nTLSMD, bit [3] When ARMv8.2-LSMAOC is implemented: No Trap Load Multiple and Store Multiple to Device-nGRE/Device-nGnRE/Device-nGnRnE memory. 0b0 All memory accesses by A32 and T32 Load Multiple and Store Multiple at EL1 or EL0 that are marked at stage 1 as Device-nGRE/Device-nGnRE/Device-nGnRnE memory are trapped and generate a stage 1 Alignment fault. 0b1 All memory accesses by A32 and T32 Load Multiple and Store Multiple at EL1 or EL0 that are marked at stage 1 as Device-nGRE/Device-nGnRE/Device-nGnRnE memory are not trapped. This bit is permitted to be cached in a TLB. This field resets to 1. Otherwise: Reserved, RES1 So as effect we start getting traps we are not quite ready for. Looking into history it seems that mask used for SCTLR clear came from the similar code for ARMv4, where bit[3] is the enable/disable bit for the write buffer. That not applicable to ARMv7 and onwards, so retire that bit from the masks. Fixes: 7d09e85448dfa78e3e58186c934449aaf6d49b50 ("[ARM] 4393/2: ARMv7: Add uncompressing code for the new CPU Id format") Signed-off-by: Vladimir Murzin Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 448d70582b11b729c4a9a29da9ae74d06f00f714 Author: Christophe JAILLET Date: Thu Dec 17 22:09:22 2020 +0100 mmc: usdhi6rol0: Fix a resource leak in the error handling path of the probe [ Upstream commit 6052b3c370fb82dec28bcfff6d7ec0da84ac087a ] A call to 'ausdhi6_dma_release()' to undo a previous call to 'usdhi6_dma_request()' is missing in the error handling path of the probe function. It is already present in the remove function. Fixes: 75fa9ea6e3c0 ("mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20201217210922.165340-1-christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 30af715437e37a9fe9b104c654fc7d0e86802b04 Author: Christophe Leroy Date: Wed Jan 20 07:49:13 2021 +0000 powerpc/47x: Disable 256k page size [ Upstream commit 910a0cb6d259736a0c86e795d4c2f42af8d0d775 ] PPC47x_TLBE_SIZE isn't defined for 256k pages, leading to a build break if 256k pages is selected. So change the kconfig so that 256k pages can't be selected for 47x. Fixes: e7f75ad01d59 ("powerpc/47x: Base ppc476 support") Reported-by: kernel test robot Signed-off-by: Christophe Leroy [mpe: Expand change log to mention build break] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/2fed79b1154c872194f98bac4422c23918325e61.1611128938.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 72710b9deeea12c5ec02a09f4aef737afcf0bd52 Author: Shay Drory Date: Mon Jan 25 14:13:38 2021 +0200 IB/umad: Return EIO in case of when device disassociated [ Upstream commit 4fc5461823c9cad547a9bdfbf17d13f0da0d6bb5 ] MAD message received by the user has EINVAL error in all flows including when the device is disassociated. That makes it impossible for the applications to treat such flow differently. Change it to return EIO, so the applications will be able to perform disassociation recovery. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/r/20210125121339.837518-2-leon@kernel.org Signed-off-by: Shay Drory Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6b37e9dda17413cfa22b26f7ca13a46422ae68f5 Author: Geert Uytterhoeven Date: Fri Jan 22 16:39:40 2021 +0100 auxdisplay: ht16k33: Fix refresh rate handling [ Upstream commit e89b0a426721a8ca5971bc8d70aa5ea35c020f90 ] Drop the call to msecs_to_jiffies(), as "HZ / fbdev->refresh_rate" is already the number of jiffies to wait. Fixes: 8992da44c6805d53 ("auxdisplay: ht16k33: Driver for LED controller") Signed-off-by: Geert Uytterhoeven Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit efb178aa999500c72e0ec7a0322edee2535a57cd Author: Pan Bian Date: Mon Jan 18 04:04:55 2021 -0800 isofs: release buffer head before return [ Upstream commit 0a6dc67a6aa45f19bd4ff89b4f468fc50c4b8daa ] Release the buffer_head before returning error code in do_isofs_readdir() and isofs_find_entry(). Fixes: 2deb1acc653c ("isofs: fix access to unallocated memory when reading corrupted filesystem") Link: https://lore.kernel.org/r/20210118120455.118955-1-bianpan2016@163.com Signed-off-by: Pan Bian Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit bd949924a5f55f5bfe18a2f0aa1c70f0a36074de Author: Pan Bian Date: Tue Jan 19 21:00:25 2021 -0800 spi: atmel: Put allocated master before return [ Upstream commit 21ea2743f015dbacec1831bdc8afc848db9c2b8c ] The allocated master is not released. Goto error handling label rather than directly return. Fixes: 5e9af37e46bc ("spi: atmel: introduce probe deferring") Signed-off-by: Pan Bian Fixes: 5e9af37e46bc ("spi: atmel: introduce probe deferring") Reviewed-by: Tudor Ambarus Link: https://lore.kernel.org/r/20210120050025.25426-1-bianpan2016@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ad26df1875bf85152f0f469e66817fcef6464532 Author: David Howells Date: Fri Nov 20 19:04:23 2020 +0100 certs: Fix blacklist flag type confusion [ Upstream commit 4993e1f9479a4161fd7d93e2b8b30b438f00cb0f ] KEY_FLAG_KEEP is not meant to be passed to keyring_alloc() or key_alloc(), as these only take KEY_ALLOC_* flags. KEY_FLAG_KEEP has the same value as KEY_ALLOC_BYPASS_RESTRICTION, but fortunately only key_create_or_update() uses it. LSMs using the key_alloc hook don't check that flag. KEY_FLAG_KEEP is then ignored but fortunately (again) the root user cannot write to the blacklist keyring, so it is not possible to remove a key/hash from it. Fix this by adding a KEY_ALLOC_SET_KEEP flag that tells key_alloc() to set KEY_FLAG_KEEP on the new key. blacklist_init() can then, correctly, pass this to keyring_alloc(). We can also use this in ima_mok_init() rather than setting the flag manually. Note that this doesn't fix an observable bug with the current implementation but it is required to allow addition of new hashes to the blacklist in the future without making it possible for them to be removed. Fixes: 734114f8782f ("KEYS: Add a system blacklist keyring") Reported-by: Mickaël Salaün Signed-off-by: David Howells cc: Mickaël Salaün cc: Mimi Zohar Cc: David Woodhouse Signed-off-by: Sasha Levin commit 84908532c407b9f3375b8386c22f231169214e31 Author: Pan Bian Date: Wed Jan 20 04:33:13 2021 -0800 regulator: axp20x: Fix reference cout leak [ Upstream commit e78bf6be7edaacb39778f3a89416caddfc6c6d70 ] Decrements the reference count of device node and its child node. Fixes: dfe7a1b058bb ("regulator: AXP20x: Add support for regulators subsystem") Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/20210120123313.107640-1-bianpan2016@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fe25fe09421eee24b22bd3da94e9a54720fb6ceb Author: Tom Rix Date: Mon Jan 18 13:19:55 2021 -0800 clocksource/drivers/mxs_timer: Add missing semicolon when DEBUG is defined [ Upstream commit 7da390694afbaed8e0f05717a541dfaf1077ba51 ] When DEBUG is defined this error occurs drivers/clocksource/mxs_timer.c:138:1: error: expected ‘;’ before ‘}’ token The preceding statement needs a semicolon. Replace pr_info() with pr_debug() and remove the unneeded ifdef. Fixes: eb8703e2ef7c ("clockevents/drivers/mxs: Migrate to new 'set-state' interface") Signed-off-by: Tom Rix Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210118211955.763609-1-trix@redhat.com Signed-off-by: Sasha Levin commit 64a33289241f1475fd9a9fd87dd6ba88dfe05fcc Author: Bartosz Golaszewski Date: Thu Jan 14 11:22:17 2021 +0100 rtc: s5m: select REGMAP_I2C [ Upstream commit 1f0cbda3b452b520c5f3794f8f0e410e8bc7386a ] The rtc-s5m uses the I2C regmap but doesn't select it in Kconfig so depending on the configuration the build may fail. Fix it. Fixes: 959df7778bbd ("rtc: Enable compile testing for Maxim and Samsung drivers") Signed-off-by: Bartosz Golaszewski Reviewed-by: Krzysztof Kozlowski Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210114102219.23682-2-brgl@bgdev.pl Signed-off-by: Sasha Levin commit 64bdf3adf0c9fc07ac7fad5f2c6a4c5839d9b359 Author: Claudiu Beznea Date: Wed Dec 16 14:57:31 2020 +0200 power: reset: at91-sama5d2_shdwc: fix wkupdbc mask [ Upstream commit 95aa21a3f1183260db1b0395e03df5bebc5ed641 ] According to datasheet WKUPDBC mask is b/w bits 26..24. Fixes: f80cb48843987 ("power: reset: at91-shdwc: add new shutdown controller driver") Signed-off-by: Claudiu Beznea Reviewed-by: Alexandre Belloni Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 6793433fc8f263eaba1621d3724b6aeba511c6c5 Author: Nicolas Boichat Date: Fri Jan 15 11:45:44 2021 +0000 of/fdt: Make sure no-map does not remove already reserved regions [ Upstream commit 8a5a75e5e9e55de1cef5d83ca3589cb4899193ef ] If the device tree is incorrectly configured, and attempts to define a "no-map" reserved memory that overlaps with the kernel data/code, the kernel would crash quickly after boot, with no obvious clue about the nature of the issue. For example, this would happen if we have the kernel mapped at these addresses (from /proc/iomem): 40000000-41ffffff : System RAM 40080000-40dfffff : Kernel code 40e00000-411fffff : reserved 41200000-413e0fff : Kernel data And we declare a no-map shared-dma-pool region at a fixed address within that range: mem_reserved: mem_region { compatible = "shared-dma-pool"; reg = <0 0x40000000 0 0x01A00000>; no-map; }; To fix this, when removing memory regions at early boot (which is what "no-map" regions do), we need to make sure that the memory is not already reserved. If we do, __reserved_mem_reserve_reg will throw an error: [ 0.000000] OF: fdt: Reserved memory: failed to reserve memory for node 'mem_region': base 0x0000000040000000, size 26 MiB and the code that will try to use the region should also fail, later on. We do not do anything for non-"no-map" regions, as memblock explicitly allows reserved regions to overlap, and the commit that this fixes removed the check for that precise reason. [ qperret: fixed conflicts caused by the usage of memblock_mark_nomap ] Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/ regions in the case of partial overlap") Signed-off-by: Nicolas Boichat Reviewed-by: Stephen Boyd Signed-off-by: Quentin Perret Link: https://lore.kernel.org/r/20210115114544.1830068-3-qperret@google.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 71bc5d496725f7f923904d2f41cd39e32c647fdf Author: KarimAllah Ahmed Date: Fri Jan 15 11:45:43 2021 +0000 fdt: Properly handle "no-map" field in the memory region [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ] Mark the memory region with NOMAP flag instead of completely removing it from the memory blocks. That makes the FDT handling consistent with the EFI memory map handling. Cc: Rob Herring Cc: Frank Rowand Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: KarimAllah Ahmed Signed-off-by: Quentin Perret Link: https://lore.kernel.org/r/20210115114544.1830068-2-qperret@google.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit b60659c70ecf41d07b736da17fe189d7344f0774 Author: Yoshihiro Shimoda Date: Tue Jan 12 18:00:56 2021 +0900 mfd: bd9571mwv: Use devm_mfd_add_devices() [ Upstream commit c58ad0f2b052b5675d6394e03713ee41e721b44c ] To remove mfd devices when unload this driver, should use devm_mfd_add_devices() instead. Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver") Signed-off-by: Yoshihiro Shimoda Acked-for-MFD-by: Lee Jones Reviewed-by: Geert Uytterhoeven Reviewed-by: Matti Vaittinen Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 12e30ce2df6ab9d4067f1698f8ac662d18d53221 Author: Ferry Toth Date: Tue Jan 12 23:37:49 2021 +0100 dmaengine: hsu: disable spurious interrupt [ Upstream commit 035b73b2b3b2e074a56489a7bf84b6a8012c0e0d ] On Intel Tangier B0 and Anniedale the interrupt line, disregarding to have different numbers, is shared between HSU DMA and UART IPs. Thus on such SoCs we are expecting that IRQ handler is called in UART driver only. hsu_pci_irq was handling the spurious interrupt from HSU DMA by returning immediately. This wastes CPU time and since HSU DMA and HSU UART interrupt occur simultaneously they race to be handled causing delay to the HSU UART interrupt handling. Fix this by disabling the interrupt entirely. Fixes: 4831e0d9054c ("serial: 8250_mid: handle interrupt correctly in DMA case") Signed-off-by: Ferry Toth Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210112223749.97036-1-ftoth@exalondelft.nl Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e165c11bfd008eec561582ae1a7ff600bde57f4d Author: Christophe JAILLET Date: Sat Dec 12 17:06:14 2020 +0100 dmaengine: fsldma: Fix a resource leak in an error handling path of the probe function [ Upstream commit b202d4e82531a62a33a6b14d321dd2aad491578e ] In case of error, the previous 'fsl_dma_chan_probe()' calls must be undone by some 'fsl_dma_chan_remove()', as already done in the remove function. It was added in the remove function in commit 77cd62e8082b ("fsldma: allow Freescale Elo DMA driver to be compiled as a module") Fixes: d3f620b2c4fe ("fsldma: simplify IRQ probing and handling") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20201212160614.92576-1-christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a81149f92d0b5655e7301530ffb637e7c2df04c9 Author: Christophe JAILLET Date: Sat Dec 12 17:05:16 2020 +0100 dmaengine: fsldma: Fix a resource leak in the remove function [ Upstream commit cbc0ad004c03ad7971726a5db3ec84dba3dcb857 ] A 'irq_dispose_mapping()' call is missing in the remove function. Add it. This is needed to undo the 'irq_of_parse_and_map() call from the probe function and already part of the error handling path of the probe function. It was added in the probe function only in commit d3f620b2c4fe ("fsldma: simplify IRQ probing and handling") Fixes: 77cd62e8082b ("fsldma: allow Freescale Elo DMA driver to be compiled as a module") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20201212160516.92515-1-christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4fea6b3b057d09bc9eae4da289ea17cde68e9db4 Author: Randy Dunlap Date: Wed Dec 16 17:12:21 2020 -0800 HID: core: detect and skip invalid inputs to snto32() [ Upstream commit a0312af1f94d13800e63a7d0a66e563582e39aec ] Prevent invalid (0, 0) inputs to hid-core's snto32() function. Maybe it is just the dummy device here that is causing this, but there are hundreds of calls to snto32(0, 0). Having n (bits count) of 0 is causing the current UBSAN trap with a shift value of 0xffffffff (-1, or n - 1 in this function). Either of the value to shift being 0 or the bits count being 0 can be handled by just returning 0 to the caller, avoiding the following complex shift + OR operations: return value & (1 << (n - 1)) ? value | (~0U << n) : value; Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Signed-off-by: Randy Dunlap Reported-by: syzbot+1e911ad71dd4ea72e04a@syzkaller.appspotmail.com Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 30860998cab5e82ea57e2de0200684e3303ac084 Author: Pratyush Yadav Date: Wed Dec 23 00:14:20 2020 +0530 spi: cadence-quadspi: Abort read if dummy cycles required are too many [ Upstream commit ceeda328edeeeeac7579e9dbf0610785a3b83d39 ] The controller can only support up to 31 dummy cycles. If the command requires more it falls back to using 31. This command is likely to fail because the correct number of cycles are not waited upon. Rather than silently issuing an incorrect command, fail loudly so the caller can get a chance to find out the command can't be supported by the controller. Fixes: 140623410536 ("mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller") Signed-off-by: Pratyush Yadav Link: https://lore.kernel.org/r/20201222184425.7028-3-p.yadav@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4ed995b914350a3c948cca1bc68f5e301aafd75f Author: Jan Kara Date: Tue Dec 22 12:09:53 2020 +0100 quota: Fix memory leak when handling corrupted quota file [ Upstream commit a4db1072e1a3bd7a8d9c356e1902b13ac5deb8ef ] When checking corrupted quota file we can bail out and leak allocated info structure. Properly free info structure on error return. Reported-by: syzbot+77779c9b52ab78154b08@syzkaller.appspotmail.com Fixes: 11c514a99bb9 ("quota: Sanity-check quota file headers on load") Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit cd89e3cbbdad5a59f3a724a0b409aac3a96585c2 Author: Martin Blumenstingl Date: Sat Dec 26 13:15:54 2020 +0100 clk: meson: clk-pll: fix initializing the old rate (fallback) for a PLL [ Upstream commit 2f290b7c67adf6459a17a4c978102af35cd62e4a ] The "rate" parameter in meson_clk_pll_set_rate() contains the new rate. Retrieve the old rate with clk_hw_get_rate() so we don't inifinitely try to switch from the new rate to the same rate again. Fixes: 7a29a869434e8b ("clk: meson: Add support for Meson clock controller") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20201226121556.975418-2-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit e516a306ef914bd2cddcb256bae09ec86ae07b05 Author: Eric W. Biederman Date: Thu Dec 17 09:42:00 2020 -0600 capabilities: Don't allow writing ambiguous v3 file capabilities [ Upstream commit 95ebabde382c371572297915b104e55403674e73 ] The v3 file capabilities have a uid field that records the filesystem uid of the root user of the user namespace the file capabilities are valid in. When someone is silly enough to have the same underlying uid as the root uid of multiple nested containers a v3 filesystem capability can be ambiguous. In the spirit of don't do that then, forbid writing a v3 filesystem capability if it is ambiguous. Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities") Reviewed-by: Andrew G. Morgan Reviewed-by: Serge Hallyn Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 9bbd72356348b710f2559542bb73948f30b90b4c Author: Tom Rix Date: Wed Dec 30 06:56:04 2020 -0800 jffs2: fix use after free in jffs2_sum_write_data() [ Upstream commit 19646447ad3a680d2ab08c097585b7d96a66126b ] clang static analysis reports this problem fs/jffs2/summary.c:794:31: warning: Use of memory after it is freed c->summary->sum_list_head = temp->u.next; ^~~~~~~~~~~~ In jffs2_sum_write_data(), in a loop summary data is handles a node at a time. When it has written out the node it is removed the summary list, and the node is deleted. In the corner case when a JFFS2_FEATURE_RWCOMPAT_COPY is seen, a call is made to jffs2_sum_disable_collecting(). jffs2_sum_disable_collecting() deletes the whole list which conflicts with the loop's deleting the list by parts. To preserve the old behavior of stopping the write midway, bail out of the loop after disabling summary collection. Fixes: 6171586a7ae5 ("[JFFS2] Correct handling of JFFS2_FEATURE_RWCOMPAT_COPY nodes.") Signed-off-by: Tom Rix Reviewed-by: Nathan Chancellor Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit f09cf766ae3d27261999a188651d1b13f77397fe Author: Colin Ian King Date: Thu Feb 11 13:01:08 2021 +0000 fs/jfs: fix potential integer overflow on shift of a int [ Upstream commit 4208c398aae4c2290864ba15c3dab7111f32bec1 ] The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit integer. In the case where l2nb is 32 or more this can lead to an overflow. Avoid this by shifting the value 1LL instead. Addresses-Coverity: ("Uninitentional integer overflow") Fixes: b40c2e665cd5 ("fs/jfs: TRIM support for JFS Filesystem") Signed-off-by: Colin Ian King Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 005da2a16e3f90c994ef39e18bd8a027e210ff56 Author: Lakshmi Ramasubramanian Date: Thu Feb 4 09:49:51 2021 -0800 ima: Free IMA measurement buffer after kexec syscall [ Upstream commit f31e3386a4e92ba6eda7328cb508462956c94c64 ] IMA allocates kernel virtual memory to carry forward the measurement list, from the current kernel to the next kernel on kexec system call, in ima_add_kexec_buffer() function. This buffer is not freed before completing the kexec system call resulting in memory leak. Add ima_buffer field in "struct kimage" to store the virtual address of the buffer allocated for the IMA measurement list. Free the memory allocated for the IMA measurement list in kimage_file_post_load_cleanup() function. Signed-off-by: Lakshmi Ramasubramanian Suggested-by: Tyler Hicks Reviewed-by: Thiago Jung Bauermann Reviewed-by: Tyler Hicks Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list") Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 5db2c9e89a2dfe279bc5527a8f4571197b15f10f Author: Lakshmi Ramasubramanian Date: Thu Feb 4 09:49:50 2021 -0800 ima: Free IMA measurement buffer on error [ Upstream commit 6d14c6517885fa68524238787420511b87d671df ] IMA allocates kernel virtual memory to carry forward the measurement list, from the current kernel to the next kernel on kexec system call, in ima_add_kexec_buffer() function. In error code paths this memory is not freed resulting in memory leak. Free the memory allocated for the IMA measurement list in the error code paths in ima_add_kexec_buffer() function. Signed-off-by: Lakshmi Ramasubramanian Suggested-by: Tyler Hicks Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list") Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit e99fbca3382bc5f1665be04b46e6afeacbd37228 Author: Daniele Alessandrelli Date: Wed Feb 3 11:28:37 2021 +0000 crypto: ecdh_helper - Ensure 'len >= secret.len' in decode_key() [ Upstream commit a53ab94eb6850c3657392e2d2ce9b38c387a2633 ] The length ('len' parameter) passed to crypto_ecdh_decode_key() is never checked against the length encoded in the passed buffer ('buf' parameter). This could lead to an out-of-bounds access when the passed length is less than the encoded length. Add a check to prevent that. Fixes: 3c4b23901a0c7 ("crypto: ecdh - Add ECDH software support") Signed-off-by: Daniele Alessandrelli Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ca30f70de83a89862340948dca9bcbe31b6a8632 Author: Jan Henrik Weinstock Date: Mon Feb 1 16:14:59 2021 +0100 hwrng: timeriomem - Fix cooldown period calculation [ Upstream commit e145f5565dc48ccaf4cb50b7cfc48777bed8c100 ] Ensure cooldown period tolerance of 1% is actually accounted for. Fixes: ca3bff70ab32 ("hwrng: timeriomem - Improve performance...") Signed-off-by: Jan Henrik Weinstock Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9ef8ddf400dd0ccf15f0b1d1605a22ee0c635bc6 Author: Zhihao Cheng Date: Fri Nov 20 09:08:04 2020 +0800 btrfs: clarify error returns values in __load_free_space_cache [ Upstream commit 3cc64e7ebfb0d7faaba2438334c43466955a96e8 ] Return value in __load_free_space_cache is not properly set after (unlikely) memory allocation failures and 0 is returned instead. This is not a problem for the caller load_free_space_cache because only value 1 is considered as 'cache loaded' but for clarity it's better to set the errors accordingly. Fixes: a67509c30079 ("Btrfs: add a io_ctl struct and helpers for dealing with the space cache") Reported-by: Hulk Robot Signed-off-by: Zhihao Cheng Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit b254acef4dcf98f0c58e4806968f048c3ab207d0 Author: Andrea Parri (Microsoft) Date: Wed Dec 9 08:08:25 2020 +0100 Drivers: hv: vmbus: Avoid use-after-free in vmbus_onoffer_rescind() [ Upstream commit e3fa4b747f085d2cda09bba0533b86fa76038635 ] When channel->device_obj is non-NULL, vmbus_onoffer_rescind() could invoke put_device(), that will eventually release the device and free the channel object (cf. vmbus_device_release()). However, a pointer to the object is dereferenced again later to load the primary_channel. The use-after-free can be avoided by noticing that this load/check is redundant if device_obj is non-NULL: primary_channel must be NULL if device_obj is non-NULL, cf. vmbus_add_channel_work(). Fixes: 54a66265d6754b ("Drivers: hv: vmbus: Fix rescind handling") Reported-by: Juan Vazquez Signed-off-by: Andrea Parri (Microsoft) Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20201209070827.29335-5-parri.andrea@gmail.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 4df803e55cd4397c051049e6767797040d0d70b7 Author: Florian Fainelli Date: Fri Jan 29 10:28:45 2021 -0800 ata: ahci_brcm: Add back regulators management [ Upstream commit 10340f8d7b6dd54e616339c8ccb2f397133ebea0 ] While reworking the resources management and departing from using ahci_platform_enable_resources() which did not allow a proper step separation like we need, we unfortunately lost the ability to control AHCI regulators. This broke some Broadcom STB systems that do expect regulators to be turned on to link up with attached hard drives. Fixes: c0cdf2ac4b5b ("ata: ahci_brcm: Fix AHCI resources management") Signed-off-by: Florian Fainelli Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ab1fbcc93aec8ab387524ae028829ee74d90a582 Author: Laurent Pinchart Date: Sun Dec 20 15:11:13 2020 +0100 media: uvcvideo: Accept invalid bFormatIndex and bFrameIndex values [ Upstream commit dc9455ffae02d7b7fb51ba1e007fffcb9dc5d890 ] The Renkforce RF AC4K 300 Action Cam 4K reports invalid bFormatIndex and bFrameIndex values when negotiating the video probe and commit controls. The UVC descriptors report a single supported format and frame size, with bFormatIndex and bFrameIndex both equal to 2, but the video probe and commit controls report bFormatIndex and bFrameIndex set to 1. The device otherwise operates correctly, but the driver rejects the values and fails the format try operation. Fix it by ignoring the invalid indices, and assuming that the format and frame requested by the driver are accepted by the device. Link: https://bugzilla.kernel.org/show_bug.cgi?id=210767 Fixes: 8a652a17e3c0 ("media: uvcvideo: Ensure all probed info is returned to v4l2") Reported-by: Till Dörges Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8f19c26c7fd814a4ea6ceb8b128defc248656849 Author: Tom Rix Date: Mon Jan 18 14:45:13 2021 +0100 media: pxa_camera: declare variable when DEBUG is defined [ Upstream commit 031b9212eeee365443aaef013360ea6cded7b2c4 ] When DEBUG is defined this error occurs drivers/media/platform/pxa_camera.c:1410:7: error: ‘i’ undeclared (first use in this function) for (i = 0; i < vb->num_planes; i++) ^ The variable 'i' is missing, so declare it. Fixes: 6f28435d1c15 ("[media] media: platform: pxa_camera: trivial move of functions") Signed-off-by: Tom Rix Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ee8eac6df80079b48e4131a4e9c39086ae47a7d8 Author: Christophe JAILLET Date: Sat Jan 16 22:21:46 2021 +0100 media: cx25821: Fix a bug when reallocating some dma memory [ Upstream commit b2de3643c5024fc4fd128ba7767c7fb8b714bea7 ] This function looks like a realloc. However, if 'risc->cpu != NULL', the memory will be freed, but never reallocated with the bigger 'size'. Explicitly set 'risc->cpu' to NULL, so that the reallocation is correctly performed a few lines below. [hverkuil: NULL != risc->cpu -> risc->cpu] Fixes: 5ede94c70553 ("[media] cx25821: remove bogus btcx_risc dependency) Signed-off-by: Christophe JAILLET Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0309b9766b3d3d2697561a48a7bb71dd480a5f07 Author: Luo Meng Date: Wed Nov 25 02:34:37 2020 +0100 media: qm1d1c0042: fix error return code in qm1d1c0042_init() [ Upstream commit fcf8d018bdca0453b8d6359062e6bc1512d04c38 ] Fix to return a negative error code from the error handling case instead of 0 in function qm1d1c0042_init(), as done elsewhere in this function. Fixes: ab4d14528fdf ("[media] em28xx: add support for PLEX PX-BCUD (ISDB-S)") Reported-by: Hulk Robot Signed-off-by: Luo Meng Acked-by: Akihiro Tsukada Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 171ee0c008cef1e1796c3b90fbb7e6eb46b0e857 Author: Joe Perches Date: Sun Aug 23 20:13:31 2020 +0200 media: lmedm04: Fix misuse of comma [ Upstream commit 59a3e78f8cc33901fe39035c1ab681374bba95ad ] There's a comma used instead of a semicolon that causes multiple statements to be executed after an if instead of just the intended single statement. Replace the comma with a semicolon. Fixes: 15e1ce33182d ("[media] lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb") Signed-off-by: Joe Perches Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ec39bca0581d22a00e42602ad4cd7ae1187d00e8 Author: Jiri Olsa Date: Tue Jan 5 00:02:37 2021 +0100 crypto: bcm - Rename struct device_private to bcm_device_private [ Upstream commit f7f2b43eaf6b4cfe54c75100709be31d5c4b52c8 ] Renaming 'struct device_private' to 'struct bcm_device_private', because it clashes with 'struct device_private' from 'drivers/base/base.h'. While it's not a functional problem, it's causing two distinct type hierarchies in BTF data. It also breaks build with options: CONFIG_DEBUG_INFO_BTF=y CONFIG_CRYPTO_DEV_BCM_SPU=y as reported by Qais Yousef [1]. [1] https://lore.kernel.org/lkml/20201229151352.6hzmjvu3qh6p2qgg@e107158-lin/ Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Jiri Olsa Tested-by: Qais Yousef Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e48a56ec0895d5eb0434ff00d29c74c223c08c5b Author: Dan Carpenter Date: Fri Dec 11 13:07:59 2020 +0300 ASoC: cs42l56: fix up error handling in probe [ Upstream commit 856fe64da84c95a1d415564b981ae3908eea2a76 ] There are two issues with this code. The first error path forgot to set the error code and instead returns success. The second error path doesn't clean up. Fixes: 272b5edd3b8f ("ASoC: Add support for CS42L56 CODEC") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/X9NE/9nK9/TuxuL+@mwanda Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c13c6c73d7a240f6942877423b5236e097045c4b Author: Dinghao Liu Date: Sat Jan 2 09:26:37 2021 +0100 media: tm6000: Fix memleak in tm6000_start_stream [ Upstream commit 76aaf8a96771c16365b8510f1fb97738dc88026e ] When usb_clear_halt() fails, dvb->bulk_urb->transfer_buffer and dvb->bulk_urb should be freed just like when usb_submit_urb() fails. Fixes: 3169c9b26fffa ("V4L/DVB (12788): tm6000: Add initial DVB-T support") Signed-off-by: Dinghao Liu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ca26576bf0003c1148938c2e9231e182c0ab8a31 Author: Dinghao Liu Date: Sat Jan 2 07:27:22 2021 +0100 media: media/pci: Fix memleak in empress_init [ Upstream commit 15d0c52241ecb1c9d802506bff6f5c3f7872c0df ] When vb2_queue_init() fails, dev->empress_dev should be released just like other error handling paths. Fixes: 2ada815fc48bb ("[media] saa7134: convert to vb2") Signed-off-by: Dinghao Liu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c03967eb83d115bcd3b3e9993175fd5efac78c92 Author: Christophe JAILLET Date: Sat Dec 12 18:41:19 2020 +0100 media: vsp1: Fix an error handling path in the probe function [ Upstream commit 7113469dafc2d545fa4fa9bc649c31dc27db492e ] A previous 'rcar_fcp_get()' call must be undone in the error handling path, as already done in the remove function. Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support") Signed-off-by: Christophe JAILLET Reviewed-by: Geert Uytterhoeven Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 717aeb383ac53eb5508a0764dea469600646fa4c Author: Jacopo Mondi Date: Mon Dec 21 18:52:20 2020 +0100 media: i2c: ov5670: Fix PIXEL_RATE minimum value [ Upstream commit dc1eb7c9c290cba52937c9a224b22a400bb0ffd7 ] The driver currently reports a single supported value for V4L2_CID_PIXEL_RATE and initializes the control's minimum value to 0, which is very risky, as userspace might accidentally use it as divider when calculating the time duration of a line. Fix this by using as minimum the only supported value when registering the control. Fixes: 5de35c9b8dcd1 ("media: i2c: Add Omnivision OV5670 5M sensor support") Signed-off-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5054cdc89d55462fbaf92ada552d48328c0ee75c Author: Nathan Chancellor Date: Tue Jan 5 13:15:48 2021 -0700 MIPS: lantiq: Explicitly compare LTQ_EBU_PCC_ISTAT against 0 [ Upstream commit c6f2a9e17b9bef7677caddb1626c2402f3e9d2bd ] When building xway_defconfig with clang: arch/mips/lantiq/irq.c:305:48: error: use of logical '&&' with constant operand [-Werror,-Wconstant-logical-operand] if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT) ^ ~~~~~~~~~~~~~~~~~ arch/mips/lantiq/irq.c:305:48: note: use '&' for a bitwise operation if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT) ^~ & arch/mips/lantiq/irq.c:305:48: note: remove constant to silence this warning if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT) ~^~~~~~~~~~~~~~~~~~~~ 1 error generated. Explicitly compare the constant LTQ_EBU_PCC_ISTAT against 0 to fix the warning. Additionally, remove the unnecessary parentheses as this is a simple conditional statement and shorthand '== 0' to '!'. Fixes: 3645da0276ae ("OF: MIPS: lantiq: implement irq_domain support") Link: https://github.com/ClangBuiltLinux/linux/issues/807 Reported-by: Dmitry Golovin Signed-off-by: Nathan Chancellor Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit a19849edb473633d5c98bdeffe37cd776c718b2f Author: Nathan Chancellor Date: Tue Jan 5 13:34:56 2021 -0700 MIPS: c-r4k: Fix section mismatch for loongson2_sc_init [ Upstream commit c58734eee6a2151ba033c0dcb31902c89e310374 ] When building with clang, the following section mismatch warning occurs: WARNING: modpost: vmlinux.o(.text+0x24490): Section mismatch in reference from the function r4k_cache_init() to the function .init.text:loongson2_sc_init() This should have been fixed with commit ad4fddef5f23 ("mips: fix Section mismatch in reference") but it was missed. Remove the improper __init annotation like that commit did. Fixes: 078a55fc824c ("MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code") Link: https://github.com/ClangBuiltLinux/linux/issues/787 Signed-off-by: Nathan Chancellor Reviewed-by: Huacai Chen Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit bdb94f6deccc78ed71525368e529f1469ff9b943 Author: Corentin Labbe Date: Mon Dec 14 20:02:30 2020 +0000 crypto: sun4i-ss - fix kmap usage [ Upstream commit 9bc3dd24e7dccd50757db743a3635ad5b0497e6e ] With the recent kmap change, some tests which were conditional on CONFIG_DEBUG_HIGHMEM now are enabled by default. This permit to detect a problem in sun4i-ss usage of kmap. sun4i-ss uses two kmap via sg_miter (one for input, one for output), but using two kmap at the same time is hard: "the ordering has to be correct and with sg_miter that's probably hard to get right." (quoting Tlgx) So the easiest solution is to never have two sg_miter/kmap open at the same time. After each use of sg_miter, I store the current index, for being able to resume sg_miter to the right place. Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 46586a2be1258b513a0748a55ffafa7090107476 Author: Dan Carpenter Date: Thu Dec 3 11:40:48 2020 +0300 gma500: clean up error handling in init [ Upstream commit 15ccc39b3aab667c6fa131206f01f31bfbccdf6a ] The main problem with this error handling was that it didn't clean up if i2c_add_numbered_adapter() failed. This code is pretty old, and doesn't match with today's checkpatch.pl standards so I took the opportunity to tidy it up a bit. I changed the NULL comparison, and removed the WARNING message if kzalloc() fails and updated the label names. Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support") Signed-off-by: Dan Carpenter Signed-off-by: Patrik Jakobsson Link: https://patchwork.freedesktop.org/patch/msgid/X8ikkAqZfnDO2lu6@mwanda Signed-off-by: Sasha Levin commit c277783f3b2d039c440fc8ed73880346d5a2a1b9 Author: Jialin Zhang Date: Mon Nov 30 10:02:16 2020 +0800 drm/gma500: Fix error return code in psb_driver_load() [ Upstream commit 6926872ae24452d4f2176a3ba2dee659497de2c4 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers") Reported-by: Hulk Robot Signed-off-by: Jialin Zhang Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201130020216.1906141-1-zhangjialin11@huawei.com Signed-off-by: Sasha Levin commit 3c7af54224869d962d6e65fb9806f6bb29e4f5b4 Author: Randy Dunlap Date: Thu Nov 26 19:17:52 2020 -0800 fbdev: aty: SPARC64 requires FB_ATY_CT [ Upstream commit c6c90c70db4d9a0989111d6b994d545659410f7a ] It looks like SPARC64 requires FB_ATY_CT to build without errors, so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled instead of using "default y if SPARC64 && PCI", which is not strong enough to prevent build errors. As it currently is, FB_ATY_CT can be disabled, resulting in build errors: ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko] undefined! ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko] undefined! Reviewed-by: Geert Uytterhoeven Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev") Signed-off-by: Randy Dunlap Cc: "David S. Miller" Cc: sparclinux@vger.kernel.org Cc: Tomi Valkeinen Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Cc: Daniel Vetter Cc: David Airlie Cc: Bartlomiej Zolnierkiewicz Cc: Geert Uytterhoeven Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201127031752.10371-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 376ced45aa70d634e2bf3814df7102c951ce2e5f Author: Maxime Chevallier Date: Tue Feb 16 10:25:35 2021 +0100 net: mvneta: Remove per-cpu queue mapping for Armada 3700 [ Upstream commit cf9bf871280d9e0a8869d98c2602d29caf69dfa3 ] According to Errata #23 "The per-CPU GbE interrupt is limited to Core 0", we can't use the per-cpu interrupt mechanism on the Armada 3700 familly. This is correctly checked for RSS configuration, but the initial queue mapping is still done by having the queues spread across all the CPUs in the system, both in the init path and in the cpu_hotplug path. Fixes: 2636ac3cc2b4 ("net: mvneta: Add network support for Armada 3700 SoC") Signed-off-by: Maxime Chevallier Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b892899ad0cd30140c89d67a1636dfd7cbccf047 Author: Shyam Sundar S K Date: Wed Feb 17 00:37:09 2021 +0530 net: amd-xgbe: Reset link when the link never comes back [ Upstream commit 84fe68eb67f9499309cffd97c1ba269de125ff14 ] Normally, auto negotiation and reconnect should be automatically done by the hardware. But there seems to be an issue where auto negotiation has to be restarted manually. This happens because of link training and so even though still connected to the partner the link never "comes back". This needs an auto-negotiation restart. Also, a change in xgbe-mdio is needed to get ethtool to recognize the link down and get the link change message. This change is only required in a backplane connection mode. Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules") Co-developed-by: Sudheesh Mavila Signed-off-by: Sudheesh Mavila Signed-off-by: Shyam Sundar S K Acked-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6e6abd5a45107289307f7db0e0744f9a2c09da20 Author: Shyam Sundar S K Date: Wed Feb 17 00:37:07 2021 +0530 net: amd-xgbe: Reset the PHY rx data path when mailbox command timeout [ Upstream commit 30b7edc82ec82578f4f5e6706766f0a9535617d3 ] Sometimes mailbox commands timeout when the RX data path becomes unresponsive. This prevents the submission of new mailbox commands to DXIO. This patch identifies the timeout and resets the RX data path so that the next message can be submitted properly. Fixes: 549b32af9f7c ("amd-xgbe: Simplify mailbox interface rate change code") Co-developed-by: Sudheesh Mavila Signed-off-by: Sudheesh Mavila Signed-off-by: Shyam Sundar S K Acked-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d68420d452433ba0c021f2eeecb07b8731f7340c Author: Lijun Pan Date: Fri Feb 12 20:49:00 2021 -0600 ibmvnic: skip send_request_unmap for timeout reset [ Upstream commit 7d3a7b9ea59ddb223aec59b45fa1713c633aaed4 ] Timeout reset will trigger the VIOS to unmap it automatically, similarly as FAILVOER and MOBILITY events. If we unmap it in the linux side, we will see errors like "30000003: Error 4 in REQUEST_UNMAP_RSP". So, don't call send_request_unmap for timeout reset. Fixes: ed651a10875f ("ibmvnic: Updated reset handling") Signed-off-by: Lijun Pan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4fac507d8f03cf4fc3389952521f46b0cda2b063 Author: Colin Ian King Date: Mon Feb 15 12:05:32 2021 +0000 b43: N-PHY: Fix the update of coef for the PHY revision >= 3case [ Upstream commit 4773acf3d4b50768bf08e9e97a204819e9ea0895 ] The documentation for the PHY update [1] states: Loop 4 times with index i If PHY Revision >= 3 Copy table[i] to coef[i] Otherwise Set coef[i] to 0 the copy of the table to coef is currently implemented the wrong way around, table is being updated from uninitialized values in coeff. Fix this by swapping the assignment around. [1] https://bcm-v4.sipsolutions.net/802.11/PHY/N/RestoreCal/ Fixes: 2f258b74d13c ("b43: N-PHY: implement restoring general configuration") Addresses-Coverity: ("Uninitialized scalar variable") Signed-off-by: Colin Ian King Acked-by: Larry Finger Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 14d12b1b9b5b7a051d46d34053a379982472455b Author: Colin Ian King Date: Fri Feb 5 17:53:52 2021 +0000 mac80211: fix potential overflow when multiplying to u32 integers [ Upstream commit 6194f7e6473be78acdc5d03edd116944bdbb2c4e ] The multiplication of the u32 variables tx_time and estimated_retx is performed using a 32 bit multiplication and the result is stored in a u64 result. This has a potential u32 overflow issue, so avoid this by casting tx_time to a u64 to force a 64 bit multiply. Addresses-Coverity: ("Unintentional integer overflow") Fixes: 050ac52cbe1f ("mac80211: code for on-demand Hybrid Wireless Mesh Protocol") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210205175352.208841-1-colin.king@canonical.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d6cd5498e652c737cfc25f907eda605e0724c464 Author: Juergen Gross Date: Thu Feb 11 11:16:12 2021 +0100 xen/netback: fix spurious event detection for common event case [ Upstream commit a3daf3d39132b405781be8d9ede0c449b244b64e ] In case of a common event for rx and tx queue the event should be regarded to be spurious if no rx and no tx requests are pending. Unfortunately the condition for testing that is wrong causing to decide a event being spurious if no rx OR no tx requests are pending. Fix that plus using local variables for rx/tx pending indicators in order to split function calls and if condition. Fixes: 23025393dbeb3b ("xen/netback: use lateeoi irq binding") Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Reviewed-by: Paul Durrant Reviewed-by: Wei Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d6fe6d183fab3fc1313d7520b0fe8625b84b7d36 Author: Edwin Peer Date: Thu Feb 11 02:24:23 2021 -0500 bnxt_en: reverse order of TX disable and carrier off [ Upstream commit 132e0b65dc2b8bfa9721bfce834191f24fd1d7ed ] A TX queue can potentially immediately timeout after it is stopped and the last TX timestamp on that queue was more than 5 seconds ago with carrier still up. Prevent these intermittent false TX timeouts by bringing down carrier first before calling netif_tx_disable(). Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 474ac57c26f7d67c36b349f3bb2f76e9eacaec9f Author: Linus Lüssing Date: Wed Feb 10 09:53:44 2021 +0200 ath9k: fix data bus crash when setting nf_override via debugfs [ Upstream commit 12c8f3d1cdd84f01ee777b756db9dddc1f1c9d17 ] When trying to set the noise floor via debugfs, a "data bus error" crash like the following can happen: [ 88.433133] Data bus error, epc == 80221c28, ra == 83314e60 [ 88.438895] Oops[#1]: [ 88.441246] CPU: 0 PID: 7263 Comm: sh Not tainted 4.14.195 #0 [ 88.447174] task: 838a1c20 task.stack: 82d5e000 [ 88.451847] $ 0 : 00000000 00000030 deadc0de 83141de4 [ 88.457248] $ 4 : b810a2c4 0000a2c4 83230fd4 00000000 [ 88.462652] $ 8 : 0000000a 00000000 00000001 00000000 [ 88.468055] $12 : 7f8ef318 00000000 00000000 77f802a0 [ 88.473457] $16 : 83230080 00000002 0000001b 83230080 [ 88.478861] $20 : 83a1c3f8 00841000 77f7adb0 ffffff92 [ 88.484263] $24 : 00000fa4 77edd860 [ 88.489665] $28 : 82d5e000 82d5fda8 00000000 83314e60 [ 88.495070] Hi : 00000000 [ 88.498044] Lo : 00000000 [ 88.501040] epc : 80221c28 ioread32+0x8/0x10 [ 88.505671] ra : 83314e60 ath9k_hw_loadnf+0x88/0x520 [ath9k_hw] [ 88.512049] Status: 1000fc03 KERNEL EXL IE [ 88.516369] Cause : 5080801c (ExcCode 07) [ 88.520508] PrId : 00019374 (MIPS 24Kc) [ 88.524556] Modules linked in: ath9k ath9k_common pppoe ppp_async l2tp_ppp cdc_mbim batman_adv ath9k_hw ath sr9700 smsc95xx sierra_net rndis_host qmi_wwan pppox ppp_generic pl2303 nf_conntrack_ipv6 mcs7830 mac80211 kalmia iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm ftdi_sio dm9601 cfg80211 cdc_subset cdc_ncm cdc_ether cdc_eem ax88179_178a asix xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CLASSIFY usbserial usbnet usbhid slhc rtl8150 r8152 pegasus nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack [ 88.597894] libcrc32c kaweth iptable_mangle iptable_filter ipt_ECN ipheth ip_tables hso hid_generic crc_ccitt compat cdc_wdm cdc_acm br_netfilter hid evdev input_core nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 l2tp_netlink l2tp_core udp_tunnel ip6_udp_tunnel xfrm6_mode_tunnel xfrm6_mode_transport xfrm6_mode_beet ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport xfrm4_mode_beet ipcomp esp4 ah4 tunnel6 tunnel4 tun xfrm_user xfrm_ipcomp af_key xfrm_algo sha256_generic sha1_generic jitterentropy_rng drbg md5 hmac echainiv des_generic deflate zlib_inflate zlib_deflate cbc authenc crypto_acompress ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common crc16 mii aead crypto_null cryptomgr crc32c_generic [ 88.671671] crypto_hash [ 88.674292] Process sh (pid: 7263, threadinfo=82d5e000, task=838a1c20, tls=77f81efc) [ 88.682279] Stack : 00008060 00000008 00000200 00000000 00000000 00000000 00000000 00000002 [ 88.690916] 80500000 83230080 82d5fe22 00841000 77f7adb0 00000000 00000000 83156858 [ 88.699553] 00000000 8352fa00 83ad62b0 835302a8 00000000 300a00f8 00000003 82d5fe38 [ 88.708190] 82d5fef4 00000001 77f54dc4 77f80000 77f7adb0 c79fe901 00000000 00000000 [ 88.716828] 80510000 00000002 00841000 77f54dc4 77f80000 801ce4cc 0000000b 41824292 [ 88.725465] ... [ 88.727994] Call Trace: [ 88.730532] [<80221c28>] ioread32+0x8/0x10 [ 88.734765] Code: 00000000 8c820000 0000000f <03e00008> 00000000 08088708 00000000 aca40000 03e00008 [ 88.744846] [ 88.746464] ---[ end trace db226b2de1b69b9e ]--- [ 88.753477] Kernel panic - not syncing: Fatal exception [ 88.759981] Rebooting in 3 seconds.. The "REG_READ(ah, AR_PHY_AGC_CONTROL)" in ath9k_hw_loadnf() does not like being called when the hardware is asleep, leading to this crash. The easiest way to reproduce this is trying to set nf_override while the hardware is down: $ ip link set down dev wlan0 $ echo "-85" > /sys/kernel/debug/ieee80211/phy0/ath9k/nf_override Fixing this crash by waking the hardware up before trying to set the noise floor. Similar to what other ath9k debugfs files do. Tested on a Lima board from 8devices, which has a QCA 4531 chipset. Fixes: b90189759a7f ("ath9k: add noise floor override option") Cc: Simon Wunderlich Signed-off-by: Linus Lüssing Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210209184352.4272-1-linus.luessing@c0d3.blue Signed-off-by: Sasha Levin commit 1ee2b1fa5a4c2162c754f8664237a234b8f458a2 Author: Marco Elver Date: Tue Feb 9 12:27:01 2021 +0100 bpf_lru_list: Read double-checked variable once without lock [ Upstream commit 6df8fb83301d68ea0a0c0e1cbcc790fcc333ed12 ] For double-checked locking in bpf_common_lru_push_free(), node->type is read outside the critical section and then re-checked under the lock. However, concurrent writes to node->type result in data races. For example, the following concurrent access was observed by KCSAN: write to 0xffff88801521bc22 of 1 bytes by task 10038 on cpu 1: __bpf_lru_node_move_in kernel/bpf/bpf_lru_list.c:91 __local_list_flush kernel/bpf/bpf_lru_list.c:298 ... read to 0xffff88801521bc22 of 1 bytes by task 10043 on cpu 0: bpf_common_lru_push_free kernel/bpf/bpf_lru_list.c:507 bpf_lru_push_free kernel/bpf/bpf_lru_list.c:555 ... Fix the data races where node->type is read outside the critical section (for double-checked locking) by marking the access with READ_ONCE() as well as ensuring the variable is only accessed once. Fixes: 3a08c2fd7634 ("bpf: LRU List") Reported-by: syzbot+3536db46dfa58c573458@syzkaller.appspotmail.com Reported-by: syzbot+516acdb03d3e27d91bcd@syzkaller.appspotmail.com Signed-off-by: Marco Elver Signed-off-by: Andrii Nakryiko Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20210209112701.3341724-1-elver@google.com Signed-off-by: Sasha Levin commit 0937d234de7fdd16b7d7ef25f5e418a3940f6a1d Author: Arnd Bergmann Date: Thu Feb 4 17:23:42 2021 +0100 ARM: s3c: fix fiq for clang IAS [ Upstream commit 7f9942c61fa60eda7cc8e42f04bd25b7d175876e ] Building with the clang integrated assembler produces a couple of errors for the s3c24xx fiq support: arch/arm/mach-s3c/irq-s3c24xx-fiq.S:52:2: error: instruction 'subne' can not set flags, but 's' suffix specified subnes pc, lr, #4 @@ return, still have work to do arch/arm/mach-s3c/irq-s3c24xx-fiq.S:64:1: error: invalid symbol redefinition s3c24xx_spi_fiq_txrx: There are apparently two problems: one with extraneous or duplicate labels, and one with old-style opcode mnemonics. Stefan Agner has previously fixed other problems like this, but missed this particular file. Fixes: bec0806cfec6 ("spi_s3c24xx: add FIQ pseudo-DMA support") Cc: Stefan Agner Signed-off-by: Arnd Bergmann Reviewed-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Link: https://lore.kernel.org/r/20210204162416.3030114-1-arnd@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit b776c91e640b761e239e44a09ab70947834e8655 Author: Vincent Knecht Date: Sat Jan 23 11:44:16 2021 +0100 arm64: dts: msm8916: Fix reserved and rfsa nodes unit address [ Upstream commit d5ae2528b0b56cf054b27d48b0cb85330900082f ] Fix `reserved` and `rfsa` unit address according to their reg address Fixes: 7258e10e6a0b ("ARM: dts: msm8916: Update reserved-memory") Signed-off-by: Vincent Knecht Link: https://lore.kernel.org/r/20210123104417.518105-1-vincent.knecht@mailoo.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c6ba6bf9b367811d2c1419875b8f6b3a1a3b9c10 Author: Chen-Yu Tsai Date: Fri Jan 8 22:14:01 2021 +0800 staging: rtl8723bs: wifi_regd.c: Fix incorrect number of regulatory rules [ Upstream commit 61834c967a929f6b4b7fcb91f43fa225cc29aa19 ] The custom regulatory ruleset in the rtl8723bs driver lists an incorrect number of rules: one too many. This results in an out-of-bounds access, as detected by KASAN. This was possible thanks to the newly added support for KASAN on ARMv7. Fix this by filling in the correct number of rules given. KASAN report: ================================================================== BUG: KASAN: global-out-of-bounds in cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211] Read of size 4 at addr bf20c254 by task ip/971 CPU: 2 PID: 971 Comm: ip Tainted: G C 5.11.0-rc2-00020-gf7fe528a7ebe #1 Hardware name: Allwinner sun8i Family [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x9c/0xb4) [] (dump_stack) from [] (print_address_description.constprop.2+0x1dc/0x2dc) [] (print_address_description.constprop.2) from [] (kasan_report+0x1a8/0x1c4) [] (kasan_report) from [] (cfg80211_does_bw_fit_range+0x14/0x4c [cfg80211]) [] (cfg80211_does_bw_fit_range [cfg80211]) from [] (freq_reg_info_regd.part.6+0x108/0x124 [> [] (freq_reg_info_regd.part.6 [cfg80211]) from [] (handle_channel_custom.constprop.12+0x48/> [] (handle_channel_custom.constprop.12 [cfg80211]) from [] (wiphy_apply_custom_regulatory+0> [] (wiphy_apply_custom_regulatory [cfg80211]) from [] (rtw_regd_init+0x60/0x70 [r8723bs]) [] (rtw_regd_init [r8723bs]) from [] (rtw_cfg80211_init_wiphy+0x164/0x1e8 [r8723bs]) [] (rtw_cfg80211_init_wiphy [r8723bs]) from [] (_netdev_open+0xe4/0x28c [r8723bs]) [] (_netdev_open [r8723bs]) from [] (netdev_open+0x60/0x88 [r8723bs]) [] (netdev_open [r8723bs]) from [] (__dev_open+0x178/0x220) [] (__dev_open) from [] (__dev_change_flags+0x258/0x2c4) [] (__dev_change_flags) from [] (dev_change_flags+0x40/0x80) [] (dev_change_flags) from [] (do_setlink+0x538/0x1160) [] (do_setlink) from [] (__rtnl_newlink+0x65c/0xad8) [] (__rtnl_newlink) from [] (rtnl_newlink+0x4c/0x6c) [] (rtnl_newlink) from [] (rtnetlink_rcv_msg+0x1f8/0x454) [] (rtnetlink_rcv_msg) from [] (netlink_rcv_skb+0xc4/0x1e0) [] (netlink_rcv_skb) from [] (netlink_unicast+0x2c8/0x3c4) [] (netlink_unicast) from [] (netlink_sendmsg+0x320/0x5f0) [] (netlink_sendmsg) from [] (____sys_sendmsg+0x320/0x3e0) [] (____sys_sendmsg) from [] (___sys_sendmsg+0xe8/0x12c) [] (___sys_sendmsg) from [] (__sys_sendmsg+0xc0/0x120) [] (__sys_sendmsg) from [] (ret_fast_syscall+0x0/0x58) Exception stack(0xc5693fa8 to 0xc5693ff0) 3fa0: 00000074 c7a39800 00000003 b6cee648 00000000 00000000 3fc0: 00000074 c7a39800 00000001 00000128 78d18349 00000000 b6ceeda0 004f7cb0 3fe0: 00000128 b6cee5e8 aeca151f aec1d746 The buggy address belongs to the variable: rtw_drv_halt+0xf908/0x6b4 [r8723bs] Memory state around the buggy address: bf20c100: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 bf20c180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >bf20c200: 00 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 ^ bf20c280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bf20c300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20210108141401.31741-1-wens@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e2617b72cb6fb13b2775f0ad8dfaa2669765c0ab Author: Guenter Roeck Date: Wed Jan 13 12:20:51 2021 +0100 usb: dwc2: Make "trimming xfer length" a debug message [ Upstream commit 1a9e38cabd80356ffb98c2c88fec528ea9644fd5 ] With some USB network adapters, such as DM96xx, the following message is seen for each maximum size receive packet. dwc2 ff540000.usb: dwc2_update_urb_state(): trimming xfer length This happens because the packet size requested by the driver is 1522 bytes, wMaxPacketSize is 64, the dwc2 driver configures the chip to receive 24*64 = 1536 bytes, and the chip does indeed send more than 1522 bytes of data. Since the event does not indicate an error condition, the message is just noise. Demote it to debug level. Fixes: 7359d482eb4d3 ("staging: HCD files for the DWC2 driver") Tested-by: Nicolas Saenz Julienne Reviewed-by: Douglas Anderson Signed-off-by: Guenter Roeck Signed-off-by: Nicolas Saenz Julienne Link: https://lore.kernel.org/r/20210113112052.17063-4-nsaenzjulienne@suse.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 65be3969b15e213c96279e93e753a77c1982f503 Author: Guenter Roeck Date: Wed Jan 13 12:20:50 2021 +0100 usb: dwc2: Abort transaction after errors with unknown reason [ Upstream commit f74b68c61cbc4b2245022fcce038509333d63f6f ] In some situations, the following error messages are reported. dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown dwc2 ff540000.usb: hcint 0x00000002, intsts 0x04000021 This is sometimes followed by: dwc2 ff540000.usb: dwc2_update_urb_state_abn(): trimming xfer length and then: WARNING: CPU: 0 PID: 0 at kernel/v4.19/drivers/usb/dwc2/hcd.c:2913 dwc2_assign_and_init_hc+0x98c/0x990 The warning suggests that an odd buffer address is to be used for DMA. After an error is observed, the receive buffer may be full (urb->actual_length >= urb->length). However, the urb is still left in the queue unless three errors were observed in a row. When it is queued again, the dwc2 hcd code translates this into a 1-block transfer. If urb->actual_length (ie the total expected receive length) is not DMA-aligned, the buffer pointer programmed into the chip will be unaligned. This results in the observed warning. To solve the problem, abort input transactions after an error with unknown cause if the entire packet was already received. This may be a bit drastic, but we don't really know why the transfer was aborted even though the entire packet was received. Aborting the transfer in this situation is less risky than accepting a potentially corrupted packet. With this patch in place, the 'ChHltd set' and 'trimming xfer length' messages are still observed, but there are no more transfer attempts with odd buffer addresses. Fixes: 151d0cbdbe860 ("usb: dwc2: make the scheduler handle excessive NAKs better") Cc: Boris ARZUR Cc: Douglas Anderson Tested-by: Nicolas Saenz Julienne Reviewed-by: Douglas Anderson Signed-off-by: Guenter Roeck Signed-off-by: Nicolas Saenz Julienne Link: https://lore.kernel.org/r/20210113112052.17063-3-nsaenzjulienne@suse.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 51fc74ce25160b6c92b272562e76d0846b639317 Author: Guenter Roeck Date: Wed Jan 13 12:20:49 2021 +0100 usb: dwc2: Do not update data length if it is 0 on inbound transfers [ Upstream commit 415fa1c7305dedbb345e2cc8ac91769bc1c83f1a ] The DWC2 documentation states that transfers with zero data length should set the number of packets to 1 and the transfer length to 0. This is not currently the case for inbound transfers: the transfer length is set to the maximum packet length. This can have adverse effects if the chip actually does transfer data as it is programmed to do. Follow chip documentation and keep the transfer length set to 0 in that situation. Fixes: 56f5b1cff22a1 ("staging: Core files for the DWC2 driver") Tested-by: Nicolas Saenz Julienne Reviewed-by: Douglas Anderson Signed-off-by: Guenter Roeck Signed-off-by: Nicolas Saenz Julienne Link: https://lore.kernel.org/r/20210113112052.17063-2-nsaenzjulienne@suse.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 639c1ae1dc50bf41aefbd0f3f9d5b59b8953b7e2 Author: Tony Lindgren Date: Wed Dec 30 10:42:30 2020 +0200 ARM: dts: Configure missing thermal interrupt for 4430 [ Upstream commit 44f416879a442600b006ef7dec3a6dc98bcf59c6 ] We have gpio_86 wired internally to the bandgap thermal shutdown interrupt on 4430 like we have it on 4460 according to the TRM. This can be found easily by searching for TSHUT. For some reason the thermal shutdown interrupt was never added for 4430, let's add it. I believe this is needed for the thermal shutdown interrupt handler ti_bandgap_tshut_irq_handler() to call orderly_poweroff(). Fixes: aa9bb4bb8878 ("arm: dts: add omap4430 thermal data") Cc: Carl Philipp Klemm Cc: Daniel Lezcano Cc: Eduardo Valentin Cc: Merlijn Wajer Cc: Pavel Machek Cc: Peter Ujfalusi Cc: Sebastian Reichel Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 49e6938165163e3ca95870dbe0ebb6cc007c4a8b Author: Pan Bian Date: Thu Jan 21 00:10:45 2021 -0800 Bluetooth: Put HCI device if inquiry procedure interrupts [ Upstream commit 28a758c861ff290e39d4f1ee0aa5df0f0b9a45ee ] Jump to the label done to decrement the reference count of HCI device hdev on path that the Inquiry procedure is interrupted. Fixes: 3e13fa1e1fab ("Bluetooth: Fix hci_inquiry ioctl usage") Signed-off-by: Pan Bian Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 39bce4ab06e3874746c08d9a0a0564809e2b32a1 Author: Pan Bian Date: Wed Jan 20 23:34:19 2021 -0800 Bluetooth: drop HCI device reference before return [ Upstream commit 5a3ef03afe7e12982dc3b978f4c5077c907f7501 ] Call hci_dev_put() to decrement reference count of HCI device hdev if fails to duplicate memory. Fixes: 0b26ab9dce74 ("Bluetooth: AMP: Handle Accept phylink command status evt") Signed-off-by: Pan Bian Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 9514233d258fddce3928b86ee8d4611a5597c80b Author: Jack Pham Date: Mon Jan 18 09:46:39 2021 +0100 usb: gadget: u_audio: Free requests only after callback [ Upstream commit 7de8681be2cde9f6953d3be1fa6ce05f9fe6e637 ] As per the kernel doc for usb_ep_dequeue(), it states that "this routine is asynchronous, that is, it may return before the completion routine runs". And indeed since v5.0 the dwc3 gadget driver updated its behavior to place dequeued requests on to a cancelled list to be given back later after the endpoint is stopped. The free_ep() was incorrectly assuming that a request was ready to be freed after calling dequeue which results in a use-after-free in dwc3 when it traverses its cancelled list. Fix this by moving the usb_ep_free_request() call to the callback itself in case the ep is disabled. Fixes: eb9fecb9e69b0 ("usb: gadget: f_uac2: split out audio core") Reported-and-tested-by: Ferry Toth Reviewed-and-tested-by: Peter Chen Acked-by: Felipe Balbi Signed-off-by: Jack Pham Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20210118084642.322510-2-jbrunet@baylibre.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 24cf809170ed7332d4f8ed7d6f6db256d1db9c64 Author: Christophe JAILLET Date: Sun Jan 17 15:26:44 2021 +0100 cpufreq: brcmstb-avs-cpufreq: Fix resource leaks in ->remove() [ Upstream commit 3657f729b6fb5f2c0bf693742de2dcd49c572aa1 ] If 'cpufreq_unregister_driver()' fails, just WARN and continue, so that other resources are freed. Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs") Signed-off-by: Christophe JAILLET [ Viresh: Updated Subject ] Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 84ebee915684a8795684954d3a7accc3c5da8d17 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:29:02 2020 +0100 arm64: dts: exynos: correct PMIC interrupt trigger level on Espresso [ Upstream commit 1fea2eb2f5bbd3fbbe2513d2386b5f6e6db17fd7 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: 9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212903.216728-8-krzk@kernel.org Signed-off-by: Sasha Levin commit e5e3b77cf2a4720ac5d00f1a527b209542b5d404 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:29:01 2020 +0100 arm64: dts: exynos: correct PMIC interrupt trigger level on TM2 [ Upstream commit e98e2367dfb4b6d7a80c8ce795c644124eff5f36 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board") Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20201210212903.216728-7-krzk@kernel.org Signed-off-by: Sasha Levin commit 8b59142d738ae3672c40f2c962524518639558ff Author: Krzysztof Kozlowski Date: Thu Dec 10 22:28:59 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa [ Upstream commit 1ac8893c4fa3d4a34915dc5cdab568a39db5086c ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: 1fed2252713e ("ARM: dts: fix pinctrl for s2mps11-irq on exynos5420-arndale-octa") Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20201210212903.216728-5-krzk@kernel.org Signed-off-by: Sasha Levin commit ef2fe0339ccd540242860932e26341b5f0ba4d52 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:28:58 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Spring [ Upstream commit 77e6a5467cb8657cf8b5e610a30a4c502085e4f9 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: 53dd4138bb0a ("ARM: dts: Add exynos5250-spring device tree") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212903.216728-4-krzk@kernel.org Signed-off-by: Sasha Levin commit 5a8fa84eb9a3fe7c142cb922d9a611325677387f Author: Krzysztof Kozlowski Date: Thu Dec 10 22:28:57 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato [ Upstream commit 437ae60947716bb479e2f32466f49445c0509b1e ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: faaf348ef468 ("ARM: dts: Add board dts file for exynos3250-rinato") Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski Link: https://lore.kernel.org/r/20201210212903.216728-3-krzk@kernel.org Signed-off-by: Sasha Levin commit 61b783b014a8fb669cf587c83fa8500bd3fd6358 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:28:56 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Monk [ Upstream commit 8528cda2b7c667e9cd173aef1a677c71b7d5a096 ] The Samsung PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Fixes: e0cefb3f79d3 ("ARM: dts: add board dts file for Exynos3250-based Monk board") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212903.216728-2-krzk@kernel.org Signed-off-by: Sasha Levin commit 858b98d0ac1fe8eae468e4f00784e93ae1b3be2f Author: Christopher William Snowhill Date: Sat Dec 26 19:12:32 2020 -0800 Bluetooth: Fix initializing response id after clearing struct [ Upstream commit a5687c644015a097304a2e47476c0ecab2065734 ] Looks like this was missed when patching the source to clear the structures throughout, causing this one instance to clear the struct after the response id is assigned. Fixes: eddb7732119d ("Bluetooth: A2MP: Fix not initializing all members") Signed-off-by: Christopher William Snowhill Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 2dfbc49763bf4b1e241becc712752e9f264ed422 Author: Christophe JAILLET Date: Sat Dec 12 10:46:58 2020 +0100 Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function [ Upstream commit 9a39a927be01d89e53f04304ab99a8761e08910d ] Some resource should be released in the error handling path of the probe function, as already done in the remove function. The remove function was fixed in commit 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg") Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") Signed-off-by: Christophe JAILLET Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit f8700bb4b89593070040a11c0f9a91e7b94018ae Author: Eric Biggers Date: Tue Jan 12 11:28:18 2021 -0800 random: fix the RNDRESEEDCRNG ioctl commit 11a0b5e0ec8c13bef06f7414f9e914506140d5cb upstream. The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which doesn't make sense. Reseed it from the input_pool instead. Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG") Cc: stable@vger.kernel.org Cc: linux-crypto@vger.kernel.org Cc: Andy Lutomirski Cc: Jann Horn Cc: Theodore Ts'o Reviewed-by: Jann Horn Acked-by: Ard Biesheuvel Signed-off-by: Eric Biggers Link: https://lore.kernel.org/r/20210112192818.69921-1-ebiggers@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0516cf27f0eafc016455e70e23fc8f6467a0983a Author: Alexander Lobakin Date: Sun Jan 10 11:56:08 2021 +0000 MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section commit 8ac7c87acdcac156670f9920c8acbd84308ff4b1 upstream. MIPS uses its own declaration of rwdata, and thus it should be kept in sync with the asm-generic one. Currently PAGE_ALIGNED_DATA() is missing from the linker script, which emits the following ld warnings: mips-alpine-linux-musl-ld: warning: orphan section `.data..page_aligned' from `arch/mips/kernel/vdso.o' being placed in section `.data..page_aligned' mips-alpine-linux-musl-ld: warning: orphan section `.data..page_aligned' from `arch/mips/vdso/vdso-image.o' being placed in section `.data..page_aligned' Add the necessary declaration, so the mentioned structures will be placed in vmlinux as intended: ffffffff80630580 D __end_once ffffffff80630580 D __start___dyndbg ffffffff80630580 D __start_once ffffffff80630580 D __stop___dyndbg ffffffff80634000 d mips_vdso_data ffffffff80638000 d vdso_data ffffffff80638580 D _gp ffffffff8063c000 T __init_begin ffffffff8063c000 D _edata ffffffff8063c000 T _sinittext -> ffffffff805a4000 D __end_init_task ffffffff805a4000 D __nosave_begin ffffffff805a4000 D __nosave_end ffffffff805a4000 d mips_vdso_data ffffffff805a8000 d vdso_data ffffffff805ac000 D mmlist_lock ffffffff805ac080 D tasklist_lock Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Signed-off-by: Alexander Lobakin Reviewed-by: Kees Cook Reviewed-by: Nathan Chancellor Cc: stable@vger.kernel.org # 4.4+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit a0a4e00a41d58a856d486e8bc8b97c319a6ea4fb Author: Sumit Garg Date: Fri Jan 22 16:35:56 2021 +0530 kdb: Make memory allocations more robust commit 93f7a6d818deef69d0ba652d46bae6fbabbf365c upstream. Currently kdb uses in_interrupt() to determine whether its library code has been called from the kgdb trap handler or from a saner calling context such as driver init. This approach is broken because in_interrupt() alone isn't able to determine kgdb trap handler entry from normal task context. This can happen during normal use of basic features such as breakpoints and can also be trivially reproduced using: echo g > /proc/sysrq-trigger We can improve this by adding check for in_dbg_master() instead which explicitly determines if we are running in debugger context. Cc: stable@vger.kernel.org Signed-off-by: Sumit Garg Link: https://lore.kernel.org/r/1611313556-4004-1-git-send-email-sumit.garg@linaro.org Signed-off-by: Daniel Thompson Signed-off-by: Greg Kroah-Hartman commit 4eb9d709e9f8efd9c9ce84627400f9acb245e770 Author: Nick Desaulniers Date: Fri Feb 5 12:22:18 2021 -0800 vmlinux.lds.h: add DWARF v5 sections commit 3c4fa46b30c551b1df2fb1574a684f68bc22067c upstream. We expect toolchains to produce these new debug info sections as part of DWARF v5. Add explicit placements to prevent the linker warnings from --orphan-section=warn. Compilers may produce such sections with explicit -gdwarf-5, or based on the implicit default version of DWARF when -g is used via DEBUG_INFO. This implicit default changes over time, and has changed to DWARF v5 with GCC 11. .debug_sup was mentioned in review, but without compilers producing it today, let's wait to add it until it becomes necessary. Cc: stable@vger.kernel.org Link: https://bugzilla.redhat.com/show_bug.cgi?id=1922707 Reported-by: Chris Murphy Suggested-by: Fangrui Song Reviewed-by: Nathan Chancellor Reviewed-by: Mark Wielaard Tested-by: Sedat Dilek Signed-off-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit d38b972711fc965af208ab1fc85811a0a30d798d Author: Rong Chen Date: Fri Feb 12 20:52:41 2021 -0800 scripts/recordmcount.pl: support big endian for ARCH sh [ Upstream commit 93ca696376dd3d44b9e5eae835ffbc84772023ec ] The kernel test robot reported the following issue: CC [M] drivers/soc/litex/litex_soc_ctrl.o sh4-linux-objcopy: Unable to change endianness of input file(s) sh4-linux-ld: cannot find drivers/soc/litex/.tmp_gl_litex_soc_ctrl.o: No such file or directory sh4-linux-objcopy: 'drivers/soc/litex/.tmp_mx_litex_soc_ctrl.o': No such file The problem is that the format of input file is elf32-shbig-linux, but sh4-linux-objcopy wants to output a file which format is elf32-sh-linux: $ sh4-linux-objdump -d drivers/soc/litex/litex_soc_ctrl.o | grep format drivers/soc/litex/litex_soc_ctrl.o: file format elf32-shbig-linux Link: https://lkml.kernel.org/r/20210210150435.2171567-1-rong.a.chen@intel.com Link: https://lore.kernel.org/linux-mm/202101261118.GbbYSlHu-lkp@intel.com Signed-off-by: Rong Chen Reported-by: kernel test robot Cc: Yoshinori Sato Cc: Rich Felker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ad48c641e7c344ae7aba243d3056a22eaba71bfd Author: Shyam Prasad N Date: Thu Feb 11 03:26:54 2021 -0800 cifs: Set CIFS_MOUNT_USE_PREFIX_PATH flag on setting cifs_sb->prepath. [ Upstream commit a738c93fb1c17e386a09304b517b1c6b2a6a5a8b ] While debugging another issue today, Steve and I noticed that if a subdir for a file share is already mounted on the client, any new mount of any other subdir (or the file share root) of the same share results in sharing the cifs superblock, which e.g. can result in incorrect device name. While setting prefix path for the root of a cifs_sb, CIFS_MOUNT_USE_PREFIX_PATH flag should also be set. Without it, prepath is not even considered in some places, and output of "mount" and various /proc/<>/*mount* related options can be missing part of the device name. Signed-off-by: Shyam Prasad N Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Sasha Levin commit f885d30f4b08d514203f008c8c4d0df05744c830 Author: Christoph Schemmel Date: Tue Feb 2 09:45:23 2021 +0100 NET: usb: qmi_wwan: Adding support for Cinterion MV31 [ Upstream commit a4dc7eee9106a9d2a6e08b442db19677aa9699c7 ] Adding support for Cinterion MV31 with PID 0x00B7. T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=1e2d ProdID=00b7 Rev=04.14 S: Manufacturer=Cinterion S: Product=Cinterion USB Mobile Broadband S: SerialNumber=b3246eed C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option Signed-off-by: Christoph Schemmel Link: https://lore.kernel.org/r/20210202084523.4371-1-christoph.schemmel@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c11e6ca7a84e92b4933bd2c29ade08c18a47a430 Author: Sameer Pujar Date: Thu Jan 7 10:36:10 2021 +0530 arm64: tegra: Add power-domain for Tegra210 HDA commit 1e0ca5467445bc1f41a9e403d6161a22f313dae7 upstream. HDA initialization is failing occasionally on Tegra210 and following print is observed in the boot log. Because of this probe() fails and no sound card is registered. [16.800802] tegra-hda 70030000.hda: no codecs found! Codecs request a state change and enumeration by the controller. In failure cases this does not seem to happen as STATETS register reads 0. The problem seems to be related to the HDA codec dependency on SOR power domain. If it is gated during HDA probe then the failure is observed. Building Tegra HDA driver into kernel image avoids this failure but does not completely address the dependency part. Fix this problem by adding 'power-domains' DT property for Tegra210 HDA. Note that Tegra186 and Tegra194 HDA do this already. Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support") Depends-on: 96d1f078ff0 ("arm64: tegra: Add SOR power-domain for Tegra210") Cc: Signed-off-by: Sameer Pujar Acked-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 49ee014a2070b209fd73ad96a7a36193dcdd149c Author: Rustam Kovhaev Date: Wed Feb 24 12:00:30 2021 -0800 ntfs: check for valid standard information attribute commit 4dfe6bd94959222e18d512bdf15f6bf9edb9c27c upstream. Mounting a corrupted filesystem with NTFS resulted in a kernel crash. We should check for valid STANDARD_INFORMATION attribute offset and length before trying to access it Link: https://lkml.kernel.org/r/20210217155930.1506815-1-rkovhaev@gmail.com Link: https://syzkaller.appspot.com/bug?extid=c584225dabdea2f71969 Signed-off-by: Rustam Kovhaev Reported-by: syzbot+c584225dabdea2f71969@syzkaller.appspotmail.com Tested-by: syzbot+c584225dabdea2f71969@syzkaller.appspotmail.com Acked-by: Anton Altaparmakov Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit afd4a33779bd37cf8b566ef1fbbbac06366c61f6 Author: Stefan Ursella Date: Wed Feb 10 15:07:11 2021 +0100 usb: quirks: add quirk to start video capture on ELMO L-12F document camera reliable commit 1ebe718bb48278105816ba03a0408ecc2d6cf47f upstream. Without this quirk starting a video capture from the device often fails with kernel: uvcvideo: Failed to set UVC probe control : -110 (exp. 34). Signed-off-by: Stefan Ursella Link: https://lore.kernel.org/r/20210210140713.18711-1-stefan.ursella@wolfvision.net Cc: stable Signed-off-by: Greg Kroah-Hartman commit 00022873fdc1a304fd89016d227e3781f413dfbd Author: Will McVicker Date: Sat Dec 5 00:48:48 2020 +0000 HID: make arrays usage and value to be the same commit ed9be64eefe26d7d8b0b5b9fa3ffdf425d87a01f upstream. The HID subsystem allows an "HID report field" to have a different number of "values" and "usages" when it is allocated. When a field struct is created, the size of the usage array is guaranteed to be at least as large as the values array, but it may be larger. This leads to a potential out-of-bounds write in __hidinput_change_resolution_multipliers() and an out-of-bounds read in hidinput_count_leds(). To fix this, let's make sure that both the usage and value arrays are the same size. Cc: stable@vger.kernel.org Signed-off-by: Will McVicker Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman