summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-10powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVMGautam Menghani
Currently, CONFIG_VPA_PMU is not enabled by default, and consequently cannot be used for KVM guests at all, unless explicitly enabled on host kernel. Mark CONFIG_VPA_PMU as "default m" to ensure it is available when KVM is being used. Cc: stable@vger.kernel.org # v6.13+ Suggested-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Gautam Menghani <gautam@linux.ibm.com> [Maddy: Changed tag order] Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260615091120.84169-1-gautam@linux.ibm.com
2026-07-10ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAFNorbert Szetei
pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path. Fixes: ee40fb2e1eb5 ("l2tp: protect sock pointer of struct pppol2tp_session with RCU") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei <norbert@doyensec.com> Reviewed-by: Qingfang Deng <qingfang.deng@linux.dev> Link: https://patch.msgid.link/E793FCF2-58DE-4387-A983-C7B4BC3158BD@doyensec.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-10selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not availableThomas Huth
MSG_OOB might be disabled in the kernel for unix sockets (by not selecting CONFIG_AF_UNIX_OOB), and in this case the related tests of the scoped_signal_test are currently failing. Add a runtime probe using socketpair() to detect MSG_OOB support and skip the test gracefully if it is unavailable. Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260710081642.405916-1-thuth@redhat.com Cc: stable@vger.kernel.org Fixes: f34e9ce5f479 ("selftests/landlock: Test signal created by out-of-bound message") Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-07-10selftests/landlock: Fix screwed up pointers in the scoped_signal_testThomas Huth
The scoped_signal_test uses pthread_join(..., (void **)&ret)) in a couple of places, i.e. the return value of the thread is stored in the shape of a "void *" into the memory location of &ret. Pointers are 64-bit on modern computers, but the ret variable is declared as a simple "enum thread_return" which is only 32 bits. So the pthread_join() will overflow the ret variable by 4 byte. The problem is very visible on big endian systems like s390x where the test is failing: The least significant byte that carries the return code of the thread is not written into the ret variable here, but somewhere else in the stack frame, so the comparison for the right return code is failing here. Fix it by getting rid of the enum and defining the THREAD_* constants and "ret" variables as proper "void *" pointers. This way we can also get rid of some ugly (void *) castings in a couple of spots. Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260709164340.339656-1-thuth@redhat.com Cc: stable@vger.kernel.org Fixes: c8994965013e ("selftests/landlock: Test signal scoping for threads") [mic: Add clang-format markups] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-07-10landlock: Update formattingMickaël Salaün
Following commit 99df2a8eba34 ("clang-format: fix formatting of guard() and scoped_guard() statements"), update scoped_guard() formatting. Also, see the related fix [1]. Cc: Günther Noack <gnoack@google.com> Cc: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20260708105713.2073335-1-mic@digikod.net [1] Link: https://patch.msgid.link/20260708110635.2083515-1-mic@digikod.net Reviewed-by: Günther Noack <gnoack@google.com> Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-07-10landlock: Fix kernel-doc for the nested quiet layer flagMickaël Salaün
kernel-doc emits "Excess struct member 'quiet' description in 'landlock_layer'" because "quiet" is a bitfield inside the named nested struct "flags", but its inline comment used the bare member name "@quiet:", which kernel-doc attributes to the enclosing landlock_layer. Use the canonical dotted notation "@flags.quiet:" so kernel-doc resolves the nested member, and include it in the generated documentation. Cc: Justin Suess <utilityemal77@gmail.com> Cc: Tingmao Wang <m@maowtm.org> Fixes: a260c0055665 ("landlock: Add a place for flags to layer rules") Link: https://patch.msgid.link/20260703141711.2016964-1-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-07-10selftests/landlock: Add test for TCP fast openMatthieu Buffet
Enforce that TCP Fast Open is controlled by LANDLOCK_ACCESS_NET_CONNECT_TCP. Semantics of connect() and sendmsg(MSG_FASTOPEN) should be identical from Landlock's perspective. Also enforce error code consistency, since UDP sockets ignore the MSG_FASTOPEN flag while Unix sockets reject it. Signed-off-by: Matthieu Buffet <matthieu@buffet.re> Link: https://patch.msgid.link/20260701214628.33319-2-matthieu@buffet.re Cc: stable@vger.kernel.org [mic: Fix formatting] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-07-10landlock: Fix TCP Fast Open connection bypassMatthieu Buffet
The documentation of the socket_connect() LSM hook states that it controls connecting a socket to a remote address. It has not been the case since the addition of TCP Fast Open (RFC 7413) support, which allows opening a TCP connection (thus, setting a socket's destination address) via the MSG_FASTOPEN flag passed to sendto()/sendmsg()/sendmmsg(). The problem then got duplicated into MPTCP. Landlock did not take it into account when its TCP support was added, leaving a bypass of TCP connect policy. Ideally a call to the LSM hook would be added in the fastopen code path, in order to fix this generically. But connect() hooks are designed to run with the socket locked, unlike sendmsg() hooks. Closes: https://github.com/landlock-lsm/linux/issues/41 Fixes: fff69fb03dde ("landlock: Support network rules with TCP bind and connect") Signed-off-by: Matthieu Buffet <matthieu@buffet.re> Link: https://patch.msgid.link/20260701214628.33319-1-matthieu@buffet.re Cc: stable@vger.kernel.org [mic: Wrap commit message] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-07-10Merge tag 'pinctrl-qcom-fixes-for-v7.2-rc3' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes Qualcomm pin control fixes for v7.2-rc3 - add missing wakeup entries for GPIO143/151 in pinctrl-sc8280xp - fix GPIO wakeup interrupt detection in pinctrl-msm Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-07-10perf/aux: Fix page UAF in map_range()Lee Jia Jie
map_range() reads rb->aux_pages[], rb->aux_nr_pages and rb->aux_pgoff via perf_mmap_to_page() while holding only event->mmap_mutex. Those fields are serialized by rb->aux_mutex, and mmap_mutex is per event. Thus, two events sharing one rb via PERF_EVENT_IOC_SET_OUTPUT can race rb_alloc_aux() with map_range(), leading to a page-UAF scenario as follows: CPU 0 CPU 1 ===== ===== rb_alloc_aux() map_range() [1]: allocate rb->aux_pages[0] [2]: rb->aux_nr_pages++ [3]: perf_mmap_to_page() returns rb->aux_pages[0] [4]: map it as VM_PFNMAP [5]: rb->aux_pgoff = 1 munmap the page [6]: free rb->aux_pages[0] Pages mapped as VM_PFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame. Fix this by taking rb->aux_mutex across the page walk in map_range(). Fixes: b709eb872e19 ("perf: map pages in advance") Signed-off-by: Lee Jia Jie <jiajie.lee@starlabs.sg> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org>
2026-07-10nouveau/vmm: fix another SPT/LPT raceDave Airlie
We've had an unknown Turing issue for a while with page faults since large pages and compression. I've got a patch series that syncs all our L2 handling with ogkm and it made this fault happen more. After writing a bunch of debugging patches, I spotted an invalid LPT entry where there should have been a valid one. A 64K MAP succeeds on a range, but a subsequent SPT put drops SPT refs across multiple ranges, We shouldn't assume all ranges where SPTEs go away will have the same sparse/invalid/valid state, just iterate over each instead and do the right thing. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Fixes: d19512f5abb1 ("nouveau/vmm: start tracking if the LPT PTE is valid. (v6)") Link: https://patch.msgid.link/20260615044737.3419585-1-airlied@gmail.com [ Properly format commit message. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org> (cherry picked from commit d008141ed4ce924167a03d46fbce9ad1fe4efa29) Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-07-10Merge tag 'drm-xe-fixes-2026-07-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Fix PTE index in xe_vm_populate_pgtable for chunked binds (Matt Brost) - Wait on external BO kernel fences in exec IOCTL (Matt Brost) - Remove duplicate include (Anas Khan) - Free madvise VMA array on L2 flush failure (Guangshuo Li) - Stub notifier_lock helpers when DRM_GPUSVM=n (Shuicheng Lin) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/alASIbW318Rl-HTv@fedora
2026-07-10Merge tag 'amd-drm-fixes-7.2-2026-07-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.2-2026-07-09: amdgpu: - PSP 15.0.9 update - SMU 15.0.9 update - VCN 5.3 fix - VI ASPM fix - Userq fix - lifetime fix for amdgpu_vm_get_task_info_pasid() - Gfx10 fix - SMU 14 fix amdkfd: - CRIU bounds checking fixes - secondary context id fix - Event bounds checking fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260709212303.15913-1-alexander.deucher@amd.com
2026-07-10Merge tag 'drm-misc-fixes-2026-07-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2-rc3: - Fix uaf in amdxdna mmap failure path. - A lot of deadlocks, access races and return value fixes in amdxdna. - Fix analogix_dp bitshifts during link training. - Use direct label in drm_exec. - Fix absent indirect bo handling in v3d. - Sync on first active crtc in fb_dirty, rather than first crtc. - Rework try_harder in the buddy allocator. - Make imagination function static to solve compiler warning. - Fix imagination error checking. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/71e5b48b-307f-47f5-8fd5-b60ea43e4196@linux.intel.com
2026-07-10Merge tag 'drm-intel-fixes-2026-07-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes Fix underrun regressions on Panther Lake by reverting the recent SCL=0 enablement for always-on VRR timing. It also includes a fix display LT PHY SSC programming and a small set of i915 fixes addressing NULL pointer dereferences, memory leaks and bound checks. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/ak-xZPqluaXVJGtP@intel.com
2026-07-09Merge tag 'v7.2-rc2-smb3-server-fixes' of git://git.samba.org/ksmbdLinus Torvalds
Pull smb server fixes from Steve French: "This contains a set of SMB server fixes mostly around session setup, multichannel/session binding, and protocol-compatible error reporting: - Fix SID-to-id mapping so only SIDs with a valid local Unix representation are translated, while preserving other Windows SIDs in NT ACL xattrs - Fix SMB3 multichannel binding across multi-round authentication, keep the derived channel key separate from the established session key, and enforce the 32-channel session limit - Match Windows-compatible close timestamp behavior by coalescing automatic write time updates smaller than 15ms - Return STATUS_DISK_FULL for SET_INFO allocation failures caused by ENOSPC or EFBIG - Fix several signed SESSION_SETUP error paths so clients see the intended server status instead of replacing it with STATUS_ACCESS_DENIED - Fix reauthentication on bound channels and reject different-user channel binding with STATUS_ACCESS_DENIED - Use the referenced session dialect/signing algorithm when validating and signing rejected cross-dialect binding requests" * tag 'v7.2-rc2-smb3-server-fixes' of git://git.samba.org/ksmbd: ksmbd: use the session dialect for rejected binding signatures ksmbd: mark rejected cross-dialect bindings as signed ksmbd: sign rejected SMB2.1 session binding responses ksmbd: handle channel binding with a different user ksmbd: find bound sessions during reauthentication ksmbd: mark invalid session responses as signed smb/server: map SET_INFO ENOSPC to disk full ksmbd: coalesce sub-15ms write time updates on close ksmbd: fix multichannel binding and enforce channel limit ksmbd: validate SID namespace before mapping IDs
2026-07-09cifs: Remove CIFSSMBSetPathInfoFB() fallback functionPali Rohár
This fallback function CIFSSMBSetPathInfoFB() is called only from CIFSSMBSetPathInfo() function. CIFSSMBSetPathInfo() is used in smb_set_file_info() which contains all required fallback code, including fallback via filehandle, since commit f122121796f9 ("cifs: Fix changing times and read-only attr over SMB1 smb_set_file_info() function") and commit 92210ccd877b ("cifs: Add fallback code path for cifs_mkdir_setinfo()"). So the CIFSSMBSetPathInfoFB() is just code duplication, which is not needed anymore. Therefore remove it. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-07-09cifs: Fix and improve cifs_is_path_accessible() functionPali Rohár
Do not call SMBQueryInformation() command for path with SMB wildcard characters on non-UNICODE connection because server expands wildcards. Function cifs_is_path_accessible() needs to check if the real path exists and must not expand wildcard characters. Do not dynamically allocate memory for small FILE_ALL_INFO structure and instead allocate it on the stack. This structure is allocated on stack by all other functions. When CAP_NT_SMBS was not negotiated then do not issue CIFSSMBQPathInfo() command. This command returns failure by non-NT Win9x SMB servers, so there is no need try it. The purpose of cifs_is_path_accessible() function is just to check if the path is accessible, so SMBQueryInformation() for old servers is enough. Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
2026-07-09mm/memory-failure: trace: change memory_failure_event to ras subsystemXie Yuanbin
Commit 97f0b1345219 ("tracing: add trace event for memory-failure") introduced memory_failure_event in ras subsystem. commit 31807483d395 ("mm/memory-failure: remove the selection of RAS") changed memory_failure_event to memory_failure subsystem. This breaks the backward compatibility, some user programs rely on it. Change memory_failure_event to ras subsystem to keep backward compatibility. Link: https://lore.kernel.org/20260605081213.154660-1-xieyuanbin1@huawei.com Fixes: 31807483d395 ("mm/memory-failure: remove the selection of RAS") Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com> Reported-by: Yi Lai <yi1.lai@intel.com> Reported-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Closes: https://lore.kernel.org/linux-mm/CY8PR11MB7134346A3E4BB28ECA28D6E989132@CY8PR11MB7134.namprd11.prod.outlook.com Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Miaohe Lin <linmiaohe@huawei.com> Tested-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@alien8.de> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09mm: page_reporting: allow driver to set batch capacityMichael S. Tsirkin
At the moment, if a virtio balloon device has a page reporting vq but its size is < PAGE_REPORTING_CAPACITY (32), the balloon driver fails probe. But, there's no way for host to know this value, so it can easily create a smaller vq and suddenly adding the reporting capability to the device makes all of the driver fail. Not pretty. Add a capacity field to page_reporting_dev_info so drivers can control the maximum number of pages per report batch. In virtio-balloon, set the capacity to the reporting virtqueue size, letting page_reporting adapt to whatever the device provides. Capacity need not be a power of two. Code previously called out division by PAGE_REPORTING_CAPACITY as cheap since it was a power of 2, but no performance difference was observed with non-power-of-2 values. If capacity is 0 or exceeds PAGE_REPORTING_CAPACITY, it defaults to PAGE_REPORTING_CAPACITY. The 0 check and the clamping is done in page_reporting_register(), before the reporting work is scheduled, so we never get division by 0. Link: https://lore.kernel.org/444c24cf39f3f3620fc90ef4695bd6b0979f4c4b.1783232420.git.mst@redhat.com Fixes: b0c504f15471 ("virtio-balloon: add support for providing free page reports to host") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Assisted-by: Claude:claude-opus-4-6 Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Gregory Price <gourry@gourry.net> Acked-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com> Cc: Brendan Jackman <jackmanb@google.com> Cc: Eugenio Pérez <eperezma@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09mm/kmemleak: fix checksum computation for per-cpu objectsBreno Leitao
The per-cpu object checksum folds each CPU's CRC together with XOR and seeds every CRC with 0. Both choices make update_checksum() miss content changes: - XOR is self-cancelling, so equal contents on two CPUs cancel out and simultaneous identical changes leave the checksum unchanged. - crc32(0, ...) over all-zero content is 0, so a freshly allocated, zeroed per-cpu area checksums to 0, matching the initial value, and the object is never seen to change. See discussions at [0]. When update_checksum() wrongly reports an actively modified object as unchanged, kmemleak stops greying it for an extra scan and can report a live per-cpu object as a leak. Fold the per-cpu CRC as a single rolling checksum across all CPUs and initialise the object checksum to ~0 so the first computed value always registers as a change, even for content that hashes to 0. reset_checksum() is seeded the same way. Link: https://lore.kernel.org/all/akfYImSNDh3OjIfR@gmail.com [0] Link: https://lore.kernel.org/20260703-kmemleak_checksum-v1-1-5e0ab7d6966f@debian.org Fixes: 6c99d4eb7c5e ("kmemleak: enable tracking for percpu pointers") Signed-off-by: Breno Leitao <leitao@debian.org> Co-developed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09mm/damon/core: disallow overlapping input ranges for damon_set_regions()SJ Park
damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for regions setting") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for regions setting"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260703165610.92894-1-sj@kernel.org Link: https://lore.kernel.org/20260630041806.151124-1-sj@kernel.org [1] Fixes: 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for regions setting") Signed-off-by: SJ Park <sj@kernel.org> Cc: <stable@vger.kernel.org> # 5.19.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09MAINTAINERS: add Usama as a THP reviewerLance Yang
Usama has been active around THP, really enjoys working on THPs, and tries to review all the patches that come in. Let's invite him to the THP party as a reviewer to help with the ongoing THP review load. Link: https://lore.kernel.org/20260702140257.44780-1-lance.yang@linux.dev Signed-off-by: Lance Yang <lance.yang@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: Barry Song <baohua@kernel.org> Acked-by: SJ Park <sj@kernel.org> Acked-by: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Dev Jain <dev.jain@arm.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09fat: avoid stack overflow warningArnd Bergmann
Building the fat kunit tests on with -fsanitize=alignment reveals some rather excessive stack usage: fs/fat/fat_test.c: In function 'fat_clus_to_blknr_test': fs/fat/fat_test.c:33:1: error: the frame size of 4736 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] 33 | } | ^ fs/fat/fat_test.c: In function 'fat_get_blknr_offset_test': fs/fat/fat_test.c:52:1: error: the frame size of 4800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] The problem is clearly related to the on-stack copy of a local msdos_sb_info structure. Avoid this by making that copy 'static const' and changing the called functions to accept a constant input. Link: https://lore.kernel.org/20260515204456.2692208-1-arnd@kernel.org Fixes: 410002f8139c ("kunit: fat: test cluster and directory i_pos layout helpers") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Adi Nata <adinata.softwareengineer@gmail.com> Cc: David Laight <david.laight.linux@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09mm/damon/core: validate ranges in damon_set_regions()SJ Park
DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function. Link: https://lore.kernel.org/20260630035221.146458-1-sj@kernel.org Fixes: 43b0536cb471 ("mm/damon: introduce DAMON-based Reclamation (DAMON_RECLAIM)") Signed-off-by: SJ Park <sj@kernel.org> Cc: Yang yingliang <yangyingliang@huawei.com> Cc: <stable@vger.kernel.org> # 5.16.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09m68k: avoid -Wunused-but-set-parameter in clear_user_page()Thomas Weißschuh
The loop in clear_user_pages() iterates over all pages and calls clear_user_page() for each of them. During the loop "vaddr" is modified. However on m68k clear_user() is a macro which does not use "vaddr". The compiler sees a variable which is modified but never used and emits a warning for that: include/linux/highmem.h: In function 'clear_user_pages': include/linux/highmem.h:234:63: warning: parameter 'vaddr' set but not used [-Wunused-but-set-parameter=] static inline void clear_user_pages(void *addr, unsigned long vaddr, Other architectures use an inline function for clear_user_page() which avoids the warning. This is not possible on m68k, as dlush_dcache_page() is another macro which is not yet defined where clear_user_page() is defined. Including cacheflush_mm.h will trigger recursive and lots of other issues. So hide the warning with a cast to (void) instead. While we are here, do the same for copy_user_page(). Link: https://lore.kernel.org/20260525-m68k-clear_user_page-v2-1-0c8981c6eca1@weissschuh.net Fixes: 62a9f5a85b98 ("mm: introduce clear_pages() and clear_user_pages()") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Ankur Arora <ankur.a.arora@oracle.com> Cc: David Hildenbrand <david@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09mm/huge_memory: set PG_has_hwpoisoned only after new folio head is establishedRik van Riel
__split_folio_to_order() copies the hwpoison state onto each new sub-folio while splitting a folio to a non-zero order. It does so via if (handle_hwpoison && page_range_has_hwpoisoned(new_head, new_nr_pages)) folio_set_has_hwpoisoned(new_folio); *before* clear_compound_head(new_head)/prep_compound_page(new_head, ...) turns @new_head from a tail page into a proper folio head. PG_has_hwpoisoned is a FOLIO_SECOND_PAGE flag, so folio_set_has_hwpoisoned() resolves to folio_flags(folio, 1). With the new compound_info-based page-flags layout, folio_flags() asserts the page is not a tail: VM_BUG_ON_PGFLAGS(page->compound_info & 1, page); VM_BUG_ON_PGFLAGS(n > 0 && !test_bit(PG_head, &page->flags.f), page); At the current call site @new_head still has the tail marker (compound_info bit 0 set, PG_head clear), so on CONFIG_DEBUG_VM kernels this hits: kernel BUG at include/linux/page-flags.h:354 folio_flags+0x82 folio_set_has_hwpoisoned __split_folio_to_order __split_unmapped_folio __folio_split truncate_inode_partial_folio (shmem hole-punch / MADV_REMOVE) Reproduced by syzkaller: hwpoison-inject a few subpages of a large shmem folio, then MADV_REMOVE (fallocate punch hole) on the same range, which splits the partial folio to a non-zero order. memory_failure() tries to split the poisoned folio to order 0 first, but that split is best-effort; when it fails the folio is left large with PG_has_hwpoisoned set, the case fa5a06170036 added this hwpoison copying for. Move the folio_set_has_hwpoisoned() call to after clear_compound_head()/prep_compound_page(), where @new_folio is a real order-new_order head folio (handle_hwpoison implies new_order != 0, so a second page always exists). The flag still lands on the same struct page (page[1] of the new folio); only the ordering relative to compound-head setup changes, satisfying the FOLIO_SECOND_PAGE precondition. Link: https://lore.kernel.org/20260701174235.3173401-1-riel@surriel.com Fixes: fa5a06170036 ("mm/huge_memory: preserve PG_has_hwpoisoned if a folio is split to >0 order") Signed-off-by: Rik van Riel <riel@surriel.com> Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Tested-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Yang Shi <yang@os.amperecomputing.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09mm/page_vma_mapped: fix device-private PMD handlingWei Yang
Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") introduced the concept of device-private PMD entries, but did not correctly update the rmap walk code to account for them. As a result, when page_vma_mapped_walk() encounters device-private PMD entries, it takes no action other than to acquire the PMD lock and exit. However this is highly problematic for two reasons - firstly, device private entries possess a PFN so check_pmd() needs to be called to ensure an overlapping PFN range. Secondly, and more importantly, if PVMW_MIGRATION is set the caller assumes the returned entry is a migration entry, resulting in memory corruption when the caller tries to interpret the device private entry as such. In addition, commit 146287290023 ("mm/huge_memory: implement device-private THP splitting") allowed device private PMDs to be split like THP mappings, but again did not update this code path. As a result, we might race a PMD split prior to acquiring the PMD lock. This patch addresses all of these issues by invoking check_pmd(), ensuring PMVW_MIGRATION is not set and checks whether a split raced us we do for PMD THP and migration entries. Instead of checking for a subset of the cases after taking the pmd_lock(), put device-private along with pmd_trans_huge() and pmd_is_migration_entry(). Also remove thp_migration_supported() as it is already guarded by pmd_is_migration_entry(). [akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David] Link: https://lore.kernel.org/20260630021540.17297-1-richard.weiyang@gmail.com Fixes: 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") Signed-off-by: Wei Yang <richard.weiyang@gmail.com> Suggested-by: David Hildenbrand <david@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Acked-by: Balbir Singh <balbirs@nvidia.com> Tested-by: Klara Modin <klarasmodin@gmail.com> Cc: SeongJae Park <sj@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: <stable@vger.kernel.org>q Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09MAINTAINERS: s/SeongJae/SJ/SJ Park
My legal and preferred first names are SeongJae and SJ, respectively. I was using the legal name for commits and tags, while using the preferred name for conversations. It sometimes confuses people including myself. Consistently use the preferred name. Together remove copyright notes on files. Those are only confusing for people who are not familiar with the law. Meanwhile, we can infer the information in a better way from git logs and public information. Link: https://lore.kernel.org/20260630013820.143366-1-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Acked-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09userfaultfd: prevent registration of special VMAsMike Rapoport (Microsoft)
Vova Tokarev says: userfaultfd allows registration on shadow stack VMAs. With userfaultfd access, you can register on the shadow stack, discard a page ... and inject a page with chosen return addresses via UFFDIO_COPY. Update vma_can_userfault() to reject VM_SHADOW_STACK. While on it, also reject VM_SPECIAL so that if a driver would implement vm_uffd_ops, it wouldn't be possible to register special VMAs with userfaultfd. Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude hugetlb VMAs from the check for VM_SPECIAL. Link: https://lore.kernel.org/20260618095017.2553004-1-rppt@kernel.org Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory") Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reported-by: vova tokarev <vladimirelitokarev@gmail.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Linus Torvalds <torvalds@linuxfoundation.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Xu <peterx@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-09xen-blkfront: fix double completion of split requests on resumeDoruk Tan Ozturk
When a block request is too large for a single ring entry and the backend does not support indirect descriptors, blkfront splits it across two ring requests. This only happens when the frontend runs on a 64K-page kernel (e.g. arm64): there, even a single-page request may not fit in one ring slot and must be split. blkif_ring_get_request() is called twice and both shadow slots (shadow[id] and shadow[extra_id]) point at the *same* struct request, linked through associated_id. blkif_completion() collapses the pair on the normal completion path, recycling the second slot and completing the request once. The suspend/resume walk in blkfront_resume() does not: it visits every shadow slot with ->request set and calls blk_mq_end_request() or re-queues ->request. For an in-flight split request it therefore processes the shared struct request twice on resume/migration -- a double completion. Skip the secondary slot of a split request in the resume walk so each logical request is processed exactly once. The secondary slot is the linked one (associated_id != NO_ASSOCIATED_ID) that carries no scatter-gather list (num_sg == 0); the first slot always keeps the sg list. The bug is only reachable on suspend/resume or live migration of such a guest, so it has no local reproducer. Fixes: 6cc568339047 ("xen/blkfront: Handle non-indirect grant with 64KB pages") Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Link: https://patch.msgid.link/20260709100853.7489-1-doruk@0sec.ai Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-09rust: allow `clippy::unwrap_or_default` globallyAlexandre Courbot
Starting with rustc 1.88, the `clippy::unwrap_or_default` lint triggers on `rust/kernel/soc.rs` if `CONFIG_CC_OPTIMIZE_FOR_SIZE=y`: warning: use of `unwrap_or` to construct default value --> ../rust/kernel/soc.rs:66:10 | 66 | .unwrap_or(core::ptr::null()) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()` This is a clippy bug [1]: the lint decides whether an expression is equivalent to `Default::default()` by inspecting the optimized MIR of `<*const T as Default>::default` exported by `core`, so its outcome depends on the optimization level `core` was built with. Moreover, its suggestion ignores our MSRV of 1.85 (`Default` for `*const T` is only stable since Rust 1.88), so we could not apply it anyway. Disable the lint globally rather than working around this single occurrence; it can be re-enabled conditionally using `rustc-min-version` once clippy is fixed. Link: https://github.com/rust-lang/rust-clippy/issues/17379 [1] Suggested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://patch.msgid.link/20260708-soc_unwrap_or-v2-1-007ed724cc7b@nvidia.com [ Moved to non-versioned group. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-07-09tools/sched_ext: scx - Fix cmask_subset(), cmask_equal() and cmask_weight()Tejun Heo
cmask_equal(), cmask_weight() and cmask_subset() bounded their word walks with CMASK_NR_WORDS(nr_cids), which pads by one word and can't tell the last word in use without @base. The walks could thus cover a slack word past the active range, which cmask_reframe() leaves non-zero: a stale bit there gave cmask_equal() a spurious mismatch, cmask_weight() an inflated count, and cmask_subset() a spurious violation. cmask_subset() could also read @b->bits[] one word past its allocation (within the arena's fault-recovered range, so harmless), and deviated from the kernel scx_cmask_subset() by failing any @a range that doesn't nest inside @b's even when the overhanging bits are all clear. Bound the cmask_equal() and cmask_weight() walks by the words the range actually spans, with early returns for empty ranges. Rewrite cmask_subset() to match the kernel semantics: scan @a's overhangs for set bits with cmask_next_set() and walk the words of the range intersection. cmask_subset() moves below cmask_next_set(), which it now uses. Padding bits don't need masking as every cmask helper keeps them clear. Fixes: a58e6b79b432 ("sched_ext: Add cmask, a base-windowed bitmap over cid space") Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-07-09sched_ext: Fix premature ops->priv publication in scx_alloc_and_add_sched()Tejun Heo
scx_alloc_and_add_sched() publishes @sch through ops->priv before allocating the cgroup path. If that allocation fails, the unwind path clears ops->priv and frees @sch immediately. scx_prog_sched() callers can dereference ops->priv from RCU context the moment it is set, so freeing without a grace period can use-after-free a concurrent kfunc caller. Move the publication below the cgroup path allocation so that every failure path after publication frees @sch through kobject_put(), whose release path defers the freeing by a grace period. Fixes: 105dcd005be2 ("sched_ext: Introduce scx_prog_sched()") Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-07-09sched_ext: Record an error on errno-only sub-enable failureTejun Heo
scx_sub_enable_workfn() has several failure paths that only return an errno (e.g. -ENOMEM from an allocation) and jump to err_disable without calling scx_error(). scx_flush_disable_work() runs the disable, and thus ops.exit(), only when an error has been recorded, so an errno-only failure leaves the half-initialized sub-scheduler linked. Record an error at the err_disable sink so every errno-only failure runs the disable path. Fixes: ebeca1f930ea ("sched_ext: Introduce cgroup sub-sched support") Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-07-09cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freqRafael J. Wysocki
If arch_scale_freq_ref() is not defined for a given arch (like x86, for example), cpufreq_update_pressure() will always set cpufreq_pressure to zero for all CPUs in the system, which is generally problematic on systems with asymmetric capacity [1]. However, in the absence of arch_scale_freq_ref(), it is reasonable to assume that cpuinfo.max_freq is the maximum sustainable frequency for the given cpufreq policy. Moreover, there are cases in which arch_scale_freq_ref() would need to be defined to return essentially the cpuinfo.max_freq value anyway (for example, intel_pstate on hybrid platforms). For the above reasons, update cpufreq_update_pressure() to fall back to using cpuinfo.max_freq as the reference frequency if zero is returned by arch_scale_freq_ref(). Fixes: 75d659317bb1 ("cpufreq: Add a cpufreq pressure feedback for the scheduler") Link: https://lore.kernel.org/lkml/CAKfTPtBuRLfYNnR4w--cFZYZy-R8gaPEgVwCcaMmbCcJ2H-muQ@mail.gmail.com/ [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> # cluster scheduling Acked-by: Vincent Guittot <vincent.guittot@linaro.org> Link: https://patch.msgid.link/5086499.GXAFRqVoOG@rafael.j.wysocki
2026-07-09cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()Rafael J. Wysocki
Setting cpu->capacity_perf to cpu->pstate.max_pstate_physical in the "no turbo" case is inconsistent with what happens elsewhere in the driver and causes arch_scale_cpu_capacity() to be incorrect. It also skews arch_scale_freq_capacity() which ends up differing from 1024 for the guaranteed P-state. Address that by setting capacity_perf to HWP_GUARANTEED_PERF() in the "no turbo" case. Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Cc: All applicable <stable@vger.kernel.org> Link: https://patch.msgid.link/12928972.O9o76ZdvQC@rafael.j.wysocki
2026-07-09Revert "io_uring: grab RCU read lock marking task run"Jens Axboe
This reverts commit ed64f5c546b3d5e3a4840f6c055448ce90edf56c. Since commit: 648790e09527 ("io_uring: restore RCU read section in io_req_local_work_add()") io_ctx_mark_taskrun() is only ever called with the RCU read lock already held, like previously. Hence's there's no need for this commit anymore, which grabbed the RCU read lock inside io_ctx_mark_taskrun(). Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-09io_uring: restore RCU read section in io_req_local_work_add()Woraphat Khiaodaeng
The task-work refactor that moved io_req_local_work_add() out of io_uring.c into the new io_uring/tw.c dropped the whole-body guard(rcu)() that used to cover the function body. For DEFER_TASKRUN rings the ring teardown still relies on that RCU read section pairing with its grace period: /* pairs with RCU read section in io_req_local_work_add() */ if (ctx->flags & IORING_SETUP_DEFER_TASKRUN) synchronize_rcu(); io_ring_ctx_free(ctx); io_req_local_work_add() keeps dereferencing ctx after mpscq_push() has published the request to the work list (ctx->cq_wait_nr, and ctx->submitter_task in the final wake_up_state()), without holding a ctx reference across that window. The RCU read section was the only thing guaranteeing an in-flight adder had finished touching ctx before io_ring_ctx_free() ran; synchronize_rcu() only waits for readers that are actually inside an RCU read-side critical section. With the guard gone the grace period no longer pairs with anything on the add side, so ctx can be freed and reused while io_req_local_work_add() is still using it. Fixes: d46ab2c98aba ("io_uring: switch local task_work to a mpscq") Signed-off-by: Woraphat Khiaodaeng <worapat.kd2@gmail.com> Link: https://patch.msgid.link/20260709035100.2269-1-worapat.kd2@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-09smb: client: mask server-provided mode to 07777 in modefromsidNorbert Manthey
When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path. Fixes: e2f8fbfb8d09c ("cifs: get mode bits from special sid on stat") Signed-off-by: Norbert Manthey <nmanthey@amazon.de> Assisted-by: Kiro:claude-opus-4.6 Cc: stable@vger.kernel.org Signed-off-by: Steve French <stfrench@microsoft.com>
2026-07-09bpf: Fix UAF in sock clone early bailoutsMatt Bobrowski
Similar to recent commit 9b51a6155d14 ("bpf,fork: wipe ->bpf_storage before bailouts that access it"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone(). Fixes: 6ac99e8f23d4 ("bpf: Introduce bpf sk local storage") Fixes: f12dd75959b0 ("bpf: net: Set sk_bpf_storage back to NULL for cloned sk") Signed-off-by: Matt Bobrowski <mattbobrowski@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20260709025316.999913-1-mattbobrowski@google.com
2026-07-09ALSA: hda: MAINTAINERS: Fix missing cirrus* file referenceRichard Fitzgerald
When the HDA source was reorganized some of the cirrus* files were moved into a new 'side-codecs' subdirectory. But MAINTAINERS wasn't updated to add a cirrus* file reference to cover these moved files. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260709122211.615785-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-09ALSA: hda/cirrus_scodec: Make Kconfig visible if KUNITRichard Fitzgerald
Make the Kconfig item for cirrus_scodec visible if CONFIG_KUNIT is enabled. This is so that its KUnit test can be enabled by KUnit scripts without requiring a large amount of irrelevant additional components. The general rule for KUNIT_ALL_TESTS is that it should only enable tests for components that are already selected. However, the UML environment does not support ACPI, which means the HDA codec drivers that use cirrus_scodec cannot be selected. But cirrus_scodec does not need ACPI. By making the Kconfig option visible if CONFIG_KUNIT, the KUnit test can be enabled with only the minimal set of functionality that is required for cirrus_scodec. This is still compliant with the KUNIT_ALL_TESTS rule "only tests for enabled modules" because by default cirrus_scodec will only be enabled if the drivers that use it are enabled. It must be intentionally enabled to force it to be included for testing. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://patch.msgid.link/20260709121224.614350-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-07-09Merge tag 'net-7.2-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from netfilter, Bluetooth and batman-adv. Current release - regressions: - bluetooth: fix using chan->conn as indication to no remote netdev Current release - new code bugs: - netfilter: cap to maximum number of expectation per master on updates Previous releases - regressions: - bluetooth: - fix UAF of hci_conn_params in add_device_complete - fix null ptr deref in hci_abort_conn() - igmp: remove multicast group from hash table on device destruction - batman-adv: prevent TVLV OOB check overflow - eth: mlx5/mlx5e: - fix off-by-one in single-FDB error rollback - skip peer flow cleanup when LAG seq is unavailable - fix crashes in dynamic per-channel stats and HV VHCA agent - eth: mana: Sync page pool RX frags for CPU Previous releases - always broken: - netfilter: - mark malformed IPv6 extension headers for hotdrop - terminate table name before find_table_lock() - ipvs: use parsed transport offset in TCP state lookup - sched: act_pedit: fix TOCTOU heap OOB write in tc offload - ethtool: rss: fix hfunc and input_xfrm parsing on big endian - ipv4/ipv6: fix UAF and memory leak in IGMP/MLD - tls: consume empty data records in tls_sw_read_sock() - eth: - octeontx2-af: fix VF bringup affecting PF promiscuous state - gue: validate REMCSUM private option length" * tag 'net-7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (94 commits) macsec: don't read an unset MAC header in macsec_encrypt() dibs: loopback: validate offset and size in move_data() octeontx2-af: fix VF bringup affecting PF promiscuous state ethtool: rss: Fix hfunc and input_xfrm parsing on big endian net/mlx5: Fix L3 tunnel entropy refcount leak net: macb: drop in-flight Tx SKBs on close net: mana: Sync page pool RX frags for CPU net: mana: Validate the packet length reported by the NIC selftests/net: fix EVP_MD_CTX leak in tcp_mmap ipvs: ensure inner headers in ICMP errors are in headroom ipvs: use parsed transport offset in SCTP state lookup ipvs: use parsed transport offset in TCP state lookup ipvs: pass parsed transport offset to state handlers netfilter: handle unreadable frags netfilter: flowtable: support IPIP tunnel with direct xmit netfilter: flowtable: IPIP tunnel hardware offload is not yet support netfilter: flowtable: use dst in this direction when pushing IPIP header netfilter: ipset: allocate the proper memory for the generic hash structure netfilter: ipset: cleanup the add/del backlog when resize failed netfilter: ipset: exclude gc when resize is in progress ...
2026-07-09crypto: aes - Fix conditions for selecting MAC dependenciesEric Biggers
Starting in commit 7137cbf2b5c9 ("crypto: aes - Add cmac, xcbc, and cbcmac algorithms using library"), the aes module (CRYPTO_AES) supports CBC based MACs using the corresponding library functions. To avoid including unneeded functionality, that support honors the existing CRYPTO_CMAC, CRYPTO_XCBC, and CRYPTO_CCM kconfig options. The dependencies are selected if at least one of those is enabled. However, the select statements don't correctly handle the case where CRYPTO_AES=y and (for example) CRYPTO_CMAC=m. In that case the dependencies get selected at level 'm', due to how the kconfig language works. That causes a linker error. Fix this by changing the selection conditions to use '!= n'. A similar issue also exists for CRYPTO_LIB_AES's conditional selection of CRYPTO_LIB_UTILS. The same '!= n' would work, but instead just make CRYPTO_LIB_AES always select CRYPTO_LIB_UTILS. CRYPTO_LIB_UTILS is lightweight, and it's needed by most AES modes and many other things. Fixes: 7137cbf2b5c9 ("crypto: aes - Add cmac, xcbc, and cbcmac algorithms using library") Fixes: 309a7e514da7 ("lib/crypto: aes: Add support for CBC-based MACs") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260709022954.45113-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-09lib/crypto: docs: Improve introduction sentenceEric Biggers
Make it clear that lib/crypto/ is a kernel-internal library. It's easy for people to come across this page, especially the HTML version online, without that context. Reviewed-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260709022747.44635-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-09lib/crypto: docs: Fix some sentence fragmentsEric Biggers
Currently, the section about the library API for each algorithm begins with a noun phrase that was intended to serve as an elaboration on the title. It's better to use complete sentences. Suggested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260709022651.44216-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-09wifi: ath12k: Flush the posted write after writing to PCIE_SOC_GLOBAL_RESETManivannan Sadhasivam
ath12k_pci_soc_global_reset() tries to reset the device by writing to the PCIE_SOC_GLOBAL_RESET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before the delay. This may lead to the delay on the host to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the PCIE_SOC_GLOBAL_RESET register and before the delay. Compile tested only. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Reported-by: Alex Williamson <alex@shazbot.org> Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Tested-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Link: https://patch.msgid.link/20260623141649.41087-2-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-09wifi: ath11k: Flush the posted write after writing to PCIE_SOC_GLOBAL_RESETManivannan Sadhasivam
ath11k_pci_soc_global_reset() tries to reset the device by writing to the PCIE_SOC_GLOBAL_RESET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before the delay. This may lead to the delay on the host to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the PCIE_SOC_GLOBAL_RESET register and before the delay. Compile tested only. Fixes: f3c603d412b3 ("ath11k: reset MHI during power down and power up") Reported-by: Alex Williamson <alex@shazbot.org> Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Link: https://patch.msgid.link/20260623141649.41087-1-manivannan.sadhasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-09wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get()Dmitry Morgun
When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Dmitry Morgun <d.morgun@ispras.ru> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260530114252.42615-1-d.morgun@ispras.ru Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>