may_copy_tree() accepts a mount whose root is an nsfs or pidfs file
before it checks whether that mount is mounted. This exception exists
for nsfs and pidfs mounts. They are part of no mount namespace so
neither check_mnt() nor is_mounted() would let them through and
bind-mounting a nsfsfd or a pidfd wouldn't work.
Problem is that exception also admits a bind mount of such a file when
it was lazily unmounted and is only kept alive by a file descriptor:
mount --bind /proc/self/ns/net /tmp/x
exec 3< /tmp/x
umount -l /tmp/x
mount --rbind /proc/self/fd/3 /tmp/y
With MS_REC or AT_RECURSIVE copy_tree() doesn't stop at the unmounted
mount. It copies every mount that stayed attached to it as well. So if
you have a bunch of overmounts over the nsfsfd or the pidfd the whole
unmounted stack is copied. That's a bug.
So refuse to walk an unmounted tree. Copying its root alone stays
possible. So a bind mount of a namespace that is gone can still be
recreated from a file descriptor on the old one. The file descriptor
pins that mount and its root and __has_locked_children() only reads the
direct children which don't leave the parent's list without
namespace_sem. The internal mounts carry MNT_NS_INTERNAL instead of NULL
and are still walked. Copying an unmounted tree recursively fails with
EINVAL.
Fixes: e149ed2b80 ("take the targets of /proc/*/ns/* symlinks to separate fs")
Fixes: ef4144ac2d ("pidfs: allow bind-mounts")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-4-f357abf3d17b@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
MNT_UMOUNT gets raised on a mount that umount_tree() or umount_one() has
taken out of its namespace. It's never cleared. __detach_mounts()
unhooks a mount that carries it instead of unmounting it.
disconnect_mount() lets an unmounted child stay attached only if its
parent carries it. propagate_umount() takes it as the sign that a mount
is going to be unmounted when it decides what else can be unmounted,
where a chain of locked mounts ends and where a for reparenting an
overmount.
clone_mnt() copies the flags of the source and only masks
MNT_INTERNAL_FLAGS which doesn't include MNT_UMOUNT. A mount that was
lazily unmounted but is kept alive by a file descriptor can still be
copied when its root is an nsfs or pidfs file because may_copy_tree()
accepts those before checking whether the source is mounted at all:
mount --bind /proc/self/ns/net /tmp/x
exec 3< /tmp/x
umount -l /tmp/x
mount --bind /proc/self/fd/3 /tmp/y
The mount on /tmp/y is attached to the caller's namespace with
MNT_UMOUNT already set and every copy of it inherits the flag again.
That causes a number of bugs:
- Unlink its mountpoint from a mount namespace where it isn't one.
__detach_mounts() takes it for a mount that was unmounted earlier,
unhooks it from its parent and drops the reference the namespace
holds on it. It stays in the namespace with one reference too few
and as its own parent, so it can't be unmounted through the file
descriptor anymore and the namespace never finds it again. When the
namespace goes away it's leaked and points to a freed struct
mnt_namespace that may_change_propagation() and anon_ns_root() read
on the next propagation change or mount_setattr() through the file
descriptor.
- Make it shared and unmount a peer. trace_transfers() follows the
flag from the peer into it and strips it from its peer group.
- Let a propagated umount reach it. gather_candidates() marks it with
T_UMOUNT_CANDIDATE but never puts it on the candidate list, so the
mark is never cleared and every later propagated umount skips it. If
it's the parent of a locked mount handle_locked() takes it as the
cutoff and commits the locked child that should have stayed and
disconnect_mount() leaves that child attached to it, unmounted under
a mounted parent, which is what disconnect_mount() exists to
prevent. When the namespace goes away umount_tree() visits the child
a second time. And once __detach_mounts() has made it its own parent
reparent() never finds the end of the chain of unmounted parents.
A clone is a new mount that has never been unmounted. Add MNT_UMOUNT
to MNT_INTERNAL_FLAGS so clone_mnt() never copies it. And warn when
umount_tree() reaches a mount that already has it set.
Fixes: 590ce4bcbf ("mnt: Add MNT_UMOUNT flag")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-3-f357abf3d17b@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
statmount_mnt_basic() reads the ids of the parent through m->mnt_parent
with namespace_sem held for reading. That's fine for a mount that is
in a namespace. Everything above it is pinned by that namespace.
STATMOUNT_BY_FD also accepts a file descriptor on a mount that has
been unmounted on purpose and that only the file descriptor keeps alive.
If that mount stayed attached to its parent when it was unmounted the
parent is unmounted as well and nothing pins it for the child.
The final mntput() unmounts the children under mount_lock alone and
frees the parent afterwards. Concurrently, statmount_mnt_basic() reads
m->mnt_parent twice while that can happen and can easily dereference a
mount that's already gone.
Read the parent of an unmounted mount under mount_lock. The parent
can't be put while it is held and both ids come from the same mount. A
mounted mount's parent is pinned by the namespace and a mount can't
leave its namespace while namespace_sem is held, so the common case
takes no global lock.
Fixes: 0e5032237e ("statmount: accept fd as a parameter")
Cc: stable@vger.kernel.org # v7.0+
Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-2-f357abf3d17b@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
__umount_mnt() resets ->overmount of the parent when it unmounts the
mount that overmounts it. mnt_change_mountpoint() doesn't. It moves the
mount to its new parent and leaves the old one pointing at it.
For a mount that is moved beneath in attach_recursive_mnt() that doesn't
matter. The new mount has already reset ->overmount of the old parent by
the time the old top mount is moved onto it.
It matters for reparent() though. propagate_umount() moves a surviving
overmount onto the first ancestor that isn't going to be unmounted. The
mount it was taken from is unmounted immediately afterwards. If a file
descriptor keeps that unmounted mount alive ->overmount points at the
moved mount. That's a dangling pointer and UAF as the moved mount is
unmounted and freed.
do_lock_mount() follows ->overmount from the target path under
mount_lock. With a file descriptor on such a mount as the target of a
mount beneath topmost_overmount() walks into the freed mount and
do_lock_mount() takes references on whatever it finds there.
So reset ->overmount of the old parent in mnt_change_mountpoint() the
same way __umount_mnt() does. A mount's ->overmount is then always a
mount that is attached to it.
Fixes: ffdc52fbbd ("prevent mount hash conflicts")
Cc: stable@vger.kernel.org # v6.17+
Link: https://patch.msgid.link/20260926-work-mount-fixes-2-v1-1-f357abf3d17b@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260813223610.2043560-5-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260813223610.2043560-4-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Add a selftest to verify that KVM intercepts x2APIC MSR accesses for L1
after APICv is inhibited while L2 is active. This is a regression test for
an AVIC bug where KVM would skip updating x2APIC MSR intercepts while L2
is active, thus giving L1 access to a wide swath of L0's x2APIC surface.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260710162052.2188574-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the
runtime eVMCS controls (pin, primary, secondary, etc.) are being updated.
If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and
then runs the same L2 with TPR virtualization disabled, KVM will fail to
refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR
virtualization is disabled. I.e. failure to refresh the bitmap lets L2 (or
L1 by proxy) read and write L0's TPR.
Fixes: 502d2bf5f2 ("KVM: nVMX: Implement Enlightened MSR Bitmap feature")
Cc: stable@vger.kernel.org
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Use the MSR permission bitmap of the active VMCB instead of assuming that
KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02
if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM
needs to merge msprm01 with msrpm12.
Don't bother tracking the virtual address of the bitmap that's being used,
as __va() is cheap on x86, and caching the virtual address would introduce
yet another source of potentially stale information.
Fixes: b2ac58f905 ("KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL")
Cc: stable@vger.kernel.org
Reported-by: Stefan Teodorescu <fane@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260826195833.844526-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Don't (re)read PERF_CNTR_GLOBAL_CTL from hardware on a failed VMRUN, as the
purpose of the read is to synchronize KVM's cache with any writes done by
the guest, and the guest can't possibly have modified the MSR if it never
got a chance to run.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260904170642.3291466-5-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Don't mark the ASID as dirty in the VMCB when requesting a TLB flush via
control.tlb_ctl. Per "15.15.3 VMCB Clean Field" of the July 2026, Revision
3.45 version of the APM:
The following are explicitly not cached and not represented by Clean bits:
* TLB_Control
Fixes: 7e8e6eed75 ("KVM: SVM: Move asid to vcpu_svm")
Suggested-by: Yosry Ahmed <yosry@kernel.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260904170642.3291466-4-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Leave control.erap_ctl and control.clean as-is in the VMCS if VMRUN fails,
because as per AMD:
there's no explicit architectural guarantee about the behavior in the
presence of VMRUN failures. So the best thing to do would be to assume
that if VMRUN fails, the actions requested in the control fields may not
have been performed.
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260904170642.3291466-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN,
as empirical testing shows that the CPU performs the requested TLB flush if
and only if VMRUN is successful, i.e. clearing TLB control on a failed
VMRUN effectively drops a TLB flush.
Explicitly track the need to flush all ASIDs on a per-CPU basis, as the
ASID reuse condition is tied to the pCPU, not to the vCPU. As a bonus,
this also obviates the need to avoid clobbering FLUSH_ALL_ASID with
TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid().
Deliberately don't bother saving/restoring the "old" tlb_ctl on failure,
in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from
after pre_svm_run(), but before updating tlb_ctl for flush_all_asids. If
VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next
successful run of the VMCB *may* unnecessarily flush all ASIDs, which
strictly speaking could result in noisy neighbor issues. However, the
fact that new_asid() is already guest-triggerable, because of KVM's flawed
behavior of clearing the ASID on emulated INIT, means that a guest can
already trigger a flush of all ASIDs at roughly the same rate. And once
KVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID
to each vCPU, this flaw goes away.
Fixes: 38e5e92fe8 ("KVM: SVM: Implement Flush-By-Asid feature")
Cc: stable@vger.kernel.org
Reported-by: Stefan Teodorescu <fane@google.com>
Suggested-by: Yosry Ahmed <yosry@kernel.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260904170642.3291466-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When walking shadow page tables, immediately terminate the walk if the root
is a "dummy" root, i.e. a root whose top-level page table is backed by the
zero page, but otherwise doesn't exist. If memslot creation races with a
stage-2 page fault (EPT violation or #NPF) from L2, then if the stars align,
KVM will attempt to walk shadow page tables using the zero page and hit a
NULL pointer deref.
BUG: kernel NULL pointer dereference, address: 0000000000000021
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP
CPU: 30 UID: 1000 PID: 941 Comm: qemu Not tainted 7.2.0-rc2-1b731e5ded48-next-vm #1741 PREEMPTLAZY
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:__kvm_mmu_invalidate_addr+0xea/0x210 [kvm]
Call Trace:
<TASK>
kvm_mmu_invalidate_addr+0x92/0xe0 [kvm]
__kvm_inject_emulated_page_fault+0x67/0x80 [kvm]
ept_page_fault+0x160/0x850 [kvm]
kvm_mmu_do_page_fault+0x102/0x1f0 [kvm]
kvm_mmu_page_fault+0x8e/0x6b0 [kvm]
vmx_handle_exit+0x163/0x640 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0x960/0x2120 [kvm]
kvm_vcpu_ioctl+0x2c7/0x970 [kvm]
__x64_sys_ioctl+0x90/0xd0
do_syscall_64+0x67/0x5f0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f606d0b53bb
Opportunistically harden the shadow walks against fully invalid roots, but
WARN, as all callers are expected/required to pre-check for a valid root.
Don't WARN in the dummy root case as the whole point of using a dummy root
is to provide a root that's valid enough to enter the guest, i.e. it should
Just Work for all flows except those that *need* to know about dummy roots.
Alternatively, KVM could allocate a dedicated page and associated shadow
page structure for the dummy root, which is very tempting as it such an
approach should be more resilient against unexpected behavior. But that
would be a much larger and thus riskier change than simply terminating
walks of dummy roots.
Fixes: 0e3223d8d0 ("KVM: x86/mmu: Use dummy root, backed by zero page, for !visible guest roots")
Reported-by: Gabriel Schneider <gbrls@osec.io>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260925234256.2384816-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now that KVM holds kvm->lock for the entirety of vCPU creation, from when
created_vcpus is incremented until the new vCPU is fully onlined, WARN if
the impossible happens and KVM somehow sees a discrepancy between the
number of vCPUs "created" and "onlined".
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Tested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Message-ID: <20260921174445.911676-8-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now that KVM uses kvm_get_vcpu_by_id() to check for an existing vCPU ID
before doing any meaningful work, which was made possible by holding
kvm->lock for the entirety of vCPU creation, revert the now-redundant
"early" vCPU ID tracking. The claims about the impact of kvm->vcpu_ids on
the memory footprint were a wee bit wrong: the worst case scenario isn't
256 bytes per VM, it's 256 "unsigned longs" per VM, i.e. 2048 bytes per VM.
Increasing the size of "struct kvm" by 2048 nearly doubled the total size
on many architectures, and tripped x86's KVM_SANITY_CHECK_VM_STRUCT_SIZE,
which was added to detect this *exact* scenario, where a single change
significantly increased the size of "struct kvm". I.e. attempting to build
KVM with CONFIG_DEBUG_KERNEL=n fails on x86 (the build failures got missed
because all build bots apparently test only CONFIG_DEBUG_KERNEL=y kernels,
and maintainers' test flows were similarly lacking).
This reverts commit 97d65b544f.
Fixes: 97d65b544f ("KVM: Check for duplicate vcpu_id as early as possible")
Reported-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Closes: https://lore.kernel.org/all/56a4bc35ee605588b7cc36c8e45c12b5f3b506cb.camel@guillain.net
Reported-by: Paweł S <spawel523@gmail.com>
Closes: https://lore.kernel.org/all/CABD%3DWFOS4j4hDv%2BpW-eEM9HAM2q2GY_iYdAG%2BqvYcUEinUrcQQ@mail.gmail.com
Tested-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Message-ID: <20260921174445.911676-7-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now that kvm->lock is held for the entirety of vCPU creation, check for a
conflicting vCPU ID at the begnning of vCPU creation, before the arch
precreate() hook is invoked. This will allow reverting commit 97d65b544f
("KVM: Check for duplicate vcpu_id as early as possible"). For now, keep
the redundant vcpu_ids tracking as a sanity check.
No functional change intended (absent KVM bugs, checking vcpu_ids and
walking kvm_get_vcpu_by_id() should yield the same result).
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Tested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Message-ID: <20260921174445.911676-6-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When creating a vCPU, don't drop kvm->lock to when doing the bulk of actual
vCPU creation, as allowing multiple vCPUs to be created in parallel adds
significant complexity in KVM (as evidenced by the many related bugs), and
all known VMMs fully serialize vCPU creation. Remove all manually locking
of kvm->lock from kvm_arch_vcpu_{post,}create() for obvious reasons.
For many years, "everyone" has assumed that dropping kvm->lock was done for
performance reasons optimization, e.g. to allow userspace to create all
vCPUs concurrently for latency purposes. But as above, no known VMM does
that. Looking at the history of this code, before commit 11ec280471
("KVM: Convert vm lock to a mutex"), kvm->lock was a spinlock. I.e. KVM
*had* to drop kvm->lock when doing the bulk of vCPU creation, otherwise KVM
couldn't do normal memory allocations. When kvm->lock got turned into a
mutex for unrelated reasons, no one took advantage updated of the change to
simplify vCPU creation. And 19 years later, everyone just assumed that KVM
continued to deal with the complexity for performance reasons.
Furthermore, naively parallelizing vCPU creation in userspace is likely a
net negative due to the overheads of task creation. Unless a VMM carefully
avoids the extra overhead related to parallelization, e.g. spawns each
vCPU's thread before creating the vCPU, creating vCPUs concurrently is a
net *negative* up until about ~64 vCPUs, after which the times are a wash.
The absolute speed of light _is_ faster if KVM doesn't hold kvm-lock, but
at vCPU counts of ~16 or less, it's probably in the noise when considering
total VM creation time, as the added latency is less than 1ms up until 16
or so vCPUs.
On top of all that, KVM has had a *lot* of fatal bugs (most often found by
syzkaller) related to vCPUs being created while trying to do per-VM
operations (basically, see every flow that locks all vCPUs). I.e. the
parallel vCPU creation "support" is actively harmful as the only "use case"
is for misbehaving userspace to exploit KVM bugs.
Serializing vCPU creation will allow reverting commit 97d65b544f ("KVM:
Check for duplicate vcpu_id as early as possible"), which had "minor" math
error: the worst case scenario isn't "256 bytes per VM", it's "256 unsigned
longs per VM", i.e. 2048 bytes per VM, which doubles the size of each VM
and pushes several architectures into order-1 allocations.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Tested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Message-ID: <20260921174445.911676-5-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Use kvm_is_vcpu_creation_in_progress() instead of an open-coded equivalent
during AIA initialization. Unlike similar vGIC code in arm64, the relevant
RISC-V code runs under kvm->lock, i.e. can use the standard API without
hitting lockdep false positive.
No functional change intended.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Tested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Message-ID: <20260921174445.911676-4-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Now that KVM's APIs for locking all vCPUs return -EBUSY if vCPU creation is
in-progress, drop the manual check for the same from vGIC creation, and
update the comments accordingly.
Note, while KVM arm64 guards many vGIC operations with its arch-specific
config_lock, holding kvm->lock is sufficient to guarantee a stable result
for "is vCPU creation in-progress". So, no functional change intended.
Note #2, the open coded check in vgic_init() is racy when called without
kvm->lock held, e.g. via vgic_lazy_init(). I.e. that check needs to stay
open coded to avoid triggering a lockdep assert. Whether or not the race
is "fine" is a problem for a different day.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Tested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Message-ID: <20260921174445.911676-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reject locking of all vCPUs if vCPU creation is in-progress, i.e. if the
number of "created" vCPUs doesn't match the number of "onlined" vCPUs.
It's simply not possible to guarantee that KVM has truly locked all vCPUs
if one or more vCPUs are actively being created. Holding kvm->lock does
prevent in-flight vCPUs from being fully onlined, but it's infeasible for
common KVM to know whether or not that provides sufficient protection.
In practice, this is likely a minor bug fix for the ARM and RISC-V usage of
kvm_trylock_all_vcpus(), and a glorified nop for everything else. E.g.
ARM's kvm_timer_vcpu_init() can race kvm_vm_ioctl_set_counter_offset() with
respect to observing KVM_ARCH_FLAG_VM_COUNTER_OFFSET.
Opportunistically drop x86's existing manual checks on vCPU creation being
in-progress as all of x86's checks immediately precede or follow locking of
all vCPUs. Leave arm64 and RISC-V alone for the moment, as their checks
aren't as obviously redundant/equivalent.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Tested-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Tested-by: Naveen N Rao (AMD) <naveen@kernel.org>
Message-ID: <20260921174445.911676-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- Fix a brown paper bag bug where KVM would incorrectly treat Intel PMU MSRs
as valid on AMD.
- Fix a regression in the hardware disable selftest where it checked the wrong
macro when detecting glibc support (breaks at least musl).
- Never clear KVM_REQ_VM_DEAD so that dead VMs stay dead, which is especially
important for KVM_BUG_ON() flows, which often guard more dangerous bugs.
- Re-pend GET_NESTED_STATE_PAGES if getting the pages fails, to fix a bug
where KVM would let userspace run a broken setup with stale vmcs12 pages.
- Fix a class of bugs where KVM would fail to fill kvm_run exit fields if
getting nested pages failed.
- Treat reserved entries in the memory attributes xarray as "no attributes",
to fix false positives when checking for mixed attributes.
- Fix memcg accounting for the memory attributes xarray (the xarray library
subtly requires the xarray to be configured for accounting upfront; the gfp
flags taken at runtime are used only rarely).
- Don't pre-reserve xarray entries when storing empty attributes, as storing
NULL must not require memory allocation (KVM and other subsystems heavily
rely on this behavior).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmq3A78ACgkQOlYIJqCj
N/1uVA//TVDznH49htPNV4dh7vfiE8oF9ka4e9KTPA2eMdDeNVInNXBz0ZbJCdNN
Hm7iZZfk8yx0JCCGXdp8EoYg66iwulBr0KZXRP2U2LoyiRELA1VtGGOLUVP3PXjF
hElXD56+RrkJJSucINlFU7kSfl2hY/Jbaq87HVBLpXp8iY3stBbLdgMT1ReLdorO
s9i2uJRqHKjtSG330qDYEG1TtRAdUehgRbxbbJVuOEYtU37tCvX6ai8dEjZAvxYo
1VZOD05ITo12HUXPiZjIMoNTujQnZKmGYlBYczWlfOmkY/tN6SV8M41srV3ZcK0k
XGOQM6tOzbVTWaSH/pW1krklnOFAbnL6QzHzb3enHZfUN8AikHPDyfsJWzt/s0f/
ATTQk03OYL4fJMQSQ778EI6S4PcOzY9HiBxDXM5ySpUv1uyXw8ZFsQSdH/TYTMhi
Dce42r5rlGa1vAKHwI1Xya2su3REhWzxYxGpUOg/PtRRqWvL2RMrHArzEd6zu+Ti
jPinuQuXYcT1FTCa5S39NWhU4gWpjw8Pvs9VuUYSCDYxZCaqQ2YheYgsAcgPqgfE
hS43XVmmOB/tXGsvu+/YuEfbzNV/mHOuJBcjBnnsBP3d6EFB02FPKg4/LYiXujYo
OocUbSB7bKd87W3B+Ys3QmgOtZh4qX/aLYusa2vQ4Dp9ujXqcWs=
=LG0B
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-fixes-7.3-rc5' of https://github.com/kvm-x86/linux into HEAD
KVM fixes for 7.3-rcN
- Fix a brown paper bag bug where KVM would incorrectly treat Intel PMU MSRs
as valid on AMD.
- Fix a regression in the hardware disable selftest where it checked the wrong
macro when detecting glibc support (breaks at least musl).
- Never clear KVM_REQ_VM_DEAD so that dead VMs stay dead, which is especially
important for KVM_BUG_ON() flows, which often guard more dangerous bugs.
- Re-pend GET_NESTED_STATE_PAGES if getting the pages fails, to fix a bug
where KVM would let userspace run a broken setup with stale vmcs12 pages.
- Fix a class of bugs where KVM would fail to fill kvm_run exit fields if
getting nested pages failed.
- Treat reserved entries in the memory attributes xarray as "no attributes",
to fix false positives when checking for mixed attributes.
- Fix memcg accounting for the memory attributes xarray (the xarray library
subtly requires the xarray to be configured for accounting upfront; the gfp
flags taken at runtime are used only rarely).
- Don't pre-reserve xarray entries when storing empty attributes, as storing
NULL must not require memory allocation (KVM and other subsystems heavily
rely on this behavior).
Manually perform cache maintenance on the source VM during intra-host
migration to ensure no stale data is left in CPU caches after the VM is
destroyed. Because the source VM is "converted" to a non-SEV VM, KVM's
memory reclaim flows won't trigger cache maintenance, e.g. when all guest
memory is reclaimed in response to detaching from the mmu_notifier.
Note, relying on the destination VM to do cache maintenance isn't an option
as KVM doesn't require identical guest memory configurations, i.e. the
source VM may have access to memory that the destination VM does not.
Enforcing equivalent memory configurations is infeasible, as it would
require a *deep* comparison of memslots, e.g. to verify that not only are
the memslot identical, but what the memslots point at is also identical.
Fixes: b56639318b ("KVM: SEV: Add support for SEV intra host migration")
Cc: stable@vger.kernel.org
Reported-by: Stefan Teodorescu <fane@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260923163721.1584779-3-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Unconditionally free SEV's "have run CPUs" cpumask in the VM destroy path,
i.e. even for what appear to be non-SEV VMs, as an SEV VM becomes a non-SEV
VM if its state is intra-host migrated. Alternatively, the mask could be
freed in sev_migrate_from() when "converting" the source VM, but that gets
annoying because ideally KVM would nullify the mask to guard against UAF,
and nullifying the mask would need be conditioned on CPUMASK_OFFSTACK=y.
Freeing the mask during sev_migrate_from() is also not robust against other
KVM bugs, though that's kind of a moot point since any such bugs would show
up even if sev->active is never set. I.e. KVM must get that side of things
correct. But, that's not a great reason to add more code just to make
things marginally less robust.
Fixes: 6f38f8c574 ("KVM: SVM: Flush cache only on CPUs running SEV guest")
Cc: stable@vger.kernel.org
Reported-by: Stefan Teodorescu <fane@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20260923163721.1584779-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
qedi_get_protocol_tlv_data() can be called asynchronously by QED after
qedi_ops->register_ops(). It takes stats_lock and reads ll2_mtu, but
__qedi_probe() currently registers the callback before initializing the
mutex and assigning the default MTU on the normal probe path.
Initialize the callback-visible state before registering qedi_cb_ops. Keep
the recovery path from reinitializing state because it reuses the existing
qedi context.
Fixes: 3cc5746e5a ("scsi: qedi: Initialize the stats mutex lock")
Cc: stable@vger.kernel.org
Assisted-by: LLM Codex
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Link: https://patch.msgid.link/20260910092405.1300129-1-runyu.xiao@seu.edu.cn
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
Clock gating becomes possible as soon as ufshcd_init_clk_gating() has run,
and from that point on the probe keeps accessing host registers without
ever taking a clock reference. This has been safe only because of the state
check in __ufshcd_release(): gate_work is not queued unless
hba->ufshcd_state is UFSHCD_STATE_OPERATIONAL, and the promotion to that
state used to happen after the last register access of the probe, at the
end of ufshcd_probe_hba().
That is fragile: it only works while the promotion happens after the
register accesses. Commit a390e6677f ("scsi: ufs: core: Expand the
ufshcd_device_init(hba, true) call") changed that ordering by moving the
promotion into ufshcd_init(), which schedules ufshcd_async_scan()
afterwards. ufshcd_probe_hba() therefore now runs with the state already
promoted, and it accesses host registers without holding a clock reference:
- On hosts with UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH it calls
ufshcd_hba_stop() and ufshcd_hba_enable() before ufshcd_device_init()
sets the state back to UFSHCD_STATE_RESET, and both read
REG_CONTROLLER_ENABLE, so gated clocks stall there instead of just
losing a write.
- It ends with an ufshcd_configure_auto_hibern8() write, which its other
callers do take a clock reference for.
Take a clock reference as soon as clock gating has been initialised and
keep it until the probe is over. It then does not matter who drops a clock
reference while the probe is running, and the register accesses of the
probe no longer depend on hba->ufshcd_state. The reference is dropped by
ufshcd_async_scan() once the scan has finished, or by the new out_release
label if the probe fails after it was taken.
Fixes: a390e6677f ("scsi: ufs: core: Expand the ufshcd_device_init(hba, true) call")
Signed-off-by: Naomi Chu <naomi.chu@mediatek.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Link: https://patch.msgid.link/20260909091045.1134956-1-naomi.chu@mediatek.com
Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
In both altr_edac_a10_device_add() and altr_portb_setup(), the error path
freed the dci structure before releasing the devres group. Since the managed
single and double bit IRQ handlers use altdev(dci->pvt_info) as their data, an
IRQ firing between freeing dci and unregistering the IRQs could dereference
the freed memory.
Release the devres group first so the managed IRQs are unregistered
before the dci structure is freed.
Fixes: 911049845d ("EDAC, altera: Add Arria10 SD-MMC EDAC support")
Fixes: 588cb03ea2 ("EDAC, altera: Add Arria10 L2 Cache ECC handling")
Closes: https://sashiko.dev/#/patchset/20260719211238.589402-1-rosenp%40gmail.com
Assisted-by: LLM
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org ## 6.18+
Link: https://patch.msgid.link/20260911120627.2634225-5-dinguyen@kernel.org
Sashiko reports:
"Does suppressing sysfs unbinding fully prevent the execution of freed __init
memory? If altr_sysmgr_regmap_lookup_by_phandle() returns -EPROBE_DEFER, the
probe is deferred until after __init memory is freed."
The a10 EDAC .setup callbacks (sdmmc, ethernet, nand, dma, usb, qspi) and
their helpers (altr_init_a10_ecc_device_type, altr_init_a10_ecc_block) were
marked __init. These run from the probe path, which may execute after init
memory is freed -- e.g. a probe deferred via -EPROBE_DEFER that only succeeds
once a late/module dependency appears, or a manual unbind/rebind. Calling
__init code then dereferences freed memory. Remove __init so these functions
remain valid at runtime.
Fixes: 788586efd1 ("EDAC/altera: Initialize peripheral FIFOs in probe()")
Assisted-by: LLM
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org # 6.18+
Link: https://patch.msgid.link/20260911120627.2634225-3-dinguyen@kernel.org
The driver must remain bound; unbinding and re-binding it would erase active
system memory.
Remove the .remove functions because they will not ever get used.
Fixes: 588cb03ea2 ("EDAC, altera: Add Arria10 L2 Cache ECC handling")
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org # 6.18+
Link: https://patch.msgid.link/20260911120627.2634225-2-dinguyen@kernel.org
modify_prefix_route() is given the lifetime in clock_t relative to now,
but fib6_set_expires() wants an absolute jiffies value. So when a
permanent address is changed to a finite valid_lft, the prefix route
ends up already expired and GC removes it.
Steps to reproduce:
ip link add dummy9 type dummy
ip link set dummy9 up
ip -6 addr add 2001:db8:9::1/64 dev dummy9
ip -6 addr change 2001:db8:9::1/64 dev dummy9 valid_lft 3600 preferred_lft 3600
ip -6 route show dev dummy9 # expires is negative
Fixes: 8308f3ff17 ("net/ipv6: Add support for specifying metric of connected routes")
Signed-off-by: Qishuai Liu <lqs@lqs.me>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260923132048.3272878-1-lqs@lqs.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Since the page_pool conversion every RX buffer is a whole page and the
skb truesize is the page, although the hardware writes at most 2 KiB of
it. On 64 KiB pages a packet therefore counts 65792 bytes against the
socket buffer where it used to count 2752. As a result a UDP socket
with the default buffer starts to drop after three packets, and the RX
rings pin 16 MiB for 512 KiB of buffers.
Fix this and allocate the buffers as page fragments, so the truesize is
what a packet occupies. 4 KiB pages stay one buffer per page.
Sync each buffer in the refill path, as page_pool can only sync a whole
page on recycle. On 4 KiB pages that is twice what the hardware wrote.
Fixes: 7bc054c2d4 ("net: bcmgenet: convert RX path to page_pool")
Reported-by: Karl Mehltretter <kmehltretter@gmail.com>
Closes: https://lore.kernel.org/all/20260924065839.56793-1-kmehltretter@gmail.com/
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260924101922.2675127-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Two racing tc filter add requests on the same chain/prio of an
unlocked classifier both run change() on the shared proto and both
can fail: the winner's tcf_chain_tp_delete_empty() attempt gives up
because the loser's handle is still in the idr, and the loser's
error path drops only its own reference without a second reclamation
attempt. The empty proto stays linked in the chain, holding the
chain reference, a block reference and the classifier module
reference until the chain or block is torn down.
Reclaim the proto on the error path of any failed request that holds
a proto reference. The reclamation is emptiness-gated:
tcf_chain_tp_delete_empty() unlinks the proto only when
delete_empty() admits it is empty, so a live shared proto is never
unlinked. A proto the request created is reclaimed unconditionally -
it is the only owner, so marking it for deletion is safe even without
a delete_empty callback. Classifiers without one (the check marks the
proto unconditionally) are rtnl-serialized, so the raced window this
guard closes cannot arise for them.
This is a follow-up to commit d4e359b360 ("net/sched: cls_api: fix
teardown of an adopted proto on insert-race loss"), which stopped the
loser of the insert race from unlinking the winner's live proto but
left the empty-proto residual in place.
Conditions to recreate:
- CONFIG_NET_CLS_FLOWER=y; veth pair
- tc qdisc add dev veth0 ingress
- two concurrent `tc filter add dev veth0 ingress protocol ip pref 1
flower skip_sw ... action drop` (both fail in fl_hw_replace_filter
after publishing their handle in the idr); repeat in a loop
- an empty flower tp stays linked after both requests fail; visible
as a bare `filter protocol ip pref 1 flower chain 0` header in
`tc filter show` with no filter entries
- CAP_NET_ADMIN (namespace-local via unshare -Urn suffices)
Fixes: 8b64678e0a ("net: sched: refactor tp insert/delete for concurrent execution")
Reported-by: Sashiko (nipa) <sashiko-bot@kernel.org>
Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260805134049.927864-1-victor@mojatatu.com
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/QDISC-JCOT.v1.20260910090924@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mctp_add_dev() links the new mctp_dev into dev->mctp_ptr before mdev->dev
is assigned, so a reader that picks the device up in that window
dereferences a net_device pointer that is still NULL:
KASAN: null-ptr-deref in range [0x00000000000000b0-0x00000000000000b7]
Call Trace:
<TASK>
? __pfx_mctp_sendmsg (./include/linux/sockptr.h:49)
? __pfx_mctp_dst_output (net/mctp/route.c:41)
? selinux_socket_sendmsg (security/selinux/hooks.c:5278)
____sys_sendmsg (net/socket.c:775 (discriminator 1) net/socket.c:790
(discriminator 1) net/socket.c:2684 (discriminator 1))
? __pfx_____sys_sendmsg (net/socket.c:1131)
? __pfx_copy_msghdr_from_user (net/socket.c:2590)
? update_cfs_rq_load_avg (kernel/sched/fair.c:5478)
___sys_sendmsg (net/socket.c:2738)
? __pfx____sys_sendmsg (net/socket.c:2625)
? perf_event_task_tick (./include/linux/rcupdate.h:838)
? sched_tick (kernel/sched/core.c:5818)
? clockevents_program_event (kernel/time/clockevents.c:372)
? fdget (./include/linux/rcupdate.h:873 fs/file.c:1100)
__sys_sendmsg (net/socket.c:2770)
? __pfx___sys_sendmsg (net/socket.c:2751)
do_syscall_64 (arch/x86/entry/syscall_64.c:63)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
</TASK>
Fix by publishing only once the object is fully initialised:
__mctp_dev_get() runs under rcu_read_lock() only and hands
this object to readers as soon as mctp_ptr is assigned, so
they must never observe mdev->dev == NULL.
Fixes: 583be982d9 ("mctp: Add device handling and netlink interface")
Signed-off-by: Binbin Deng <18983559317@163.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/729830b8.130.1a0c945579d.Coremail.18983559317@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
client:
- fix restore of partially initialized client
i915:
- Fix incorrect RCU teardown order leading to endless loop
- Fix DP MST TU and FEC handling for disconnected streams
- Fix selective fetch disable, again
- Fix export namespace for kunit helpers
- Workaround eDP flicker on a specific laptop model
xe:
- CRI throttle reasons report
- TLB invalidation at wedge
- SVM eviction and VM close
- Display corruption on LNL on Xen PV
- W/a fix and addition
amdgpu:
- Display ref count fix
- Userq fixes
- VCN 4, 5 reset fixes
- Fixes for various error paths
- Stack frame size fixes for various combinations of compilers and configs
amdkfd:
- Possible UAF fix
nouveau:
- runtime suspend/resume fixes for newer firmware
- rcu free the scheduler
- fix VRAM pinning
- fix double free
- fix reference leaks
- fix runtime PM leak
- fix cursor list usage problems
- fix HDMI config rejection without SCDC
virtio:
- fix a bunch of object/memory leaks in failure paths
- add pixel blend mode property to cursor plane
- revert prime buffers import
- sync shmem backing on guest transfers
imagination:
- propogate map failures properly
- fix page count in map interface
- clamp freelist reconstruction requests
ivpu:
- use separate flag for job timeout
bridge:
- samsung-dsim: fix TE GPIO lifetime for host attach
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmq29FYACgkQDHTzWXnE
hr4pnw/+JhcAdts2saCNt/j7EtD6DqXJvyfo4BVyjYCSVP3YEZuZCrpBJh02UUUo
sU8MgjmzwXHRxflTk8DLQMMKhN7cvFmzdREro5x7gJkCi2m/x3eanafQJS0iyvqN
rl+K+rVeEmrOELN7auNFSl3kBtvR9yvbPZtBKNNe1IhCSq/iWKm5I4HLwP85diJZ
OHOPuXXh+QFhtXsbwH3p1NsbWb/Kiovbevqitd/X/9CFZRMiiwuy5QFX8xOAW4CR
0id0njQPWVbLupuqZRGSDMAsqiVq/ClKIb8X0uMzU92y6l8oMsamPXxbs7Z6pfsT
d8k9+zMP0LXXkwdS/sTI/9axJ5LZmd4mqEL+iAkoKkO2EGnDerzyklOCWtk38qvc
qpjhQDW77AGLoQbISKZzI2Ce9B3RotdDghyd0Bt++GJegKQAAvevEQKNzWVvlMd3
aQcpI/EKf1PXJnX44LtDqNmoEmmEy4fKOICu52GzpPYOGaSQL25tuA7/KGNX35D8
hY7KiJRYaPcU0hAwAPLvQDHUvFBhDJD4BHGO01YOZ0fZzBARwE57Hwp3hxkHez64
CbcVZ5bzTREmZ3KHKI79OMhKUfCbq+E6YoJ1jxSDs902LWTrULx/iMCA+7NTZL1U
f/9nIe2fkA0/D+++CraKd+HYkfdxvZZwuRuZtp5jWqRLxB4bdes=
=oRa2
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2026-09-26' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"While most of this is AI inspired fixes for error handling paths,
leaks and use after frees, there are some normal things.
nouveau has probably the biggest changes with some fixes to stabilise
runtime suspend/resume on 570 firmware which regressed after we moved
from 535, there are some fixes to stackframe issues seen with amdgpu,
and otherwise the usual bunch of i915/xe/amdgpu fixes, and some
virtio-gpu fixes.
Hopefully it will start to quiten down a bit from here.
client:
- fix restore of partially initialized client
i915:
- Fix incorrect RCU teardown order leading to endless loop
- Fix DP MST TU and FEC handling for disconnected streams
- Fix selective fetch disable, again
- Fix export namespace for kunit helpers
- Workaround eDP flicker on a specific laptop model
xe:
- CRI throttle reasons report
- TLB invalidation at wedge
- SVM eviction and VM close
- Display corruption on LNL on Xen PV
- W/a fix and addition
amdgpu:
- Display ref count fix
- Userq fixes
- VCN 4, 5 reset fixes
- Fixes for various error paths
- Stack frame size fixes for various combinations of compilers and
configs
amdkfd:
- Possible UAF fix
nouveau:
- runtime suspend/resume fixes for newer firmware
- rcu free the scheduler
- fix VRAM pinning
- fix double free
- fix reference leaks
- fix runtime PM leak
- fix cursor list usage problems
- fix HDMI config rejection without SCDC
virtio:
- fix a bunch of object/memory leaks in failure paths
- add pixel blend mode property to cursor plane
- revert prime buffers import
- sync shmem backing on guest transfers
imagination:
- propogate map failures properly
- fix page count in map interface
- clamp freelist reconstruction requests
ivpu:
- use separate flag for job timeout
bridge:
- samsung-dsim: fix TE GPIO lifetime for host attach"
* tag 'drm-fixes-2026-09-26' of https://gitlab.freedesktop.org/drm/kernel: (60 commits)
drm/amd/display: Bump frame warning limit for all builds of dml
drm/imagination: clamp freelist reconstruction requests
drm/imagination: Fix page count for page table for map() interface
drm/imagination: Propagate map failures correctly from pvr_mmu_map_sgl()
drm/amd/display: Bump frame warning limit for clang builds of dml
drm/amd/display: Relax DML frame limit with UBSAN
drm/amdgpu: Fix runtime PM leak in amdgpu_debugfs_test_ib_show()
drm/amdgpu: Fix last_update fence leak in amdgpu_vm_init()
drm/amdgpu: Fix acpi device leak in amdgpu_acpi_enumerate_xcc()
drm/amdgpu: Fix vmid_wait fence leak in amdgpu_ring_init()
drm/amdkfd: fix use-after-free and multi-container gap in kfd_dev_mapping
drm/amdgpu/vcn4.0.3: fix video_timeout unit mismatch in jpeg reset wait
drm/amdgpu/vcn5.0.1: fix video_timeout unit mismatch in jpeg reset wait
drm/amdgpu/userq: fix double jiffies conversion in hang detect timeout
drm/amdgpu: move userq fence wait out of signalling section
drm/amd/display: Fix dc stream excess put in dm_update_crtc_state()
drm/xe: Add wa_14025941587 to xe2, xe3 and xe3p platforms
drm/xe: harden adjust_idledly() against divide-by-zero and overflow
drm/xe: Limit sg segment size to PAGE_SIZE on Xen PV
drm/i915: fix incorrect RCU teardown order
...
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQzmBmZPBN6m/hUJmnyomI6a/yO7QUCarbccwAKCRDyomI6a/yO
7YKCAQDsDhTU3Rq7HCUgCkGYpZnsTAqXo3JeDP66Ku6Y0bOJjAEAhyRelXr+tKFW
aYpuOn3qF+tihTJ52RWzAhQzEQ1BRQY=
=QEqL
-----END PGP SIGNATURE-----
Merge tag 'ipe-pr-20260925' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe
Pull IPE fixes from Fan Wu:
"Two fixes for use-after-free issues found by recent LLM-assisted code
analysis.
- move successful policy load auditing under the new policy
directory's inode lock, preventing a concurrent policy deletion
from freeing the policy while it is still being audited
- protect the dm-verity root hash with RCU, preventing policy
evaluation from racing with root hash replacement during preresume"
* tag 'ipe-pr-20260925' of git://git.kernel.org/pub/scm/linux/kernel/git/wufan/ipe:
ipe: protect the dm-verity root hash with RCU
ipe: fix use-after-free when auditing a newly loaded policy
Mostly small driver fixes. The biggest fix is the one to the block zone
handling which might trip for real or virtual hardware if the number of
zones is > 2^32.
Signed-off-by: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
-----BEGIN PGP SIGNATURE-----
iLgEABMIAGAWIQTnYEDbdso9F2cI+arnQslM7pishQUCarblBBsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDImHGphbWVzLmJvdHRvbWxleUBoYW5zZW5wYXJ0bmVy
c2hpcC5jb20ACgkQ50LJTO6YrIXG4wEA0mYHxKLKHGzKMTZhLIQc9LqJ+oAFQfwk
sUfhX5kqt+QA+QGx/jrg6DKgC6LLeti8xRD+hkeSCwSPCt98Tg2/ba/O
=pQUi
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Mostly small driver fixes. The biggest fix is the one to the block
zone handling which might trip for real or virtual hardware if the
number of zones is > 2^32"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: megaraid_sas: Protect megasas_get_ctrl_info() in megasas_resume()
scsi: sd_zbc: Reject disks with too many zones
scsi: block: Fix zones_cond out-of-bounds write on zone report
scsi: leapraid: Avoid -Wformat-security warning
scsi: devinfo: Add BLIST_SKIP_IO_HINTS for EMC Symmetrix
scsi: libiscsi_tcp: Check the data direction of a Data-In PDU
scsi: ufs: pltfrm: Add quirk for R-Car S4 lacking lanes-per-direction
scsi: ufs: core: Keep internal commands dispatchable during error handling
ipe_bdev_setintegrity() frees the old root hash when dm-verity publishes
a new one on ->preresume, while policy evaluation can still be
dereferencing it.
Protect the root hash with RCU. The evaluation path already runs under
rcu_read_lock().
Fixes: e155858dd9 ("ipe: add support for dm-verity as a trust provider")
Cc: stable@vger.kernel.org
Assisted-by: LLM
[FW: remove model name according to latest guideline]
Signed-off-by: Fan Wu <wufan@kernel.org>
new_policy() audits the policy after ipe_new_policyfs_node() publishes it
and drops the new directory's inode lock. A concurrent delete can free
the policy while ipe_audit_policy_load() is still using it.
Audit the successful load under that lock.
Fixes: f44554b506 ("audit,ipe: add IPE auditing support")
Cc: stable@vger.kernel.org
Assisted-by: LLM
[FW: remove model name according to latest guideline]
Signed-off-by: Fan Wu <wufan@kernel.org>
- Fix leaked server handles and dropped errors in the SMB2 compound
create path: a parsing error reported as success, an earlier CREATE
left open when a later command fails, the cached directory open
losing the FID needed for cleanup, and SMB2_open() not closing the
handle after a create-context parse failure
- Fix out-of-bounds reads when parsing create contexts from a
malicious server: bound each context by its Next field, parse the
lease and QFid contexts from their declared offsets and validate
the POSIX create context length
- Fix a double credit decrement, and its warning, when a compound
send fails and triggers a reconnect; found by syzbot
- Fix a dentry and server handle leak in cifs_atomic_open() when an
O_CREAT open resolves to a symlink or other non-regular inode
- Use GFP_KERNEL in the DFS get_targets() path
- Minor update to the POSIX extension specification references
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQTcqRusfSdYROJQwGkpVtNKoQNdYwUCarbTMwAKCRApVtNKoQNd
Y4KIAQC58KxOQ51ppRaqMGyL/Rk6duW254zritcmacI49ekHSgD9FZfkYe/MpLFH
eKnZ4mxjXkH7EcHmkDC2rfh5cj+edgg=
=HCa6
-----END PGP SIGNATURE-----
Merge tag 'cifs-fixes-7.3-rc5' of https://git.manguebit.org/linux
Pull smb client fixes from Paulo Alcantara:
- Fix leaked server handles and dropped errors in the SMB2 compound
create path: a parsing error reported as success, an earlier CREATE
left open when a later command fails, the cached directory open
losing the FID needed for cleanup, and SMB2_open() not closing the
handle after a create-context parse failure
- Fix out-of-bounds reads when parsing create contexts from a
malicious server: bound each context by its Next field, parse the
lease and QFid contexts from their declared offsets and validate
the POSIX create context length
- Fix a double credit decrement, and its warning, when a compound
send fails and triggers a reconnect; found by syzbot
- Fix a dentry and server handle leak in cifs_atomic_open() when an
O_CREAT open resolves to a symlink or other non-regular inode
- Use GFP_KERNEL in the DFS get_targets() path
- Minor update to the POSIX extension specification references
* tag 'cifs-fixes-7.3-rc5' of https://git.manguebit.org/linux:
smb: client: use finish_no_open() for non-regular inodes
smb: client: use GFP_KERNEL in get_targets()
smb: client: update POSIX extension specification references
smb: client: preserve create-context parsing errors
smb: client: close completed creates on compound wait errors
smb: client: clean up failed cached directory opens
smb: client: close handle after create-context parsing failure
smb: client: validate POSIX create context length
smb: client: fix create context out-of-bounds reads
smb: client: delete compound mids on send failure before unlock
kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit
tree is pruned. It drops entry->rule.exe before removing the rule from
the RCU-visible filter lists.
After a rule has been installed with AUDIT_ADD_RULE, which requires
CAP_AUDIT_CONTROL, removing the watched directory can race with another
task that is still evaluating the rule. In that case, fsnotify can free
the executable mark before the reader reaches audit_mark_compare(),
causing a use-after-free.
KASAN reports:
BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0
Unlink the published rules from the RCU-visible lists and retain them
on tree->rules for cleanup. If any rule has an executable mark, wait for
a single RCU grace period before removing the marks and scheduling the
entries for freeing. Otherwise, call_rcu() already provides the required
deferred freeing without a synchronous wait.
Cc: stable@vger.kernel.org
Fixes: 34d99af52a ("audit: implement audit by executable")
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Reviewed-by: Ricardo Robaina <rrobaina@redhat.com>
Tested-by: Ricardo Robaina <rrobaina@redhat.com>
Reviewed-by: Bradley Morgan <brads@mainlining.org>
Signed-off-by: Paul Moore <paul@paul-moore.com>
avc_policy_seqno() reads latest_notif without holding notif_lock, while
avc_latest_notif_update() can update it under that lock. KCSAN reports
these concurrent accesses during policy boolean updates and permission
checks.
Use READ_ONCE() for the lockless read and WRITE_ONCE() for the update.
The spinlock continues to serialize the comparison and update against
other writers. Reads made while holding notif_lock cannot race with a
writer and can remain plain accesses.
This marks both sides of the intentional concurrent access and constrains
compiler transformations, without suppressing checking with data_race().
Cc: stable@vger.kernel.org
Fixes: 788e7dd4c2 ("SELinux: Improve read/write performance")
Reported-by: syzbot+a7f7cb0737bd91aa698c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=a7f7cb0737bd91aa698c
Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Please consider pulling these changes from the signed vfs-7.3-rc5.fixes tag.
Thanks!
Christian
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRAhzRXHqcMeLMyaSiRxhvAZXjcogUCarab9AAKCRCRxhvAZXjc
osTRAP90MigSgX2U/USBn8zgSTs9Key89pWuwpctsvELYKUSzwEA12UDBswbtgmq
EGT6S2HSa6bifJMXG6AB+nMCcSluuAs=
=KEgE
-----END PGP SIGNATURE-----
Merge tag 'vfs-7.3-rc5.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
- Revert "put_mnt_ns(): leave mounts connected". This allows the
creation of reference count cycles in a very trivial way. We can't
bring this in until we have fixed the underlying cause
- vfs: Don't create the private nullfs instance for kthreads under
namespace_sem to avoid false lockdeps complaints
- binfmt_misc:
- Copy the name into a stack buffer and look up the copy in
bpf_binprm_select_interp()
- bpf_binprm_set_interp() and bpf_binprm_set_interp_arg(): Check
the private copy instead so the string that gets staged is the
kstring that was checked
- netfs:
- Make netfs_read_gaps() use separate sink folios rather than one
reused sink folio to discard unwanted data so that cifs checksum
checking sees all the data that was fetched
- Trim reads down to i_size so afs symlinks read correctly from the
cache
- Wrap the direct mempool ->alloc() calls the GFP_KERNEL paths make
in alloc_hooks() via a new mempool_alloc_noreserve() helper
- iov_iter: Use iov_iter_alignment() for the start and length check
added to iov_iter_extract_bvecs() this cycle. It used iter_iov_addr()
and iter_iov_len() which are only valid for ITER_UBUF and ITER_IOVEC
iterators
- super: Make iterate_supers_type() deletion-safe
- inode: Stop evict_inodes() from rescanning the same inodes
- writeback: Bound the cleanup_offline_cgwb() rescans
- ntfs3: Use d_instantiate_new() in ntfs_create_inode()
- ovl: Fix a use-after-free in the ovl_do_mkdir() debug print
- dcache: Unpoison the inline name buffer in __d_alloc() for KMSAN
- autofs: Fix a pipe file reference leak in autofs_kill_sb()
- bpf: Drop the path_unlink and path_rmdir hooks from the list of hooks
for which the verifier rewrites bpf_{set,remove}_dentry_xattr() to
the _locked variants
- squashfs: Range check the xz dictionary size before shifting by it
- selftests: Add the missing eventfd, open_tree_ns, openat2 and xattr
filesystems selftests to TARGETS and drop the stale openat2 entry
left behind when those tests moved
* tag 'vfs-7.3-rc5.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
netfs: Fix missing alloc tagging of direct mempool allocations
bpf: fs/xattr: don't assume the inode is locked in path_unlink/path_rmdir
autofs: fix sbi->pipe file reference leak in autofs_kill_sb()
dcache: unpoison the inline name buffer in __d_alloc()
ovl: fix UAF in ovl_do_mkdir() debug print
super: make iterate_supers_type() deletion-safe
Revert "put_mnt_ns(): leave mounts connected"
Revert "selftests/filesystems: add mntns cleanup test"
binfmt_misc: fix racy checks in bpf set_interp kfuncs
binfmt_misc: fix OOB read in bpf_binprm_select_interp()
fs: don't create the private nullfs mount under namespace_sem
writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes
fs: avoid repeated scans in evict_inodes()
netfs, afs: Fix symlink reading
netfs: Fix netfs_read_gaps() to use separate sink folios
squashfs: Add dictionary size range check to prevent shift-out-of-bounds
fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga
selftests/filesystems: fix missing and stale TARGETS entries
block: Fix start and length check added to iov_iter_extract_bvecs()
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEq1nRK9aeMoq1VSgcnJ2qBz9kQNkFAmq2Qs8ACgkQnJ2qBz9k
QNnBEAf5AXGzuQPeOHZQ0+kXhe0y+2Epj1oqSH0YIDI2263nav9go3wjz4uyL/J2
0bbALzEX0Em0n0OfYOSKPdOx22AFZdZVKrFiACXeaUQmK1R0zwLOJPxDvpyWhHQS
8Rn+HxMVxdqbobIClHQvGsU3EkBZR+d2ZSDfG4A3Gqc4O2vkgB3CvDvw5d7OdDNB
5Et2tydekYTSUH2JZvJxlzwvbfsvvgSEEVupYILYZvMOv01EMxOTLCCv/8KWOFNE
Xjen/maE+1ks+nGmTgDQC2bOALB3nCQhoMlL31nsYzP89Dg/C0IGCbVX25yUvlzX
0FXMPKVVEEvpZVhTc5Hy7HYhDatC5Q==
=IeuV
-----END PGP SIGNATURE-----
Merge tag 'fs_for_v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull isofs fix from Jan Kara:
"A fix for reading tightly packed isofs directories"
* tag 'fs_for_v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
isofs: Fix handling of directories with tight blocks
bpf_ma_set_dtor() duplicates map->record so that the bpf_mem_alloc
destructor can release the special fields of hash and rhash map elements
once the allocator frees them for good. btf_record_dup() only acquires
references on kernel and module BTF. Fields whose types live in the map
BTF keep pointing into it: a kptr to a local type refers to map->btf,
and a list_head or rb_root field carries a value_rec owned by the struct
meta table of map->btf.
That borrowed state can outlive the map. When RCU callbacks are still in
flight, bpf_mem_alloc_destroy() copies the allocator and defers the final
drain, together with the destructor context, to a workqueue.
bpf_map_free() then frees map->record and drops the map's BTF reference
as soon as map_free() returns. Once the program that loaded the BTF is
gone as well, the BTF is freed while the worker still uses the
duplicate. The worker dereferences it through btf_is_kernel() and
btf_find_struct_meta() in bpf_obj_free_fields() when destroying elements
that were freed under RCU, and through btf_is_kernel() in
btf_record_free() when releasing the context itself:
BUG: KASAN: slab-use-after-free in btf_is_kernel+0x19/0x30
Read of size 1 at addr ffff88811505dce8 by task kworker/u16:2/50
Workqueue: events_unbound free_mem_alloc_deferred
Call Trace:
btf_is_kernel+0x19/0x30
btf_record_free+0xc7/0xf0
htab_dtor_ctx_free+0x1a/0x30
free_mem_alloc_no_barrier+0x39/0x230
free_mem_alloc_deferred+0x2a/0x40
process_scheduled_works+0x5ce/0x9d0
worker_thread+0x42a/0x5e0
kthread+0x1f5/0x230
ret_from_fork+0x1dd/0x390
ret_from_fork_asm+0x1a/0x30
Allocated by task 358:
__kmalloc_cache_noprof+0x287/0x510
btf_new_fd+0xf7/0x3d0
__sys_bpf+0x487/0x840
Freed by task 0:
kfree+0x186/0x560
rcu_core+0x6f6/0xd40
Freeing a map that still holds more elements than the allocator's high
watermark is enough to get there, because the bulk free during teardown
queues the RCU callback that makes bpf_mem_alloc_destroy() defer.
Non-preallocated hash maps and resizable hash maps both register the
destructor and are affected alike.
Keep one reference on the map BTF in the destructor context. Every
non-kernel pointer in the duplicated record is either map->btf or memory
owned by it, so a single reference covers kptrs, list heads, and rb
roots, and mirrors what bpf_map_meta_alloc() does for the duplicated
record of an inner map. Release it only after the duplicated record has
been freed: the worker is preemptible and not in an RCU read-side
critical section, so dropping the last reference first would let the
BTF be freed while btf_record_free() still reads its fields.
Fixes: 1df97a7453 ("bpf: Register dtor for freeing special fields")
Reported-by: Yuan Chen <chenyuan@kylinos.cn>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20260901062845.1379760-3-chenyuan_fl@163.com
Link: https://patch.msgid.link/20260925064652.2261885-1-memxor@gmail.com
Fix a step-wise thermal governor issue that causes thermal mitigation to
contiune forever after the temperature has dropped below the trip point
threshold in some cases (Manaf Meethalavalappu Pallikunhi).
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEcM8Aw/RY0dgsiRUR7l+9nS/U47UFAmq2l84SHHJqd0Byand5
c29ja2kubmV0AAoJEO5fvZ0v1OO1NAAH/2pYr1erbmTfHAkmka5b+4/nJsAONclz
izc6GPbLdM7PgR7LnAxAlJzQCz9wIljxtOHYKviZmlrnXbVwQxLZLI/GLpF5LN5Z
au79wSH/q1UHsBbLUIUKp887WVEvxeS/jC6//YFUkjY+gVCiRpvKUHkLr8WzQYue
DD1cQNR+nLquYao04+Src02VfbjKhRouMoHNhSkJXOm4IbkPMA75ENBw6LGfWshf
tm1uSXghzog0kNNU3rqjLOdMdIpp1Ea/l1wCfg8mkwd+AVZS2G3eItQbrLQmXPWg
yjKWpmTPggletPB4bz7LjMwkHwI+xzLIWSbr0j5zRqEopedSHhc0MXk=
=VygM
-----END PGP SIGNATURE-----
Merge tag 'thermal-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fix from Rafael Wysocki:
"Fix a step-wise thermal governor issue that causes thermal mitigation
to contiune forever after the temperature has dropped below the trip
point threshold in some cases (Manaf Meethalavalappu Pallikunhi)"
* tag 'thermal-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: gov_step_wise: Fix stale mitigation vote with non-zero lower bounds
Address a hibernation regression introduced during the 7.2 development
cycle that causes the image memory preallocation to deadlock if it
depends on frozen kernel threads (Florian Schmaus).
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEcM8Aw/RY0dgsiRUR7l+9nS/U47UFAmq2mDESHHJqd0Byand5
c29ja2kubmV0AAoJEO5fvZ0v1OO1wFAH/2e9iz++Qjb9SODpGX/2Fz07qb4SBRCP
Zf0r74G7qfoPczcLuiKu8irb1FSvlwr1nlcygWcF0gYLg9TJCaaQ7JIxHL/9ePV0
lbINk+4ozu5S6AbMh7O5wpv3n+nwBtg1wZZP3kSY4hxQ5zymACuEzwBTGT9vfQVA
GpkrasgQVTOyt1gWAO8Ak3WX3z1EaBqzl8DsCm/75PVq2Wy1I801JagtYT6KArf6
kqH19SdiihrTl+2k/k2Vvc14H9XYfXab77ShWv1JgKF7X1QqaO8QWVFQulj0bpgc
LLSlpiQXqBYfz469bPGyS2U6tyFioynqoiWQfdxC6zBGcHv1Jl3LdDg=
=mfRN
-----END PGP SIGNATURE-----
Merge tag 'pm-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"Address a hibernation regression introduced during the 7.2 development
cycle that causes the image memory preallocation to deadlock if it
depends on frozen kernel threads (Florian Schmaus)"
* tag 'pm-7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
PM: hibernate: Freeze kernel threads after image preallocation
- Fix several bugs in PCI error recovery SCLP reporting: don't report
success on skipped recovery, report errors when no pdev is associated,
add missing device lock, and fix struct pci_dev reference leak in
zpci_report_status()
- Fix several bugs in CIO code: fix use of invalid SCHIB data, guard PMCW
field accesses, check device number valid bit in PMWC before accessing
other fields, and fix NULL pointer dereference in
ccw_device_get_util_str()
- Fix virtual vs physical address confusion in channel measurement
facility code on kernels with CONFIG_RANDOMIZE_IDENTITY_BASE=y
- Fix couple of bugs in s390dbf: fix copy of failed static debug areas,
skip view registration on failure, and reject NULL pointer in
debug_dump()
- Fix sriov_numvfs attribute name in zPCI documentation
- Fix typos in comments
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEECMNfWEw3SLnmiLkZIg7DeRspbsIFAmq2V1AACgkQIg7DeRsp
bsJ7zg/7BrnPs0WyKv9NZvVUudYbz3nUIAleJo6HcDK2SUDr+EX3W4U7OjsXL6Fv
H76hx5AqF6ddtUOJ2uevCAb3PKm0eA7vmK9YiERAclrBA+tWGW0xBwCqqyc84k38
CPxOBr87Ae1jIIcfDxfBWujtKTFi/4BpSvKvKgg3mnd2egny4UnHnABx5ZcClEee
p6aVjCKycQFHwNLMoJA1BxvGSpcXdiKXbm6VRJ4gCaBnVuzkLUv1ZMp/Pi1fWVbV
E1AEztZ/03Tfry51q7wQLv6wD5lR3Z/Py2vZ4YIbelQwVMAMI+rFtgd5oFfo9qkF
gcFJ+faE9m0E/nsoaaVCaa2Ja4+hV/vZ5ik0bq1ljEqEvInaa2XTuxNAljId351Y
JrLvCdaip0FkMNMqEym0iydMAlpc491GAhzNrT3yvq6t03VVpxprPPA6VIwHg+zk
UBMP+QdxtnaV8AAUzDD9E255d88N4DECBICUgf1XjFm/I7xLJFWyUvbzcqNn9VnY
EGVBOeQmoByhCL9lN0+nzEM1sgT+hQB/C3WmLqiuLxrxjnc8dVr8rVHcPXFgARPw
Ht3W9jxdTdl4VBwckOWmbvG4L6spXFLdEzI51cP46L1RKWhFjLl/6RoY8fUHf4Vz
YnHutQevSoPI2D6G4v8K1FBz9wclxCojBPbXCmevfbL9B4ChPoQ=
=r3uP
-----END PGP SIGNATURE-----
Merge tag 's390-7.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Heiko Carstens:
- Fix several bugs in PCI error recovery SCLP reporting: don't report
success on skipped recovery, report errors when no pdev is
associated, add missing device lock, and fix struct pci_dev reference
leak in zpci_report_status()
- Fix several bugs in CIO code: fix use of invalid SCHIB data, guard
PMCW field accesses, check device number valid bit in PMWC before
accessing other fields, and fix NULL pointer dereference in
ccw_device_get_util_str()
- Fix virtual vs physical address confusion in channel measurement
facility code on kernels with CONFIG_RANDOMIZE_IDENTITY_BASE=y
- Fix couple of bugs in s390dbf: fix copy of failed static debug areas,
skip view registration on failure, and reject NULL pointer in
debug_dump()
- Fix sriov_numvfs attribute name in zPCI documentation
- Fix typos in comments
* tag 's390-7.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/cio: Fix NULL pointer dereference in ccw_device_get_util_str()
s390/debug: Fix NULL pointer dereference in debug_info_copy()
s390/debug: Do not register views for failed static debug areas
s390/debug: Reject NULL debug info in debug_dump()
s390/cmf: Fix virtual vs physical address confusion
s390/pci: Don't report recovery success on skipped recovery
s390/pci: Report SCLP status on error events when no pdev is associated
s390/pci: Fix missing device lock in zpci_report_status()
s390/pci: Fix leak of struct pci_dev reference in zpci_report_status()
s390/cio: Guard PMCW field accesses with dnv check
s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points
s390/cio: Fix cio_update_schib() to not cache invalid schib
s390/pci/docs: Fix sriov_numvfs attribute name
s390: Fix typos in comments
- fix a regression introduced by moving GPIO hog handling into GPIOLIB
core where of_node_name was used if line name property was missing on
DT systems
- fix kernel stack leak to user-space in error path in GPIO character
device code
- fix runtime PM leaks in gpio-xilinx and gpio-arizona
- fix several register programming bugs in gpio-tps65219
- fix interrupt storm on resume in gpio-mvebu
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEkeUTLeW1Rh17omX8BZ0uy/82hMMFAmq2KYwACgkQBZ0uy/82
hMOkFhAAjIaH6nUhhUBykRyIbBVAbxYFWrps/qLw9Wlg1wDteUwwMWpdHWivsi2M
Ch0zCR1/op812cu47dTsnNteHuK9oGoL0IHXGweylNJVU7IXTiUx6sUu+kLlT2wK
/yIH6Zk78rULodV/80S9aNbFNNHOu7Pu/AEAPPJjGIKK6UVxT7o2o04jG1xORVbr
X11hLjzKe1RpVKo3fhBFglzW1T4YVpulorsgkMNabTG4hbf5pArtkaQGPHVvH3Hk
LNpTFJ3Jmoczo4UgsKAaUso2LoC19hoIUMRBVoOwscTLlPoIE6MTH0bLj+U9npId
TUhGpVYIvfy4B6V2+FU+9YnWTkDE7efmnmm0l+GnNp7FmDTxTO0aVJoouPNEeUgu
Zu1CJxaKYTWuTm5mdk2Tgw5G+3YtzcGS6iW3dCFvshyYSdHHkvPQ6ys2blJJyeEd
2MRoZQZdSzMDmCfw5Y+RxF1jp1BRjIID2NH1p/cxUokFvMDgFJU+MFxdOo6ySnC/
+1EEeA7Gak4StJUDa2Y4+uI0PMokWAEXs3ixlQUmgIpgGVtBIzI17psj4RDumdGD
6HIG/31Pedg3LtUkkzC8P6vfdREzzquWUPBr9F7dApur4/MMJZyeu3pUwFtx0AKs
+T5qgUwwsoKxLmg2EAdg5pThzLVgqgtrSYuw8esqfG8tNRzoRgc=
=Mp0f
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-for-v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- fix a regression introduced by moving GPIO hog handling into GPIOLIB
core where of_node_name was used if line name property was missing on
DT systems
- fix kernel stack leak to user-space in error path in GPIO character
device code
- fix runtime PM leaks in gpio-xilinx and gpio-arizona
- fix several register programming bugs in gpio-tps65219
- fix interrupt storm on resume in gpio-mvebu
* tag 'gpio-fixes-for-v7.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: tps65219: Fix TPS65214 GPIO direction programming
gpio: tps65219: Use the variant-specific direction callback
gpio: tps65219: Fix GPIO input value reads
gpio: zynq: fix runtime PM leak on request error path
gpio: cdev: fix kernel stack leak to user-space in error path
gpiolib: use of_node_name if line-name is missing
gpio: mvebu: keep resume masks within the irqchip cache
gpio: arizona: Fix runtime PM leak in arizona_gpio_direction_out()
