- 15 Oct, 2022 20 commits
-
-
Johannes Berg authored
commit aebe9f46 upstream. In the copy code of the elements, we do the following calculation to reach the end of the MBSSID element: /* copy the IEs after MBSSID */ cpy_len = mbssid[1] + 2; This looks fine, however, cpy_len is a u8, the same as mbssid[1], so the addition of two can overflow. In this case the subsequent memcpy() will overflow the allocated buffer, since it copies 256 bytes too much due to the way the allocation and memcpy() sizes are calculated. Fix this by using size_t for the cpy_len variable. This fixes CVE-2022-41674. Reported-by:
Soenke Huster <shuster@seemoo.tu-darmstadt.de> Tested-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason A. Donenfeld authored
commit 748bc4dd upstream. Previously, the fast pool was dumped into the main pool periodically in the fast pool's hard IRQ handler. This worked fine and there weren't problems with it, until RT came around. Since RT converts spinlocks into sleeping locks, problems cropped up. Rather than switching to raw spinlocks, the RT developers preferred we make the transformation from originally doing: do_some_stuff() spin_lock() do_some_other_stuff() spin_unlock() to doing: do_some_stuff() queue_work_on(some_other_stuff_worker) This is an ordinary pattern done all over the kernel. However, Sherry noticed a 10% performance regression in qperf TCP over a 40gbps InfiniBand card. Quoting her message: > MT27500 Family [ConnectX-3] cards: > Infiniband device 'mlx4_0' port 1 status: > default gid: fe80:0000:0000:0000:0010:e000:0178:9eb1 > base lid: 0x6 > sm lid: 0x1 > state: 4: ACTIVE > phys state: 5: LinkUp > rate: 40 Gb/sec (4X QDR) > link_layer: InfiniBand > > Cards are configured with IP addresses on private subnet for IPoIB > performance testing. > Regression identified in this bug is in TCP latency in this stack as reported > by qperf tcp_lat metric: > > We have one system listen as a qperf server: > [root@yourQperfServer ~]# qperf > > Have the other system connect to qperf server as a client (in this > case, it’s X7 server with Mellanox card): > [root@yourQperfClient ~]# numactl -m0 -N0 qperf 20.20.20.101 -v -uu -ub --time 60 --wait_server 20 -oo msg_size:4K:1024K:*2 tcp_lat Rather than incur the scheduling latency from queue_work_on, we can instead switch to running on the next timer tick, on the same core. This also batches things a bit more -- once per jiffy -- which is okay now that mix_interrupt_randomness() can credit multiple bits at once. Reported-by:
Sherry Yang <sherry.yang@oracle.com> Tested-by:
Paul Webb <paul.x.webb@oracle.com> Cc: Sherry Yang <sherry.yang@oracle.com> Cc: Phillip Goerl <phillip.goerl@oracle.com> Cc: Jack Vogel <jack.vogel@oracle.com> Cc: Nicky Veitch <nicky.veitch@oracle.com> Cc: Colm Harrington <colm.harrington@oracle.com> Cc: Ramanan Govindarajan <ramanan.govindarajan@oracle.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Tejun Heo <tj@kernel.org> Cc: Sultan Alsawaf <sultan@kerneltoast.com> Cc: stable@vger.kernel.org Fixes: 58340f8e ("random: defer fast pool mixing to worker") Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Jason A. Donenfeld authored
commit 9ee0507e upstream. In order to avoid reading and dirtying two cache lines on every IRQ, move the work_struct to the bottom of the fast_pool struct. add_ interrupt_randomness() always touches .pool and .count, which are currently split, because .mix pushes everything down. Instead, move .mix to the bottom, so that .pool and .count are always in the first cache line, since .mix is only accessed when the pool is full. Fixes: 58340f8e ("random: defer fast pool mixing to worker") Reviewed-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Giovanni Cabiddu authored
commit 9c5f21b1 upstream. This reverts commit e48767c1 . In an attempt to resolve a set of warnings reported by the static analyzer Smatch, the reverted commit improperly reduced the sizes of the DMA mappings used for the input and output parameters for both RSA and DH creating a mismatch (map size=8 bytes, unmap size=64 bytes). This issue is reported when CONFIG_DMA_API_DEBUG is selected, when the crypto self test is run. The function dma_unmap_single() reports a warning similar to the one below, saying that the `device driver frees DMA memory with different size`. DMA-API: 4xxx 0000:06:00.0: device driver frees DMA memory with different size [device address=0x0000000123206c80] [map size=8 bytes] [unmap size=64 bytes] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:973 check_unmap+0x3d0/0x8c0\ ... Call Trace: <IRQ> debug_dma_unmap_page+0x5c/0x60 qat_dh_cb+0xd7/0x110 [intel_qat] qat_alg_asym_callback+0x1a/0x30 [intel_qat] adf_response_handler+0xbd/0x1a0 [intel_qat] tasklet_action_common.constprop.0+0xcd/0xe0 __do_softirq+0xf8/0x30c __irq_exit_rcu+0xbf/0x140 common_interrupt+0xb9/0xd0 </IRQ> <TASK> The original commit was correct. Cc: <stable@vger.kernel.org> Reported-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by:
-
Nathan Lynch authored
commit f88aabad upstream. At the time this was submitted by Leonardo, I confirmed -- or thought I had confirmed -- with PowerVM partition firmware development that the following RTAS functions: - ibm,get-xive - ibm,int-off - ibm,int-on - ibm,set-xive were safe to call on multiple CPUs simultaneously, not only with respect to themselves as indicated by PAPR, but with arbitrary other RTAS calls: https://lore.kernel.org/linuxppc-dev/875zcy2v8o.fsf@linux.ibm.com/ Recent discussion with firmware development makes it clear that this is not true, and that the code in commit b664db8e ("powerpc/rtas: Implement reentrant rtas call") is unsafe, likely explaining several strange bugs we've seen in internal testing involving DLPAR and LPM. These scenarios use ibm,configure-connector, whose internal state can be corrupted by the concurrent use of the "reentrant" functions, leading to symptoms like endless busy statuses from RTAS. Fixes: b664db8e ("powerpc/rtas: Implement reentrant rtas call") Cc: stable@vger.kernel.org # v5.8+ Signed-off-by:
Nathan Lynch <nathanl@linux.ibm.com> Reviewed-by:
Laurent Dufour <laurent.dufour@fr.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220907220111.223267-1-nathanl@linux.ibm.com Signed-off-by:
-
Andy Shevchenko authored
commit 7a84e735 upstream. This reverts commit 0f010171. As pointed out by Ferry this breaks Dual Role support on Intel Merrifield platforms. Fixes: 0f010171 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present") Reported-by:
Ferry Toth <fntoth@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Ferry Toth <fntoth@gmail.com> # for Merrifield Reviewed-by:
Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20220927155332.10762-3-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Andy Shevchenko authored
Revert "USB: fixup for merge issue with "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"" commit 2adc960c upstream. This reverts commit 8bd6b8c4. Prerequisite revert for the reverting of the original commit 0f010171. Fixes: 8bd6b8c4 ("USB: fixup for merge issue with "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"") Fixes: 0f010171 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present") Reported-by:
-
Frank Wunderlich authored
commit eee48781 upstream. Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2. Signed-off-by:
Frank Wunderlich <frank-w@public-files.de> Cc: stable@vger.kernel.org Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Linus Torvalds authored
commit 6022f210 upstream. The passthrough structure is declared off of the stack, so it needs to be set to zero before copied back to userspace to prevent any unintentional data leakage. Switch things to be statically allocated which will fill the unused fields with 0 automatically. Link: https://lore.kernel.org/r/YxrjN3OOw2HHl9tx@kroah.com Cc: stable@kernel.org Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Reported-by:
hdthky <hdthky0@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Orlando Chamberlain authored
commit bab715bd upstream. It turns out Apple doesn't capitalise the "mini" in "Macmini" in DMI, which is inconsistent with other model line names. Correct the capitalisation of Macmini in the quirk for skipping loading platform certs on T2 Macs. Currently users get: ------------[ cut here ]------------ [Firmware Bug]: Page fault caused by firmware at PA: 0xffffa30640054000 WARNING: CPU: 1 PID: 8 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x55/0xe0 Modules linked in: CPU: 1 PID: 8 Comm: kworker/u12:0 Not tainted 5.18.14-arch1-2-t2 #1 4535eb3fc40fd08edab32a509fbf4c9bc52d111e Hardware name: Apple Inc. Macmini8,1/Mac-7BA5B2DFE22DDD8C, BIOS 1731.120.10.0.0 (iBridge: 19.16.15071.0.0,0) 04/24/2022 Workqueue: efi_rts_wq efi_call_rts ... ---[ end trace 0000000000000000 ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list Fixes: 155ca952 ("efi: Do not import certificates from UEFI Secure Boot for T2 Macs") Cc: stable@vger.kernel.org Cc: Aditya Garg <gargaditya08@live.com> Tested-by:
Samuel Jiang <chyishian.jiang@gmail.com> Signed-off-by:
Orlando Chamberlain <redecorating@protonmail.com> Signed-off-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
-
Takashi Iwai authored
commit 225f6e1b upstream. HP Zbook Firefly 14 G9 model (103c:8abb) requires yet another binding with CS35L41 codec, but with a slightly different configuration. It's over spi1 instead of spi0. Create a new fixup entry for that. Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220929061455.13355-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 56e696c0 upstream. Hans reported that his Sony VAIO VPX11S1E showed the broken sound behavior at the start of the stream for a couple of seconds, and it turned out that the position_fix=1 option fixes the issue. It implies that the position reporting is inaccurate, and very likely hitting on all Poulsbo devices. The patch applies the workaround for Poulsbo generically to switch to LPIB mode instead of the default position buffer. Reported-and-tested-by:
Hans de Goede <hdegoede@redhat.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/3e8697e1-87c6-7a7b-d2e8-b21f1d2f181b@redhat.com Link: https://lore.kernel.org/r/20221001142124.7241-1-tiwai@suse.de Signed-off-by:
-
Jason A. Donenfeld authored
commit e78a802a upstream. Since the most that's mixed into the pool is sizeof(long)*2, don't credit more than that many bytes of entropy. Fixes: e3e33fc2 ("random: do not use input pool from hard IRQs") Cc: stable@vger.kernel.org Signed-off-by:
-
Jason A. Donenfeld authored
commit cd4f24ae upstream. Prior to 5.6, when /dev/random was opened with O_NONBLOCK, it would return -EAGAIN if there was no entropy. When the pools were unified in 5.6, this was lost. The post 5.6 behavior of blocking until the pool is initialized, and ignoring O_NONBLOCK in the process, went unnoticed, with no reports about the regression received for two and a half years. However, eventually this indeed did break somebody's userspace. So we restore the old behavior, by returning -EAGAIN if the pool is not initialized. Unlike the old /dev/random, this can only occur during early boot, after which it never blocks again. In order to make this O_NONBLOCK behavior consistent with other expectations, also respect users reading with preadv2(RWF_NOWAIT) and similar. Fixes: 30c08efe ("random: make /dev/random be almost like /dev/urandom") Reported-by:
Guozihua <guozihua@huawei.com> Reported-by:
Zhongguohua <zhongguohua1@huawei.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Andrew Lutomirski <luto@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Rishabh Bhatnagar authored
commit 61ce339f upstream. If swiotlb is force enabled dma_max_mapping_size ends up calling swiotlb_max_mapping_size which takes into account the min align mask for the device. Set the min align mask for nvme driver before calling dma_max_mapping_size while calculating max hw sectors. Signed-off-by:
Rishabh Bhatnagar <risbhat@amazon.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Hu Weiwen authored
commit 7cb99947 upstream. Clear O_TRUNC from the flags sent in the MDS create request. `atomic_open' is called before permission check. We should not do any modification to the file here. The caller will do the truncation afterward. Fixes: 124e68e7 ("ceph: file operations") Signed-off-by:
Hu Weiwen <sehuww@mail.scut.edu.cn> Reviewed-by:
Xiubo Li <xiubli@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> [Xiubo: fixed a trivial conflict for 5.19 backport] Signed-off-by:
-
Ryusuke Konishi authored
commit 723ac751 upstream. If creation or finalization of a checkpoint fails due to anomalies in the checkpoint metadata on disk, a kernel warning is generated. This patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted with panic_on_warn, does not panic. A nilfs_error is appropriate here to handle the abnormal filesystem condition. This also replaces the detected error codes with an I/O error so that neither of the internal error codes is returned to callers. Link: https://lkml.kernel.org/r/20220929123330.19658-1-konishi.ryusuke@gmail.com Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@gmail.com> Reported-by: syzbot+fbb3e0b24e8dae5a16ee@syzkaller.appspotmail.com Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Ryusuke Konishi authored
commit d0d51a97 upstream. If nilfs_attach_log_writer() failed to create a log writer thread, it frees a data structure of the log writer without any cleanup. After commit e912a5b6 ("nilfs2: use root object to get ifile"), this causes a leak of struct nilfs_root, which started to leak an ifile metadata inode and a kobject on that struct. In addition, if the kernel is booted with panic_on_warn, the above ifile metadata inode leak will cause the following panic when the nilfs2 kernel module is removed: kmem_cache_destroy nilfs2_inode_cache: Slab cache still has objects when called from nilfs_destroy_cachep+0x16/0x3a [nilfs2] WARNING: CPU: 8 PID: 1464 at mm/slab_common.c:494 kmem_cache_destroy+0x138/0x140 ... RIP: 0010:kmem_cache_destroy+0x138/0x140 Code: 00 20 00 00 e8 a9 55 d8 ff e9 76 ff ff ff 48 8b 53 60 48 c7 c6 20 70 65 86 48 c7 c7 d8 69 9c 86 48 8b 4c 24 28 e8 ef 71 c7 00 <0f> 0b e9 53 ff ff ff c3 48 81 ff ff 0f 00 00 77 03 31 c0 c3 53 48 ... Call Trace: <TASK> ? nilfs_palloc_freev.cold.24+0x58/0x58 [nilfs2] nilfs_destroy_cachep+0x16/0x3a [nilfs2] exit_nilfs_fs+0xa/0x1b [nilfs2] __x64_sys_delete_module+0x1d9/0x3a0 ? __sanitizer_cov_trace_pc+0x1a/0x50 ? syscall_trace_enter.isra.19+0x119/0x190 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK> Kernel panic - not syncing: panic_on_warn set ... This patch fixes these issues by calling nilfs_detach_log_writer() cleanup function if spawning the log writer thread fails. Link: https://lkml.kernel.org/r/20221007085226.57667-1-konishi.ryusuke@gmail.com Fixes: e912a5b6 ("nilfs2: use root object to get ifile") Signed-off-by:
-
Ryusuke Konishi authored
commit d325dc6e upstream. If the beginning of the inode bitmap area is corrupted on disk, an inode with the same inode number as the root inode can be allocated and fail soon after. In this case, the subsequent call to nilfs_clear_inode() on that bogus root inode will wrongly decrement the reference counter of struct nilfs_root, and this will erroneously free struct nilfs_root, causing kernel oopses. This fixes the problem by changing nilfs_new_inode() to skip reserved inode numbers while repairing the inode bitmap. Link: https://lkml.kernel.org/r/20221003150519.39789-1-konishi.ryusuke@gmail.com Signed-off-by:
Khalid Masum <khalid.masum.92@gmail.com> Tested-by:
-
Ryusuke Konishi authored
commit 21a87d88 upstream. If the i_mode field in inode of metadata files is corrupted on disk, it can cause the initialization of bmap structure, which should have been called from nilfs_read_inode_common(), not to be called. This causes a lockdep warning followed by a NULL pointer dereference at nilfs_bmap_lookup_at_level(). This patch fixes these issues by adding a missing sanitiy check for the i_mode field of metadata file's inode. Link: https://lkml.kernel.org/r/20221002030804.29978-1-konishi.ryusuke@gmail.com Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by:
-
- 12 Oct, 2022 20 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20221010070333.676316214@linuxfoundation.org Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Link: https://lore.kernel.org/r/20221010191212.200768859@linuxfoundation.org Tested-by:
Slade Watkins <srw@sladewatkins.net> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
Sasha Levin authored
This reverts commit 67c830a6. Which was upstream commit 255584b1 . Reported as causing boot failures. Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Tetsuo Handa authored
commit deee93d1 upstream. syzbot is reporting attempt to schedule hdev->cmd_work work from system_wq WQ into hdev->workqueue WQ which is under draining operation [1], for commit c8efcc25 ("workqueue: allow chained queueing during destruction") does not allow such operation. The check introduced by commit 877afada ("Bluetooth: When HCI work queue is drained, only queue chained work") was incomplete. Use hdev->workqueue WQ when queuing hdev->{cmd,ncmd}_timer works because hci_{cmd,ncmd}_timeout() calls queue_work(hdev->workqueue). Also, protect the queuing operation with RCU read lock in order to avoid calling queue_delayed_work() after cancel_delayed_work() completed. Link: https://syzkaller.appspot.com/bug?extid=243b7d89777f90f7613b [1] Reported-by:
syzbot <syzbot+243b7d89777f90f7613b@syzkaller.appspotmail.com> Signed-off-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
Jules Irenge authored
commit 9fad7fe5 upstream. Sparse reported a warning at bpf_map_free_kptrs() "warning: Using plain integer as NULL pointer" During the process of fixing this warning, it was discovered that the current code erroneously writes to the pointer variable instead of deferencing and writing to the actual kptr. Hence, Sparse tool accidentally helped to uncover this problem. Fix this by doing WRITE_ONCE(*p, 0) instead of WRITE_ONCE(p, 0). Note that the effect of this bug is that unreferenced kptrs will not be cleared during check_and_free_fields. It is not a problem if the clearing is not done during map_free stage, as there is nothing to free for them. Fixes: 14a324f6 ("bpf: Wire up freeing of referenced kptr") Signed-off-by:
Jules Irenge <jbi.octave@gmail.com> Link: https://lore.kernel.org/r/Yxi3pJaK6UDjVJSy@playground Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Daniel Golle authored
commit ae3ed15d upstream. Setting ib1 state to MTK_FOE_STATE_UNBIND in __mtk_foe_entry_clear routine as done by commit 0e80707d ("net: ethernet: mtk_eth_soc: fix typo in __mtk_foe_entry_clear") breaks flow offloading, at least on older MTK_NETSYS_V1 SoCs, OpenWrt users have confirmed the bug on MT7622 and MT7621 systems. Felix Fietkau suggested to use MTK_FOE_STATE_INVALID instead which works well on both, MTK_NETSYS_V1 and MTK_NETSYS_V2. Tested on MT7622 (Linksys E8450) and MT7986 (BananaPi BPI-R3). Suggested-by:
Felix Fietkau <nbd@nbd.name> Fixes: 0e80707d ("net: ethernet: mtk_eth_soc: fix typo in __mtk_foe_entry_clear") Fixes: 33fc42de ("net: ethernet: mtk_eth_soc: support creating mac address based offload entries") Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/YzY+1Yg0FBXcnrtc@makrotopia.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Kumar Kartikeya Dwivedi authored
commit 8addbfc7 upstream. This has been enabled for unprivileged programs for only one kernel release, hence the expected annoyances due to this move are low. Users using ringbuf can stick to non-dynptr APIs. The actual use cases dynptr is meant to serve may not make sense in unprivileged BPF programs. Hence, gate these helpers behind CAP_BPF and limit use to privileged BPF programs. Fixes: 263ae152 ("bpf: Add bpf_dynptr_from_mem for local dynptrs") Fixes: bc34dee6 ("bpf: Dynptr support for ring buffers") Fixes: 13bbbfbe ("bpf: Add bpf_dynptr_read and bpf_dynptr_write") Fixes: 34d4ef57 ("bpf: Add dynptr data slices") Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20220921143550.30247-1-memxor@gmail.com Acked-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
commit 766279a8 upstream. The use of strncpy() is considered deprecated for NUL-terminated strings[1]. Replace strncpy() with strscpy_pad(), to keep existing pad-behavior of strncpy, similarly to commit 08de420a ("rpmsg: glink: Replace strncpy() with strscpy_pad()"). This fixes W=1 warning: In function ‘qcom_glink_rx_close’, inlined from ‘qcom_glink_work’ at ../drivers/rpmsg/qcom_glink_native.c:1638:4: drivers/rpmsg/qcom_glink_native.c:1549:17: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] 1549 | strncpy(chinfo.name, channel->name, sizeof(chinfo.name)); [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220519073330.7187-1-krzysztof.kozlowski@linaro.org Signed-off-by:
Andrew Chernyakov <acherniakov@astralinux.ru> Signed-off-by:
-
Brian Norris authored
commit e9233917 upstream. This loop intends to retry a max of 10 times, with some implicit termination based on the SD_{R,}OCR_S18A bit. Unfortunately, the termination condition depends on the value reported by the SD card (*rocr), which may or may not correctly reflect what we asked it to do. Needless to say, it's not wise to rely on the card doing what we expect; we should at least terminate the loop regardless. So, check both the input and output values, so we ensure we will terminate regardless of the SD card behavior. Note that SDIO learned a similar retry loop in commit 0797e5f1 ("mmc: core: Fixup signal voltage switch"), but that used the 'ocr' result, and so the current pre-terminating condition looks like: rocr & ocr & R4_18V_PRESENT (i.e., it doesn't have the same bug.) This addresses a number of crash reports seen on ChromeOS that look like the following: ... // lots of repeated: ... <4>[13142.846061] mmc1: Skipping voltage switch <4>[13143.406087] mmc1: Skipping voltage switch <4>[13143.964724] mmc1: Skipping voltage switch <4>[13144.526089] mmc1: Skipping voltage switch <4>[13145.086088] mmc1: Skipping voltage switch <4>[13145.645941] mmc1: Skipping voltage switch <3>[13146.153969] INFO: task halt:30352 blocked for more than 122 seconds. ... Fixes: f2119df6 ("mmc: sd: add support for signal voltage switch procedure") Cc: <stable@vger.kernel.org> Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
ChanWoo Lee authored
commit e4272664 upstream. SD_ROCR_S18A is already defined and is used to check the rocr value, so let's replace with already defined values for readability. Signed-off-by:
ChanWoo Lee <cw9316.lee@samsung.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220706004840.24812-1-cw9316.lee@samsung.com Signed-off-by:
-
Mario Limonciello authored
commit 0ea76c40 upstream. Asus UM325UAZ has GPIO 18 programmed as both an interrupt and a wake source, but confirmed with internal team on this design this pin is floating and shouldn't have been programmed. This causes lots of spurious IRQs on the system and horrendous battery life. Add a quirk to ignore attempts to program this pin on this system. Reported-by:
Pavel Krc <reg.krn@pkrc.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216208 Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Mario Limonciello authored
commit 6b6af7bd upstream. gpiolib-acpi already had support for ignoring a pin for wakeup, but if an OEM configures a floating pin as an interrupt source then stopping it from being a wakeup won't do much good to stop the interrupt storm. Add support for a module parameter and quirk infrastructure to ignore interrupts as well. Signed-off-by:
-
Johan Hovold authored
commit 7bd7ad3c upstream. The 300 bps rate of SIO devices has been mapped to 9600 bps since 2003... Let's fix the regression. Cc: stable@vger.kernel.org Signed-off-by:
-
Tadeusz Struk authored
commit a659daf6 upstream. Syzbot found an issue in usbmon module, where the user space client can corrupt the monitor's internal memory, causing the usbmon module to crash the kernel with segfault, UAF, etc. The reproducer mmaps the /dev/usbmon memory to user space, and overwrites it with arbitrary data, which causes all kinds of issues. Return an -EPERM error from mon_bin_mmap() if the flag VM_WRTIE is set. Also clear VM_MAYWRITE to make it impossible to change it to writable later. Cc: "Dmitry Vyukov" <dvyukov@google.com> Cc: stable <stable@kernel.org> Fixes: 6f23ee1f ("USB: add binary API to usbmon") Suggested-by: PaX Team <pageexec@freemail.hu> # for the VM_MAYRITE portion Link: https://syzkaller.appspot.com/bug?id=2eb1f35d6525fa4a74d75b4244971e5b1411c95a Reported-by: syzbot+23f57c5ae902429285d7@syzkaller.appspotmail.com Signed-off-by:
Tadeusz Struk <tadeusz.struk@linaro.org> Link: https://lore.kernel.org/r/20220919215957.205681-1-tadeusz.struk@linaro.org Signed-off-by:
-
Zhang Qilong authored
[ Upstream commit e2062df7 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. Fixes: 17f88151 ("i2c: davinci: Add PM Runtime Support") Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Reviewed-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Al Viro authored
[ Upstream commit 06bbaa6d ] passing kmap_local_page() result to __kernel_write() is unsafe - random ->write_iter() might (and 9p one does) get unhappy when passed ITER_KVEC with pointer that came from kmap_local_page(). Fix by providing a variant of __kernel_write() that takes an iov_iter from caller (__kernel_write() becomes a trivial wrapper) and adding dump_emit_page() that parallels dump_emit(), except that instead of __kernel_write() it uses __kernel_write_iter() with ITER_BVEC source. Fixes: 3159ed57 "fs/coredump: use kmap_local_page()" Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Kan Liang authored
[ Upstream commit 24919fde ] For some Alder Lake N machine, the below unchecked MSR access error may be triggered. [ 0.088017] rcu: Hierarchical SRCU implementation. [ 0.088017] unchecked MSR access error: WRMSR to 0x38f (tried to write 0x0001000f0000003f) at rIP: 0xffffffffb5684de8 (native_write_msr+0x8/0x30) [ 0.088017] Call Trace: [ 0.088017] <TASK> [ 0.088017] __intel_pmu_enable_all.constprop.46+0x4a/0xa0 The Alder Lake N only has e-cores. The X86_FEATURE_HYBRID_CPU flag is not set. The perf cannot retrieve the correct CPU type via get_this_hybrid_cpu_type(). The model specific get_hybrid_cpu_type() is hardcode to p-core. The wrong CPU type is given to the PMU of the Alder Lake N. Since Alder Lake N isn't in fact a hybrid CPU, remove ALDERLAKE_N from the rest of {ALDER,RAPTOP}LAKE and create a non-hybrid PMU setup. The differences between Gracemont and the previous Tremont are, - Number of GP counters - Load and store latency Events - PEBS event_constraints - Instruction Latency support - Data source encoding - Memory access latency encoding Fixes: c2a960f7 ("perf/x86: Add new Alder Lake and Raptor Lake support") Reported-by:
Jianfeng Gao <jianfeng.gao@intel.com> Suggested-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Kan Liang <kan.liang@linux.intel.com> Signed-off-by:
-
Dmytro Laktyushkin authored
[ Upstream commit dcc2527d ] [Why & How] Update after new measurment came in Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
Wayne Lin <wayne.lin@amd.com> Signed-off-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Cruise Hung authored
[ Upstream commit 20c6168b ] [Why] When USB4 DP link training failed and fell back to lower link rate, the time slot calculation uses the verified_link_cap. And the verified_link_cap was not updated to the new one. It caused the wrong VC payload time-slot was allocated. [How] Updated verified_link_cap with the new one from cur_link_settings after the LT completes successfully. Reviewed-by:
Cruise Hung <Cruise.Hung@amd.com> Tested-by:
-
zhikzhai authored
[ Upstream commit 65fbfb02 ] [why] We have minimal pipe split transition method to avoid pipe allocation outage.However, this method will invoke audio setup which cause audio output stuck once pipe reallocate. [how] skip audio setup for pipelines which audio stream has been enabled Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
zhikzhai <zhikai.zhai@amd.com> Tested-by:
-
Hugo Hu authored
[ Upstream commit 52bb2149 ] [Why] The desktop plane and full-screen game plane may have different gamut remap coefficients, if switching between desktop and full-screen game without updating the gamut remap will cause incorrect color. [How] Update gamut remap if planes change. Reviewed-by:
Hugo Hu <hugo.hu@amd.com> Tested-by:
-
