- Jan 24, 2023
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20230122150232.736358800@linuxfoundation.org Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Link: https://lore.kernel.org/r/20230123094918.977276664@linuxfoundation.org Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Kelsey Steele <kelseysteele@linux.microsoft.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jens Axboe authored
commit 5c61795e upstream. This debug statement was never meant to go into the upstream release, kill it off before it ends up in a release. It was just part of the testing for the initial version of the patch. Fixes: 2ec33a6c ("io_uring/rw: ensure kiocb_end_write() is always called") Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Jens Axboe authored
commit 2ec33a6c upstream. A previous commit moved the notifications and end-write handling, but it is now missing a few spots where we also want to call both of those. Without that, we can potentially be missing file notifications, and more importantly, have an imbalance in the super_block writers sem accounting. Fixes: b000145e ("io_uring/rw: defer fsnotify calls to task context") Reported-by:
Dave Chinner <david@fromorbit.com> Link: https://lore.kernel.org/all/20221010050319.GC2703033@dread.disaster.area/ Signed-off-by:
-
Pavel Begunkov authored
commit c0737fa9 upstream. We have re-polling for partial IO, so a request can be polled twice. If it used two poll entries the first time then on the second io_arm_poll_handler() it will find the old apoll entry and NULL kmalloc()'ed second entry, i.e. apoll->double_poll, so leaking it. Fixes: 10c87333 ("io_uring: allow re-poll if we made progress") Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/fee2452494222ecc7f1f88c8fb659baef971414a.1655852245.git.asml.silence@gmail.com Signed-off-by:
-
Alviro Iskandar Setiawan authored
commit 0d7c1153 upstream. In io_recv(), if import_single_range() fails, the @flags variable is uninitialized, then it will goto out_free. After the goto, the compiler doesn't know that (ret < min_ret) is always true, so it thinks the "if ((flags & MSG_WAITALL) ..." path could be taken. The complaint comes from gcc-9 (Debian 9.3.0-22) 9.3.0: ``` fs/io_uring.c:5238 io_recvfrom() error: uninitialized symbol 'flags' ``` Fix this by bypassing the @ret and @flags check when import_single_range() fails. Reasons: 1. import_single_range() only returns -EFAULT when it fails. 2. At that point, @flags is uninitialized and shouldn't be read. Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reported-by:
"Chen, Rong A" <rong.a.chen@intel.com> Link: https://lore.gnuweeb.org/timl/d33bb5a9-8173-f65b-f653-51fc0681c6d6@intel.com/ Cc: Pavel Begunkov <asml.silence@gmail.com> Suggested-by:
Ammar Faizi <ammarfaizi2@gnuweeb.org> Fixes: 7297ce3d ("io_uring: improve send/recv error handling") Signed-off-by:
Alviro Iskandar Setiawan <alviro.iskandar@gmail.com> Signed-off-by:
-
Hugh Dickins authored
commit ab0c3f12 upstream. uprobe_write_opcode() uses collapse_pte_mapped_thp() to restore huge pmd, when removing a breakpoint from hugepage text: vma->anon_vma is always set in that case, so undo the prohibition. And MADV_COLLAPSE ought to be able to collapse some page tables in a vma which happens to have anon_vma set from CoWing elsewhere. Is anon_vma lock required? Almost not: if any page other than expected subpage of the non-anon huge page is found in the page table, collapse is aborted without making any change. However, it is possible that an anon page was CoWed from this extent in another mm or vma, in which case a concurrent lookup might look here: so keep it away while clearing pmd (but perhaps we shall go back to using pmd_lock() there in future). Note that collapse_pte_mapped_thp() is exceptional in freeing a page table without having cleared its ptes: I'm uneasy about that, and had thought pte_clear()ing appropriate; but exclusive i_mmap lock does fix the problem, and we would have to move the mmu_notification if clearing those ptes. What this fixes is not a dangerous instability. But I suggest Cc stable because uprobes "healing" has regressed in that way, so this should follow 8d3c106e into those stable releases where it was backported (and may want adjustment there - I'll supply backports as needed). Link: https://lkml.kernel.org/r/b740c9fb-edba-92ba-59fb-7a5592e5dfc@google.com Fixes: 8d3c106e ("mm/khugepaged: take the right locks for page table retraction") Signed-off-by:
Hugh Dickins <hughd@google.com> Acked-by:
David Hildenbrand <david@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: Yang Shi <shy828301@gmail.com> Cc: Zach O'Keefe <zokeefe@google.com> Cc: Song Liu <songliubraving@fb.com> Cc: <stable@vger.kernel.org> [5.4+] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Stephan Gerhold authored
commit 599d41fb upstream. APR should not fail if the service device tree node does not have the qcom,protection-domain property, since this functionality does not exist on older platforms such as MSM8916 and MSM8996. Ignore -EINVAL (returned when the property does not exist) to fix a regression on 6.2-rc1 that prevents audio from working: qcom,apr remoteproc0:smd-edge.apr_audio_svc.-1.-1: Failed to read second value of qcom,protection-domain qcom,apr remoteproc0:smd-edge.apr_audio_svc.-1.-1: Failed to add apr 3 svc Fixes: 6d7860f5 ("soc: qcom: apr: Add check for idr_alloc and of_property_read_string_index") Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
-
Eric Dumazet authored
commit 80f8a66d upstream. This reverts commit 13e5afd3. ieee80211_if_free() is already called from free_netdev(ndev) because ndev->priv_destructor == ieee80211_if_free syzbot reported: general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 0 PID: 10041 Comm: syz-executor.0 Not tainted 6.2.0-rc2-syzkaller-00388-g55b98837e37d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 RIP: 0010:pcpu_get_page_chunk mm/percpu.c:262 [inline] RIP: 0010:pcpu_chunk_addr_search mm/percpu.c:1619 [inline] RIP: 0010:free_percpu mm/percpu.c:2271 [inline] RIP: 0010:free_percpu+0x186/0x10f0 mm/percpu.c:2254 Code: 80 3c 02 00 0f 85 f5 0e 00 00 48 8b 3b 48 01 ef e8 cf b3 0b 00 48 ba 00 00 00 00 00 fc ff df 48 8d 78 20 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 3b 0e 00 00 48 8b 58 20 48 b8 00 00 00 00 00 fc RSP: 0018:ffffc90004ba7068 EFLAGS: 00010002 RAX: 0000000000000000 RBX: ffff88823ffe2b80 RCX: 0000000000000004 RDX: dffffc0000000000 RSI: ffffffff81c1f4e7 RDI: 0000000000000020 RBP: ffffe8fffe8fc220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 1ffffffff2179ab2 R12: ffff8880b983d000 R13: 0000000000000003 R14: 0000607f450fc220 R15: ffff88823ffe2988 FS: 00007fcb349de700(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32220000 CR3: 000000004914f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> netdev_run_todo+0x6bf/0x1100 net/core/dev.c:10352 ieee80211_register_hw+0x2663/0x4040 net/mac80211/main.c:1411 mac80211_hwsim_new_radio+0x2537/0x4d80 drivers/net/wireless/mac80211_hwsim.c:4583 hwsim_new_radio_nl+0xa09/0x10f0 drivers/net/wireless/mac80211_hwsim.c:5176 genl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968 genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2564 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline] netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1356 netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1932 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 ____sys_sendmsg+0x712/0x8c0 net/socket.c:2476 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2530 __sys_sendmsg+0xf7/0x1c0 net/socket.c:2559 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Reported-by:
syzbot <syzkaller@googlegroups.com> Fixes: 13e5afd3 ("wifi: mac80211: fix memory leak in ieee80211_if_add()") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Zhengchao Shao <shaozhengchao@huawei.com> Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230113124326.3533978-1-edumazet@google.com Signed-off-by:
-
Damien Le Moal authored
commit 3692fec8 upstream. Rename deadline_is_seq_writes() to deadline_is_seq_write() (remove the "s" plural) to more correctly reflect the fact that this function tests a single request, not multiple requests. Fixes: 015d02f4 ("block: mq-deadline: Do not break sequential write streams to zoned HDDs") Signed-off-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com> Link: https://lore.kernel.org/r/20221126025550.967914-2-damien.lemoal@opensource.wdc.com Signed-off-by:
-
Yang Yingliang authored
commit 90e7cb78 upstream. Add missing mutex_unlock() before returning from mlx5_fw_fatal_reporter_err_work(). Fixes: 9078e843 ("net/mlx5: Avoid recovery in probe flows") Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Shay Drory <shayd@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
-
Paolo Abeni authored
commit 8ccc9936 upstream. The referenced commit changed the error code returned by the kernel when preventing a non-established socket from attaching the ktls ULP. Before to such a commit, the user-space got ENOTCONN instead of EINVAL. The existing self-tests depend on such error code, and the change caused a failure: RUN global.non_established ... tls.c:1673:non_established:Expected errno (22) == ENOTCONN (107) non_established: Test failed at step #3 FAIL global.non_established In the unlikely event existing applications do the same, address the issue by restoring the prior error code in the above scenario. Note that the only other ULP performing similar checks at init time - smc_ulp_ops - also fails with ENOTCONN when trying to attach the ULP to a non-established socket. Reported-by:
Sabrina Dubroca <sd@queasysnail.net> Fixes: 2c02d41d ("net/ulp: prevent ULP without clone op from entering the LISTEN status") Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Stefan Metzmacher authored
commit 3e4cb6eb upstream. I hit a very bad problem during my tests of SENDMSG_ZC. BUG(); in first_iovec_segment() triggered very easily. The problem was io_setup_async_msg() in the partial retry case, which seems to happen more often with _ZC. iov_iter_iovec_advance() may change i->iov in order to have i->iov_offset being only relative to the first element. Which means kmsg->msg.msg_iter.iov is no longer the same as kmsg->fast_iov. But this would rewind the copy to be the start of async_msg->fast_iov, which means the internal state of sync_msg->msg.msg_iter is inconsitent. I tested with 5 vectors with length like this 4, 0, 64, 20, 8388608 and got a short writes with: - ret=2675244 min_ret=8388692 => remaining 5713448 sr->done_io=2675244 - ret=-EAGAIN => io_uring_poll_arm - ret=4911225 min_ret=5713448 => remaining 802223 sr->done_io=7586469 - ret=-EAGAIN => io_uring_poll_arm - ret=802223 min_ret=802223 => res=8388692 While this was easily triggered with SENDMSG_ZC (queued for 6.1), it was a potential problem starting with 7ba89d2a in 5.18 for IORING_OP_RECVMSG. And also with 4c3c0943 in 5.19 for IORING_OP_SENDMSG. However 257e84a5 introduced the critical code into io_setup_async_msg() in 5.11. Fixes: 7ba89d2a ("io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly") Fixes: 257e84a5 ("io_uring: refactor sendmsg/recvmsg iov managing") Cc: stable@vger.kernel.org Signed-off-by:
Stefan Metzmacher <metze@samba.org> Reviewed-by:
-
Jens Axboe authored
commit 6f83ab22 upstream. -1 tells use to use the current position, but we check if the file is a stream regardless of that. Fix up io_kiocb_update_pos() to only dip into file if we need to. This is both more efficient and also drops 12 bytes of text on aarch64 and 64 bytes on x86-64. Fixes: b4aec400 ("io_uring: do not recalculate ppos unnecessarily") Signed-off-by:
-
Steven Rostedt (Google) authored
commit 09794a5a upstream. Simplify: #define ALIGN_STRUCTFIELD(type) ((int)(offsetof(struct {char a; type b;}, b))) with #define ALIGN_STRUCTFIELD(type) __alignof__(struct {type b;}) Which works just the same. Link: https://lore.kernel.org/all/a7d202457150472588df0bd3b7334b3f@AcuMS.aculab.com/ Link: https://lkml.kernel.org/r/20220802154412.513c50e3@gandalf.local.home Suggested-by:
David Laight <David.Laight@ACULAB.COM> Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
-
YingChi Long authored
commit 55228db2 upstream. WG14 N2350 specifies that it is an undefined behavior to have type definitions within offsetof", see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm This specification is also part of C23. Therefore, replace the TYPE_ALIGN macro with the _Alignof builtin to avoid undefined behavior. (_Alignof itself is C11 and the kernel is built with -gnu11). ISO C11 _Alignof is subtly different from the GNU C extension __alignof__. Latter is the preferred alignment and _Alignof the minimal alignment. For long long on x86 these are 8 and 4 respectively. The macro TYPE_ALIGN's behavior matches _Alignof rather than __alignof__. [ bp: Massage commit message. ] Signed-off-by:
YingChi Long <me@inclyc.cn> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20220925153151.2467884-1-me@inclyc.cn Signed-off-by:
-
Alex Deucher authored
This reverts commit 78623b10 which is commit 81d0bcf9 upstream. This commit causes hiberation regressions on some platforms on kernels older than 6.1.x (6.1.x and newer kernels works fine) so let's revert it from 5.15 and older stable kernels. This should be reverted from 6.0.x as well, but that kernel is no longer supported. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=216917 Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: kolAflash@kolahilft.de Cc: jrf@mailbox.org Cc: mario.limonciello@amd.com Cc: stable@vger.kernel.org # 5.15.x Signed-off-by:
-
Ard Biesheuvel authored
commit 18bba184 upstream. Add the missing #include of asm/assembler.h, which is where the ldr_l macro is defined. Fixes: ff7a1679 ("arm64: efi: Execute runtime services from a dedicated stack") Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Cc: Lee Jones <lee@kernel.org> Signed-off-by:
-
Ard Biesheuvel authored
commit ff7a1679 upstream. With the introduction of PRMT in the ACPI subsystem, the EFI rts workqueue is no longer the only caller of efi_call_virt_pointer() in the kernel. This means the EFI runtime services lock is no longer sufficient to manage concurrent calls into firmware, but also that firmware calls may occur that are not marshalled via the workqueue mechanism, but originate directly from the caller context. For added robustness, and to ensure that the runtime services have 8 KiB of stack space available as per the EFI spec, introduce a spinlock protected EFI runtime stack of 8 KiB, where the spinlock also ensures serialization between the EFI rts workqueue (which itself serializes EFI runtime calls) and other callers of efi_call_virt_pointer(). While at it, use the stack pivot to avoid reloading the shadow call stack pointer from the ordinary stack, as doing so could produce a gadget to defeat it. Signed-off-by:
-
Alon Zahavi authored
commit 6d5c9e79 upstream. The bug occours due to a misuse of `attr` variable instead of `attr_b`. `attr` is being initialized as NULL, then being derenfernced as `attr->res.data_size`. This bug causes a crash of the ntfs3 driver itself, If compiled directly to the kernel, it crashes the whole system. Signed-off-by:
Alon Zahavi <zahavi.alon@gmail.com> Co-developed-by:
Tal Lossos <tallossos@gmail.com> Signed-off-by:
Konstantin Komarov <almaz.alexandrovich@paragon-software.com> Signed-off-by:
-
Alex Deucher authored
commit 3786a9bc upstream. These have been at production level for a while. Drop the flag. Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Joshua Ashton authored
commit 973a9c81 upstream. The YCC conversion matrix for RGB -> COLOR_SPACE_YCBCR2020_TYPE is missing the values for the fourth column of the matrix. The fourth column of the matrix is essentially just a value that is added given that the color is 3 components in size. These values are needed to bias the chroma from the [-1, 1] -> [0, 1] range. This fixes color being very green when using Gamescope HDR on HDMI output which prefers YCC 4:4:4. Fixes: 40df2f80 ("drm/amd/display: color space ycbcr709 support") Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
Joshua Ashton <joshua@froggi.es> Signed-off-by:
-
Joshua Ashton authored
commit 79601b89 upstream. Code in get_output_color_space depends on knowing the pixel encoding to determine whether to pick between eg. COLOR_SPACE_SRGB or COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver. v2: Fixed patch being accidentally based on a personal feature branch, oops! Fixes: ea117312 ("drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded") Reviewed-by:
-
hongao authored
commit 040625ab upstream. [Why] Setting scaling does not correctly update CRTC state. As a result dc stream state's src (composition area) && dest (addressable area) was not calculated as expected. This causes set scaling doesn's work. [How] Correctly update CRTC state when setting scaling property. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Tested-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
hongao <hongao@uniontech.com> Signed-off-by:
-
Drew Davenport authored
commit 8565c502 upstream. The error message suggests that the height of the src rect must be at least 1. Reject source with height of 0. Cc: stable@vger.kernel.org Signed-off-by:
Drew Davenport <ddavenport@chromium.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221226225246.1.I15dff7bb5a0e485c862eae61a69096caf12ef29f@changeid (cherry picked from commit 0fe76b19) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Sasa Dragic authored
commit 67b0b4ed upstream. RC6p on Sandy Bridge got re-enabled over time, causing visual glitches and GPU hangs. Disabled originally in commit 1c8ecf80 ("drm/i915: do not enable RC6p on Sandy Bridge"). Signed-off-by:
Sasa Dragic <sasa.dragic@gmail.com> Signed-off-by:
-
Alexander Usyskin authored
commit 0c4d6826 upstream. Add Meteor Lake Point M device id. Cc: <stable@vger.kernel.org> Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20221212220247.286019-2-tomas.winkler@intel.com Signed-off-by:
-
Khazhismel Kumykov authored
commit a769b05e upstream. We can get EFI variables without fetching the attribute, so we must allow for that in gsmi. commit 85974825 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi. Fixes: 74c5b31c ("driver: Google EFI SMI") Cc: stable <stable@kernel.org> Signed-off-by:
Khazhismel Kumykov <khazhy@google.com> Link: https://lore.kernel.org/r/20230118010212.1268474-1-khazhy@google.com Signed-off-by:
-
Tobias Schramm authored
commit 5bfdd3c6 upstream. Commit ba47f97a ("serial: core: remove baud_rates when serial console setup") changed uart_set_options to select the correct baudrate configuration based on the absolute error between requested baudrate and available standard baudrate settings. Prior to that commit the baudrate was selected based on which predefined standard baudrate did not exceed the requested baudrate. This change of selection logic was never reflected in the atmel serial driver. Thus the comment left in the atmel serial driver is no longer accurate. Additionally the manual rounding up described in that comment and applied via (quot - 1) requests an incorrect baudrate. Since uart_set_options uses tty_termios_encode_baud_rate to determine the appropriate baudrate flags this can cause baudrate selection to fail entirely because tty_termios_encode_baud_rate will only select a baudrate if relative error between requested and selected baudrate does not exceed +/-2%. Fix that by requesting actual, exact baudrate used by the serial. Fixes: ba47f97a ("serial: core: remove baud_rates when serial console setup") Cc: stable <stable@kernel.org> Signed-off-by:
Tobias Schramm <t.schramm@manjaro.org> Acked-by:
Richard Genoud <richard.genoud@gmail.com> Link: https://lore.kernel.org/r/20230109072940.202936-1-t.schramm@manjaro.org Signed-off-by:
-
Lino Sanfilippo authored
commit 4f39aca2 upstream. In RS485 mode the transmission of a high priority character fails since it is written to the data register before the transmitter is enabled. Fix this in pl011_tx_chars() by enabling RS485 transmission before writing the character. Fixes: 8d479237 ("serial: amba-pl011: add RS485 support") Cc: stable@vger.kernel.org Signed-off-by:
Lino Sanfilippo <l.sanfilippo@kunbus.com> Link: https://lore.kernel.org/r/20230108181735.10937-1-LinoSanfilippo@gmx.de Signed-off-by:
-
Reinette Chatre authored
commit b51b75f0 upstream. The workqueue is enabled when the appropriate driver is loaded and disabled when the driver is removed. When the driver is removed it assumes that the workqueue was enabled successfully and proceeds to free allocations made during workqueue enabling. Failure during workqueue enabling does not prevent the driver from being loaded. This is because the error path within drv_enable_wq() returns success unless a second failure is encountered during the error path. By returning success it is possible to load the driver even if the workqueue cannot be enabled and allocations that do not exist are attempted to be freed during driver remove. Some examples of problematic flows: (a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq(). (b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010 Fix the drv_enable_wq() error path by returning the original error that indicates failure of workqueue enabling. This ensures that the probe fails when an error is encountered and the driver remove paths are only attempted when the workqueue was enabled successfully. Fixes: 1f2bb403 ("dmaengine: idxd: move wq_enable() to device.c") Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Reviewed-by:
Dave Jiang <dave.jiang@intel.com> Reviewed-by:
Fenghua Yu <fenghua.yu@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/e8d8116e5efa0fd14fadc5adae6ffd319f0e5ff1.1670452419.git.reinette.chatre@intel.com Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Mohan Kumar authored
commit 9c7e355c upstream. The current global interrupt clear programming register offset was not correct. Fix the programming with right offset Fixes: ded1f3db ("dmaengine: tegra210-adma: prepare for supporting newer Tegra chips") Cc: stable@vger.kernel.org Signed-off-by:
Mohan Kumar <mkumard@nvidia.com> Link: https://lore.kernel.org/r/20230102064844.31306-1-mkumard@nvidia.com Signed-off-by:
-
Peter Harliman Liem authored
commit 96b3bb18 upstream. ldma_cfg_init() will parse DT to retrieve certain configs. However, that is called before ldma_dma_init_vXX(), which will make some initialization to channel configs. It will thus incorrectly overwrite certain configs that are declared in DT. To fix that, we move DT parsing after initialization. Function name is renamed to better represent what it does. Fixes: 32d31c79 ("dmaengine: Add Intel LGM SoC DMA support.") Signed-off-by:
Peter Harliman Liem <pliem@maxlinear.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/afef6fc1ed20098b684e0d53737d69faf63c125f.1672887183.git.pliem@maxlinear.com Signed-off-by:
-
Ilpo Järvinen authored
commit e8914b52 upstream. A local variable sg is used to store scatterlist pointer in pch_dma_tx_complete(). The for loop doing Tx byte accounting before dma_unmap_sg() alters sg in its increment statement. Therefore, the pointer passed into dma_unmap_sg() won't match to the one given to dma_map_sg(). To fix the problem, use priv->sg_tx_p directly in dma_unmap_sg() instead of the local variable. Fixes: da3564ee ("pch_uart: add multi-scatter processing") Cc: stable@vger.kernel.org Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20230103093435.4396-1-ilpo.jarvinen@linux.intel.com Signed-off-by:
-
Heiner Kallweit authored
commit e1811190 upstream. The compatible string in the driver doesn't have the meson prefix. Fix this in the documentation and rename the file accordingly. Fixes: 87a55485 ("dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml") Cc: stable@vger.kernel.org Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/0a82be92-ce85-da34-9d6f-4b33034473e5@gmail.com Signed-off-by:
-
Heiner Kallweit authored
commit c63835bf upstream. The compatible strings in the driver don't have the meson prefix. Fix this in the documentation and rename the file accordingly. Fixes: da86d286 ("dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml") Cc: stable@vger.kernel.org Signed-off-by:
-
Juhyung Park authored
commit dbd24ec1 upstream. The commit e00b488e ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS") blacklists UAS for all of RTL9210 enclosures. The RTL9210 controller was advertised with UAS since its release back in 2019 and was shipped with a lot of enclosure products with different firmware combinations. Blacklist UAS only for HIKSEMI MD202. This should hopefully be replaced with more robust method than just comparing strings. But with limited information [1] provided thus far (dmesg when the device is plugged in, which includes manufacturer and product, but no lsusb -v to compare against), this is the best we can do for now. [1] https://lore.kernel.org/all/20230109115550.71688-1-qkrwngud825@gmail.com Fixes: e00b488e ("usb-storage: Add Hiksemi USB3-FW to IGNORE_UAS") Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Hongling Zeng <zenghongling@kylinos.cn> Cc: stable@vger.kernel.org Signed-off-by:
Juhyung Park <qkrwngud825@gmail.com> Acked-by:
Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20230117085154.123301-1-qkrwngud825@gmail.com Signed-off-by:
-
Maciej Żenczykowski authored
commit c6ec9295 upstream. In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device. AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b) Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c] which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); which calls: ncm_bitrate(NULL) which then calls: gadget_is_superspeed(NULL) which reads ((struct usb_gadget *)NULL)->max_speed and hits a panic. AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct work_struct) It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing... Cc: Felipe Balbi <balbi@kernel.org> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Carlos Llamas <cmllamas@google.com> Cc: stable@vger.kernel.org Signed-off-by:
Maciej Żenczykowski <maze@google.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20230117131839.1138208-1-maze@google.com Signed-off-by:
-
Daniel Scally authored
commit e95765e9 upstream. Currently the color matching descriptor is only sent across the wire a single time, following the descriptors for each format and frame. According to the UVC 1.5 Specification 3.9.2.6 ("Color Matching Descriptors"): "Only one instance is allowed for a given format and if present, the Color Matching descriptor shall be placed following the Video and Still Image Frame descriptors for that format". Add another reference to the color matching descriptor after the yuyv frames so that it's correctly transmitted for that format too. Fixes: a9914127 ("USB gadget: Webcam device") Cc: stable <stable@kernel.org> Signed-off-by:
Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Link: https://lore.kernel.org/r/20221216160528.479094-1-dan.scally@ideasonboard.com Signed-off-by:
-
Prashant Malani authored
commit 9682b41e upstream. Commit c1e5c2f0 ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles") fixed the pin assignment calculation to take into account whether the peripheral was a plug or a receptacle. But the "pin_assignments" sysfs logic was not updated. Address this by using the macros introduced in the aforementioned commit in the sysfs logic too. Fixes: c1e5c2f0 ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles") Cc: stable@vger.kernel.org Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Prashant Malani <pmalani@chromium.org> Reviewed-by:
Benson Leung <bleung@chromium.org> Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230111020546.3384569-2-pmalani@chromium.org Signed-off-by:
-
Prashant Malani authored
commit 582836e3 upstream. The code to extract a peripheral's currently supported Pin Assignments is repeated in a couple of locations. Factor it out into a separate function. This will also make it easier to add fixes (we only need to update 1 location instead of 2). Fixes: c1e5c2f0 ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles") Cc: stable@vger.kernel.org Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
