Merge tag 'powerpc-7.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Madhavan Srinivasan:
"KVM:
- fix use-after-free in kvmhv_emulate_tlbie_all_lpid()
- fix secure device page leak on uv_page_in() failure
iommu:
- Fix the overflow validation in iommu_tce_check_ioba
Thanks to Amit Machhiwal, Gautam Menghani, Ritesh Harjani (IBM), R
Nageswara Sastry, and Shivaprasad G Bhat"
* tag 'powerpc-7.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba
KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure
KVM: PPC: Book3S HV: fix use-after-free in kvmhv_emulate_tlbie_all_lpid()
powerpc/iommu: Fix the overflow validation in iommu_tce_check_ioba
The commit b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking") unified
IOBA parameter checking across KVM and VFIO into iommu_tce_check_ioba().
While doing so, the passed in argument npages is ignored and constant
value '1' is used leaving out a possible overflow as the callers can
legitimately be using npages > 1 for H_STUFF_TCE or H_PUT_TCE_INDIRECT
cases.
Fix this by accounting for 'npages', checking for arithmetic overflow,
and verifying that the entire requested range (ioba - offset + npages)
does not exceed the table capacity 'size'.
Fixes: b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking")
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list at gmail.com>
Tested-by: R Nageswara Sastry <rnsastry at linux.ibm.com>
Signed-off-by: Shivaprasad G Bhat <sbhat at linux.ibm.com>
Signed-off-by: Gautam Menghani <gautam at linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy at linux.ibm.com>
KVM: PPC: Book3S HV: fix secure device page leak on uv_page_in() failure
In kvmppc_svm_page_in(), if uv_page_in() fails after
kvmppc_uvmem_get_page() has succeeded, the secure device page is never
released. kvmppc_uvmem_get_page() sets a bit in kvmppc_uvmem_bitmap,
allocates a kvmppc_uvmem_page_pvt struct, marks the GFN as
KVMPPC_GFN_UVMEM_PFN, and calls zone_device_page_init() which sets
refcount=1 and locks the page. The subsequent goto out_finalize skips
the *mig.dst assignment, so migrate_vma_finalize() is a no-op for the
page, and none of those resources are ever reclaimed.
Each occurrence permanently consumes one entry from the firmware-bounded
secure memory pool (kvmppc_uvmem_bitmap), leaks pvt, and leaves the GFN
marked as secure — making it unusable for the lifetime of the VM.
The twin __kvmppc_svm_page_out() already handles the analogous uv_page_out()
failure correctly with unlock_page(dpage); __free_page(dpage). Apply
the same pattern here: unlock_page() followed by put_page(), which
chains through free_zone_device_folio() into kvmppc_uvmem_folio_free()
[11 lines not shown]
KVM: PPC: Book3S HV: fix use-after-free in kvmhv_emulate_tlbie_all_lpid()
kvmhv_emulate_tlbie_all_lpid() iterates the nested-guest IDR and drops
mmu_lock before calling kvmhv_emulate_tlbie_lpid(), but does not hold a
reference on the kvm_nested_guest pointer obtained from the IDR. A
concurrent vCPU issuing a single-LPID tlbie (is=2, ric=2) can race
through kvmhv_flush_nested() -> kvmhv_remove_nested() -> idr_remove /
--refcnt -> kvmhv_release_nested() -> kfree(gp) in that window, leaving
the iterating vCPU with a dangling pointer. The subsequent
mutex_lock(&gp->tlb_lock) and accesses to gp->shadow_pgtable,
gp->shadow_lpid and gp->l1_host all touch freed memory. The free path
is fully L1-controlled.
Fix this by incrementing gp->refcnt inside the loop before dropping
mmu_lock, mirroring what kvmhv_get_nested() does, and releasing the
reference with kvmhv_put_nested() after the per-guest work completes.
This is the same get/put discipline already used at every other
call site that drops mmu_lock while holding a nested-guest pointer.
[6 lines not shown]
Merge tag 'sched_ext-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext
Pull sched_ext fixes from Tejun Heo:
- An error raised by a BPF program before the scheduler finished
enabling was consumed by the disable path's pre-enable shortcut,
leaving a running scheduler that couldn't be disabled and was later
freed while in use.
- Two compat kfuncs dereferenced a NULL scheduler when handed an exited
or idle task, oopsing the kernel.
- Keep-running decisions in the dispatch path used the root scheduler's
flags for tasks belonging to a sub-scheduler, causing warnings and
stalls.
- Schedulers with their own CPU ID mapping had no way to learn which
IDs are online. Add a kernel-maintained online mask to plug the hole.
[19 lines not shown]
Merge tag 'cgroup-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fix from Tejun Heo:
- The task iterator could pick up a dying task whose refcount had
already dropped to zero and resurrect it, leading to a use-after-free
when reading cgroup.procs. Skip such tasks.
* tag 'cgroup-for-7.3-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cgroup: Avoid iteration of dying tasks with zero refcount
sched_ext: Maintain an online cid mask in the scheduler arena
Schedulers on the default cid mapping treat [0, nr_online_cids) as the
online set and restart on hotplug. Schedulers that install their own mapping
with scx_bpf_cid_override() have no way to learn which cids are online: the
count no longer identifies members and the CPU-form cpumask is unusable from
cid programs. This is an obvious hole in the cid API.
Add scx_bpf_online_cmask(), a kernel-maintained cmask in the scheduler's
arena, allocated alongside the per-CPU scratch masks and populated after the
cid mapping is finalized and before ops.init(), for child schedulers too.
The pointer stays valid through ops.exit() with no reference to take. It is
the arena offset as a void pointer, the same form struct_ops arena arguments
arrive in. The verifier types the void return as a scalar for the program's
arena cast.
The mask follows the SCX hotplug notifications: seeded from cpu_active_mask
and updated before ops.cid_online/offline() runs, so it lags cpu_online_mask
only inside a hotplug transition. Updates walk the scheduler list under the
[7 lines not shown]
sched_ext: scx_qmap: Restore unused idle claims from ops.dispatch()
scx_qmap tracks idle cids itself. pick_direct_dispatch_cid() claims a cid by
clearing its bit and the task is inserted into that cid's local DSQ, which
kicks the CPU. When the task does not arrive, for example because the insert
fell back to the global DSQ after an affinity change, the CPU wakes, finds
nothing and picks idle again. That is not an idle transition, so
ops.update_idle() is not called and the cid stays marked busy until an
unrelated task runs on it.
Restore the claim from ops.dispatch(). The kick guarantees a dispatch on the
kicked CPU, and when it finds nothing to run with a NULL @prev, the CPU is
going back to idle. Document the pattern in ops.update_idle(), which reports
only actual transitions.
Signed-off-by: Tejun Heo <tj at kernel.org>
Reviewed-by: Andrea Righi <arighi at nvidia.com>
Cc: Andrea Righi <arighi at nvidia.com>
Merge tag 'sysctl-7.03-fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl
Pull sysctl fixes from Joel Granados:
- Re-add the range check for millisecond to jiffy conversion in sysctl
They where removed in d174174c6776 ("sysctl: replace
SYSCTL_INT_CONV_CUSTOM macro with functions") and b96b5c6708ea
("sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vec")
- Fix type truncation in sysctl_msec_to_jiffies
Previously truncated millisecond values now get converted into
MAX_JIFFY_OFFSET
* tag 'sysctl-7.03-fixes-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/sysctl/sysctl:
sysctl: Fix type truncation in sysctl_msec_to_jiffies
sysctl: Check range in do_proc_ulong_conv_ms_jiffies
sysctl: Check range in proc_dointvec_ms_jiffies_minmax
sysctl: Check range in proc_dointvec_ms_jiffies_minmax
Add the range check to do_proc_int_conv_ms_jiffies_minmax that commit
d174174c6776 ("sysctl: replace SYSCTL_INT_CONV_CUSTOM macro with
functions") incorrectly removed.
Fixes: d174174c6776 ("sysctl: replace SYSCTL_INT_CONV_CUSTOM macro with functions")
Signed-off-by: Kuniyuki Iwashima <kuniyu at google.com>
Signed-off-by: Joel Granados <joel.granados at kernel.org>
sysctl: Fix type truncation in sysctl_msec_to_jiffies
Return MAX_JIFFY_OFFSET for all the values truncated when val (u64) is
passed to msecs_to_jiffies (u32). This aligns with how very large
millisecond values get translated into MAX_JIFFY_OFFSET.
Fixes: b96b5c6708ea ("sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vec")
Suggested-by: Kuniyuki Iwashima <kuniyu at google.com>
Signed-off-by: Joel Granados <joel.granados at kernel.org>
sysctl: Check range in do_proc_ulong_conv_ms_jiffies
Add the range check back to do_proc_ulong_conv_ms_jiffies that commit
b96b5c6708ea ("sysctl: Replace do_proc_do{int,ulong,uint}vec with
do_proc_vec") incorrectly removed. Append "_minmax" to the end of
do_proc_ulong_conv_ms_jiffies so it is clear that there should be a
range check.
Fixes: b96b5c6708ea ("sysctl: Replace do_proc_do{int,ulong,uint}vec with do_proc_vec")
Signed-off-by: Kuniyuki Iwashima <kuniyu at google.com>
Signed-off-by: Joel Granados <joel.granados at kernel.org>
cgroup: Avoid iteration of dying tasks with zero refcount
The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from
cgroup_task_release() to cgroup_task_free()") extended the lifetime of
tasks on the dying_tasks list.
The iterators have provision to go through dying_tasks because of
dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however,
it was expected that such tasks can obtain a new reference (that is
possible before cgroup_task_release()/put_task_struct_rcu_user()).
The tasks after cgroup_task_release() and before cgroup_task_free()
are subject to race when they may or may not have ->usage count > 0.
The race window is between css_task_iter_next() invocations
when css_set_lock is released and we may arrive at a new ->task_pos.
The iterator should not attempt to resurrect tasks whose ->usage count
dropped to zero. (When that happens, __put_task_struct_rcu_cb() is
already imminent and the returned task_struct would could be used
after free.)
[58 lines not shown]
Merge tag 'nfsd-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux
Pull nfsd fix from Chuck Lever:
- Fix handling of NFSEXP_PNFS in the netlink codepath
* tag 'nfsd-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux:
nfsd: fix handling of NFSEXP_PNFS in the netlink codepath
Merge tag '9p-for-7.3-rc4' of https://github.com/martinetd/linux
Pull 9pfs fix from Dominique Martinet:
"This is a single fix for a 9p/netfs regression that got in 7.1 (and
was backported to 7.0)
We need to rework how cached attributes, and in particular i_size, are
handled in 9p more thoroughly but that will take more time and this
appears to be enough for the most obvious problems"
* tag '9p-for-7.3-rc4' of https://github.com/martinetd/linux:
9p: Fix v9fs_issue_write() to update i_size and remote_i_size
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Jason Gunthorpe:
"Lots of bug fixes from the last weeks:
- Various error unwind bugs
- Several more races and bugs in siw and rxe, including remote
triggerable
- HFI1 corruption with its credit scheme
- Remove a bogus user triggerable dev_warn
- Lock __ethtool_get_link_ksettings() properly
- Fix a lockdep loop with diassociation
- Several storage related bugs, some triggerable remotely
[31 lines not shown]
Merge tag 'fixes-2026-09-14' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/memblock
Pull memblock fixes from Mike Rapoport:
"Fix for regions display in debugfs and MAINTAINERS update:
- Make sure that multiple flags on a memblock region are all
displayed in debugfs
- Update memblock tree tags in MAINTAINERS"
* tag 'fixes-2026-09-14' of git://git.kernel.org/pub/scm/linux/kernel/git/mm/memblock:
MAINTAINERS: update memblock tree URLs
mm: memblock: show all region flags in debugfs
Merge tag 'mm-hotfixes-stable-2026-09-13-21-50' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull misc fixes from Andrew Morton:
"14 hotfixes. 10 are cc:stable. 11 are for MM.
All are singletons - please see the changelogs for details"
* tag 'mm-hotfixes-stable-2026-09-13-21-50' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
mm/folio: EXPORT_SYMBOL_FOR_KVM(lru_cache_drain_for_folio)
mm/shrinker: fix bogus set_shrinker_bit() with cgroup.memory=nokmem
mm/vma: correctly unaccount on mmap_prepare() failure
mm/mlock: use the IRQ-safe accessor for NR_MLOCK in __munlock_folio()
remove old lib/alloc_tag.c
fs/dax: check zero or empty entry before converting xarray entry
fs: fix missed removal of super_fs_objects_eligible()
mm: filemap: retain mapped dropbehind folios
mailmap: update entry for Christopher Obbard
memcg: avoid charging the root memcg from obj_cgroup_charge_pages()
mm, swap: fix SWAP_USAGE_OFFLIST_BIT collision with real usage count
[3 lines not shown]
Merge tag 'x86_urgent_for_7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Dave Hansen:
"The most notable fix is THP not silently losing user data and having
been around for a couple of years. The main explanation I'd have for
its longevity is that it requires a few different things to align at
the same time: MADV_FREE, THP and heavy reclaim.
- Fix user-space data loss with THP
- Fix set_memory oopses
- Fix addition of large constants in mul_u64_add_u64_div_u64()
- Fix FineIBT hash offset in cfi_get_func_hash()
- Fix PCI device reference counting in amd_smn_init()"
* tag 'x86_urgent_for_7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
[8 lines not shown]
Merge tag 'trace-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull tracing fixes from Steven Rostedt:
- Don't destroy user event fields when removal fails
User event fields are destroyed before the event is removed from
visibility. But that can fail leaving the still visible event with no
fields. Move the destroying of the fields to after the event is
successfully removed from visibility.
- Initialize function graph state is fork before calling
copy_exec_state()
For non-CLONE_VM forks, copy_exec_state() allocates a new
task_exec_state. If that allocation fails, ftrace_graph_exit_task()
will free the tasks ret_stack pointer. Since that pointer is still
using the parent's ret_stack, it mistakenly frees the parent's
pointer too.
[169 lines not shown]
Merge misc regression fixes that seem to have fallen through the cracks
Thorsten continues to track regressions, and reporting on known issues
with fixes that don't seem to make any progress.
I'm going to do an rc3 release later today - let's not keep these known
issues pending for yet another rc for no obvious reason.
Reported-by: Thorsten Leemhuis <regressions at leemhuis.info>
Link: https://lore.kernel.org/all/46403cf8-9a81-4596-87eb-dde58ae4c5db@leemhuis.info/
* regressions:
media: ipu-bridge: do not use the CVS device lookup for IVSC
wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe
wifi: mt76: mt7921: skip unknown CLC firmware records
media: ipu-bridge: do not use the CVS device lookup for IVSC
Since commit c6b1b34b5090 ("media: pci: intel: Add CVS support for IPU
bridge driver") the internal camera no longer works on laptops where the
sensor sits behind an IVSC, for example a Dell XPS 16 9640 (IPU6,
INTC10CF, ov02c10):
intel-ipu6 0000:00:05.0: Found supported sensor OVTI02C1:00
intel-ipu6 0000:00:05.0: Connected 1 cameras
ivsc_csi intel_vsc-92335fcf-3203-4472-af93-7b4453ac29da: mei-csi probed
without device fwnode!
No sensor subdevice is registered, the media graph has no sensor entity
and userspace finds no camera at all.
ipu_bridge_get_ivsc_csi_dev() first looks for the platform device named
"intel_vsc" and returns its mei-csi child. That device is created by
mei_vsc, which on this machine only appears once the LJCA USB bridge and
its SPI controller have probed, about a second after the IPU6 probe that
[36 lines not shown]
wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe
Some laptops carry a MediaTek power table in their firmware, and the
driver reads it to set a transmit limit for each frequency range. It
only fills in the ranges themselves when it registers the device.
The startup step that does this existed already, but it never programmed
anything. Two recent commits made it run a regulatory update instead,
which sets the limits on the way through, long before registration.
As a result, on a machine that has the table the driver reads through an
empty pointer and the interface never appears:
BUG: kernel NULL pointer dereference, address: 0000000000000004
RIP: 0010:mt792x_init_acpi_sar_power
Call Trace:
mt7921_set_tx_sar_pwr
mt7921_mcu_regd_update
mt7921_regd_update
[15 lines not shown]
wifi: mt76: mt7921: skip unknown CLC firmware records
Treat an out-of-range CLC index as newer firmware rather than a
malformed image. linux-firmware 20260810 ships MT7922 records with
idx 3, and rejecting them made mt7921e fail to probe.
Keep the record-length checks, and report those as errors so a
truncated table is visible instead of a silent retry loop.
Fixes: 9417c5818a01 ("wifi: mt76: mt7921: validate CLC firmware records")
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov at gmail.com>
Signed-off-by: Laxman Acharya Padhya <acharyalaxman8848 at gmail.com>
Reviewed-by: Junjie Cao <junjie.cao at intel.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov at gmail.com>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
ring-buffer: Check resize_disabled before publishing the new subbuf order
ring_buffer_subbuf_order_set() stores the new order and only then walks
the CPUs, returning -EBUSY if any of them has resizing disabled. A user
mapped buffer has resizing disabled, and __rb_map_vma() reads
buffer->subbuf_order without buffer->mutex, so an mmap of an already
mapped CPU racing the failing order change sizes the mapping with the
new order and inserts pages past the sub-buffer into the VMA.
Check the CPUs before storing the new order.
Cc: stable at vger.kernel.org
Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions")
Link: https://patch.msgid.link/20260912103938.1127021-1-devnexen@gmail.com
Signed-off-by: David Carlier <devnexen at gmail.com>
Signed-off-by: Steven Rostedt <rostedt at goodmis.org>
tracing/remotes: Catch nr_page_va overflow in ring_buffer_desc sizing
The number of pages per remote ring buffer is capped by
ring_buffer_desc::nr_page_va (32 bits). A buffer_size large enough to
overflow that field would silently allocate a descriptor smaller than
what was asked for.
Return SIZE_MAX from trace_buffer_desc_size() on nr_page_va overflow.
Link: https://patch.msgid.link/20260911193937.602202-3-vdonnefort@google.com
Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes")
Signed-off-by: Vincent Donnefort <vdonnefort at google.com>
Signed-off-by: Steven Rostedt <rostedt at goodmis.org>
tracing/remotes: Account for ring buffer page header in size calculation
trace_buffer_desc_size() and trace_remote_alloc_buffer() undercount the
required pages because every ring buffer page contains a header
(BUF_PAGE_HDR_SIZE). Account for that header to ensure allocated remote
ring buffers aren't smaller than requested by the user.
The newly introduced helper __calc_nr_pages_ring_buffer_desc() can
return a value that overflows the descriptor nr_pages field (32 bits).
Link: https://patch.msgid.link/20260911193937.602202-2-vdonnefort@google.com
Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes")
Signed-off-by: Vincent Donnefort <vdonnefort at google.com>
Signed-off-by: Steven Rostedt <rostedt at goodmis.org>
Merge tag 'rust-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull Rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:
- Work around a 'bindgen' 0.73.2 bug that emits an 'allow' attribute
for 'unnecessary_transmutes', which is unknown in older compilers
- Clean 'clippy::as_underscore' lints in generated code by the new
'bindgen' 0.73.0+ releases
- Clean new 'clippy::needless_range_loop' lint for the upcoming Rust
1.100.0 (expected 2026-11-12)
'kernel' crate:
- 'num' module: fix soundness issue in 'Bounded' by sealing the
'Integer' trait
[16 lines not shown]
Merge tag 'bootconfig-fixes-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull bootconfig fixes from Masami Hiramatsu:
"Fix integer overflow and truncation in size checks.
- Fix size check bypasses caused by integer overflow and truncation
when parsing initrd or standalone bootconfig files, preventing
buffer overflow and out-of-bounds writes in the userspace tool.
- Fix pointer arithmetic wrap-around in get_boot_config_from_initrd()
when handling crafted huge size values, preventing fatal kernel
page faults during early boot"
* tag 'bootconfig-fixes-v7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
bootconfig: Fix integer overflow in initrd size check
tools/bootconfig: Fix integer overflow and truncation in size checks
