kernel/linux.git, branch v6.1.132

Linux 6.1.132

2025-03-28T20:59:02+00:00

Link: https://lore.kernel.org/r/20250325122156.633329074@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Link: https://lore.kernel.org/r/20250326154349.272647840@linuxfoundation.org Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20250328074420.301061796@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Ron Economos Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Frank Scheiner Signed-off-by: Greg Kroah-Hartman

xfs: give xfs_extfree_intent its own perag reference

2025-03-28T20:59:02+00:00

commit f6b384631e1e3482c24e35b53adbd3da50e47e8f upstream. Give the xfs_extfree_intent an passive reference to the perag structure data. This reference will be used to enable scrub intent draining functionality in subsequent patches. The space being freed must already be allocated, so we need to able to run even if the AG is being offlined or shrunk. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Leah Rumancik Acked-by: "Darrick J. Wong" Signed-off-by: Greg Kroah-Hartman

block, bfq: fix re-introduced UAF in bic_set_bfqq()

2025-03-28T20:59:02+00:00

Commit eca0025faa96ac ("block, bfq: split sync bfq_queues on a per-actuator basis"), which is a backport of 9778369a2d6c5e ("block, bfq: split sync bfq_queues on a per-actuator basis") re-introduces UAF bug originally fixed by b600de2d7d3a16 ("block, bfq: fix uaf for bfqq in bic_set_bfqq()") and backported to 6.1 in cb1876fc33af26 ("block, bfq: fix uaf for bfqq in bic_set_bfqq()"). bfq_release_process_ref() may release the sync_bfqq variable, which points to the same bfqq as bic->bfqq member for call context from __bfq_bic_change_cgroup(). bic_set_bfqq() then accesses bic->bfqq member which leads to the UAF condition. Fix this by bringing the incriminated function calls back in correct order. Fixes: eca0025faa96ac ("block, bfq: split sync bfq_queues on a per-actuator basis") Signed-off-by: Jakub Acs Cc: Hagar Hemdan Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

mm/migrate: fix shmem xarray update during migration

2025-03-28T20:59:02+00:00

commit 60cf233b585cdf1f3c5e52d1225606b86acd08b0 upstream. A shmem folio can be either in page cache or in swap cache, but not at the same time. Namely, once it is in swap cache, folio->mapping should be NULL, and the folio is no longer in a shmem mapping. In __folio_migrate_mapping(), to determine the number of xarray entries to update, folio_test_swapbacked() is used, but that conflates shmem in page cache case and shmem in swap cache case. It leads to xarray multi-index entry corruption, since it turns a sibling entry to a normal entry during xas_store() (see [1] for a userspace reproduction). Fix it by only using folio_test_swapcache() to determine whether xarray is storing swap cache entries or not to choose the right number of xarray entries to update. [1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/ Note: In __split_huge_page(), folio_test_anon() && folio_test_swapcache() is used to get swap_cache address space, but that ignores the shmem folio in swap cache case. It could lead to NULL pointer dereferencing when a in-swap-cache shmem folio is split at __xa_store(), since !folio_test_anon() is true and folio->mapping is NULL. But fortunately, its caller split_huge_page_to_list_to_order() bails out early with EBUSY when folio->mapping is NULL. So no need to take care of it here. Link: https://lkml.kernel.org/r/20250305200403.2822855-1-ziy@nvidia.com Fixes: fc346d0a70a1 ("mm: migrate high-order folios in swap cache correctly") Signed-off-by: Zi Yan Reported-by: Liu Shixin Closes: https://lore.kernel.org/all/28546fb4-5210-bf75-16d6-43e1f8646080@huawei.com/ Suggested-by: Hugh Dickins Reviewed-by: Matthew Wilcox (Oracle) Reviewed-by: Baolin Wang Cc: Barry Song Cc: Charan Teja Kalla Cc: David Hildenbrand Cc: Hugh Dickins Cc: Kefeng Wang Cc: Lance Yang Cc: Ryan Roberts Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

wifi: iwlwifi: mvm: ensure offloading TID queue exists

2025-03-28T20:59:02+00:00

commit 78f65fbf421a61894c14a1b91fe2fb4437b3fe5f upstream. The resume code path assumes that the TX queue for the offloading TID has been configured. At resume time it then tries to sync the write pointer as it may have been updated by the firmware. In the unusual event that no packets have been send on TID 0, the queue will not have been allocated and this causes a crash. Fix this by ensuring the queue exist at suspend time. Signed-off-by: Benjamin Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240218194912.6632e6dc7b35.Ie6e6a7488c9c7d4529f13d48f752b5439d8ac3c4@changeid Signed-off-by: Johannes Berg Signed-off-by: Jianqi Ren Signed-off-by: He Zhe Signed-off-by: Greg Kroah-Hartman

fs/ntfs3: Change new sparse cluster processing

2025-03-28T20:59:02+00:00

commit c380b52f6c5702cc4bdda5e6d456d6c19a201a0b upstream. Remove ntfs_sparse_cluster. Zero clusters in attr_allocate_clusters. Fixes xfstest generic/263 Bug: https://syzkaller.appspot.com/bug?extid=f3e5d0948a1837ed1bb0 Reported-by: syzbot+f3e5d0948a1837ed1bb0@syzkaller.appspotmail.com Cc: Signed-off-by: Konstantin Komarov Signed-off-by: Miguel Garcia Roman Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix use-after-free bug

2025-03-28T20:59:02+00:00

commit 22207fd5c80177b860279653d017474b2812af5e upstream. The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl to the AMDGPU DRM driver on any ASICs with an invalid address and size. The bug was reported by Joonkyo Jung . For example the following code: static void Syzkaller1(int fd) { struct drm_amdgpu_gem_userptr arg; int ret; arg.addr = 0xffffffffffff0000; arg.size = 0x80000000; /*2 Gb*/ arg.flags = 0x7; ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg); } Due to the address and size are not valid there is a failure in amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert-> check_shl_overflow, but we even the amdgpu_hmm_register failure we still call amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address. The following stack is below when the issue is reproduced when Kazan is enabled: [ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340 [ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80 [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246 [ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b [ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260 [ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25 [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00 [ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260 [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000 [ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0 [ +0.000010] Call Trace: [ +0.000006] [ +0.000007] ? show_regs+0x6a/0x80 [ +0.000018] ? __warn+0xa5/0x1b0 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [ +0.000018] ? report_bug+0x24a/0x290 [ +0.000022] ? handle_bug+0x46/0x90 [ +0.000015] ? exc_invalid_op+0x19/0x50 [ +0.000016] ? asm_exc_invalid_op+0x1b/0x20 [ +0.000017] ? kasan_save_stack+0x26/0x50 [ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340 [ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10 [ +0.000017] ? kasan_save_alloc_info+0x1e/0x30 [ +0.000018] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_kmalloc+0xb1/0xc0 [ +0.000018] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_read+0x11/0x20 [ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu] [ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu] [ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu] [ +0.004291] ? do_syscall_64+0x5f/0xe0 [ +0.000023] ? srso_return_thunk+0x5/0x5f [ +0.000017] drm_gem_object_free+0x3b/0x50 [drm] [ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu] [ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004270] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __this_cpu_preempt_check+0x13/0x20 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm] [ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm] [ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm] [ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm] [ +0.000489] ? srso_return_thunk+0x5/0x5f [ +0.000011] ? __kasan_check_write+0x14/0x20 [ +0.000016] drm_ioctl+0x3da/0x730 [drm] [ +0.000475] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004293] ? __pfx_drm_ioctl+0x10/0x10 [drm] [ +0.000506] ? __pfx_rpm_resume+0x10/0x10 [ +0.000016] ? srso_return_thunk+0x5/0x5f [ +0.000011] ? __kasan_check_write+0x14/0x20 [ +0.000010] ? srso_return_thunk+0x5/0x5f [ +0.000011] ? _raw_spin_lock_irqsave+0x99/0x100 [ +0.000015] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ +0.000014] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000011] ? srso_return_thunk+0x5/0x5f [ +0.000011] ? preempt_count_sub+0x18/0xc0 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000010] ? _raw_spin_unlock_irqrestore+0x27/0x50 [ +0.000019] amdgpu_drm_ioctl+0x7e/0xe0 [amdgpu] [ +0.004272] __x64_sys_ioctl+0xcd/0x110 [ +0.000020] do_syscall_64+0x5f/0xe0 [ +0.000021] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ +0.000015] RIP: 0033:0x7ff9ed31a94f [ +0.000012] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 [ +0.000013] RSP: 002b:00007fff25f66790 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ +0.000016] RAX: ffffffffffffffda RBX: 000055b3f7e133e0 RCX: 00007ff9ed31a94f [ +0.000012] RDX: 000055b3f7e133e0 RSI: 00000000c1186451 RDI: 0000000000000003 [ +0.000010] RBP: 00000000c1186451 R08: 0000000000000000 R09: 0000000000000000 [ +0.000009] R10: 0000000000000008 R11: 0000000000000246 R12: 00007fff25f66ca8 [ +0.000009] R13: 0000000000000003 R14: 000055b3f7021ba8 R15: 00007ff9ed7af040 [ +0.000024] [ +0.000007] ---[ end trace 0000000000000000 ]--- v2: Consolidate any error handling into amdgpu_hmm_register which applied to kfd_bo also. (Christian) v3: Improve syntax and comment (Christian) Cc: Christian Koenig Cc: Alex Deucher Cc: Felix Kuehling Cc: Joonkyo Jung Cc: Dokyung Song Cc: Cc: Signed-off-by: Vitaly Prosyak Reviewed-by: Christian König Signed-off-by: Alex Deucher [ drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c is renamed from drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c since d9483ecd327b ("drm/amdgpu: rename the files for HMM handling"). The path is changed accordingly to apply the patch on 6.1.y. ] Signed-off-by: Bin Lan Signed-off-by: He Zhe Signed-off-by: Greg Kroah-Hartman

arm64: dts: rockchip: fix u2phy1_host status for NanoPi R4S

2025-03-28T20:59:02+00:00

commit 38f4aa34a5f737ea8588dac320d884cc2e762c03 upstream. The u2phy1_host should always have the same status as usb_host1_ehci and usb_host1_ohci, otherwise the EHCI and OHCI drivers may be initialized for a disabled usb port. Per the NanoPi R4S schematic, the phy-supply for u2phy1_host is set to the vdd_5v regulator. Fixes: db792e9adbf8 ("rockchip: rk3399: Add support for FriendlyARM NanoPi R4S") Cc: stable@vger.kernel.org Signed-off-by: Justin Klaassen Reviewed-by: Dragan Simic Link: https://lore.kernel.org/r/20250225170420.3898-1-justin@tidylabs.net Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman

media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning

2025-03-28T20:59:02+00:00

commit b113bc7c0e83b32f4dd2d291a2b6c4803e0a2c44 upstream. Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL. Fixes: 7a7ae26fd458 ("media: mediatek: vcodec: support stateless VP8 decoding") Signed-off-by: Yunfei Dong Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Bin Lan Signed-off-by: He Zhe Signed-off-by: Greg Kroah-Hartman

drm/mediatek: Fix coverity issue with unintentional integer overflow

2025-03-28T20:59:02+00:00

commit b0b0d811eac6b4c52cb9ad632fa6384cf48869e7 upstream. 1. Instead of multiplying 2 variable of different types. Change to assign a value of one variable and then multiply the other variable. 2. Add a int variable for multiplier calculation instead of calculating different types multiplier with dma_addr_t variable directly. Fixes: 1a64a7aff8da ("drm/mediatek: Fix cursor plane no update") Signed-off-by: Jason-JH.Lin Reviewed-by: Alexandre Mergnat Reviewed-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/dri-devel/patch/20230907091425.9526-1-jason-jh.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu [ For certain code segments with coverity issue do not exist in function mtk_plane_update_new_state(), those not present in v6.1 are not back ported. ] Signed-off-by: Bin Lan Signed-off-by: He Zhe Signed-off-by: Greg Kroah-Hartman