--- /dev/null
+From 635bc4def026a24e071436f4f356ea08c0eed6ff Mon Sep 17 00:00:00 2001
+From: Amir Goldstein <amir73il@gmail.com>
+Date: Sun, 7 Dec 2025 11:44:55 +0100
+Subject: fsnotify: do not generate ACCESS/MODIFY events on child for special files
+
+From: Amir Goldstein <amir73il@gmail.com>
+
+commit 635bc4def026a24e071436f4f356ea08c0eed6ff upstream.
+
+inotify/fanotify do not allow users with no read access to a file to
+subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the
+same user to subscribe for watching events on children when the user
+has access to the parent directory (e.g. /dev).
+
+Users with no read access to a file but with read access to its parent
+directory can still stat the file and see if it was accessed/modified
+via atime/mtime change.
+
+The same is not true for special files (e.g. /dev/null). Users will not
+generally observe atime/mtime changes when other users read/write to
+special files, only when someone sets atime/mtime via utimensat().
+
+Align fsnotify events with this stat behavior and do not generate
+ACCESS/MODIFY events to parent watchers on read/write of special files.
+The events are still generated to parent watchers on utimensat(). This
+closes some side-channels that could be possibly used for information
+exfiltration [1].
+
+[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf
+
+Reported-by: Sudheendra Raghav Neela <sneela@tugraz.at>
+CC: stable@vger.kernel.org
+Signed-off-by: Amir Goldstein <amir73il@gmail.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/notify/fsnotify.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/fs/notify/fsnotify.c
++++ b/fs/notify/fsnotify.c
+@@ -224,8 +224,15 @@ int __fsnotify_parent(struct dentry *den
+ /*
+ * Include parent/name in notification either if some notification
+ * groups require parent info or the parent is interested in this event.
++ * The parent interest in ACCESS/MODIFY events does not apply to special
++ * files, where read/write are not on the filesystem of the parent and
++ * events can provide an undesirable side-channel for information
++ * exfiltration.
+ */
+- parent_interested = mask & p_mask & ALL_FSNOTIFY_EVENTS;
++ parent_interested = mask & p_mask & ALL_FSNOTIFY_EVENTS &&
++ !(data_type == FSNOTIFY_EVENT_PATH &&
++ d_is_special(dentry) &&
++ (mask & (FS_ACCESS | FS_MODIFY)));
+ if (parent_needed || parent_interested) {
+ /* When notifying parent, child should be passed as data */
+ WARN_ON_ONCE(inode != fsnotify_data_inode(data, data_type));
--- /dev/null
+From 5674a76db0213f9db1e4d08e847ff649b46889c0 Mon Sep 17 00:00:00 2001
+From: Yosry Ahmed <yosry.ahmed@linux.dev>
+Date: Fri, 24 Oct 2025 19:29:17 +0000
+Subject: KVM: nSVM: Propagate SVM_EXIT_CR0_SEL_WRITE correctly for LMSW emulation
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Yosry Ahmed <yosry.ahmed@linux.dev>
+
+commit 5674a76db0213f9db1e4d08e847ff649b46889c0 upstream.
+
+When emulating L2 instructions, svm_check_intercept() checks whether a
+write to CR0 should trigger a synthesized #VMEXIT with
+SVM_EXIT_CR0_SEL_WRITE. For MOV-to-CR0, SVM_EXIT_CR0_SEL_WRITE is only
+triggered if any bit other than CR0.MP and CR0.TS is updated. However,
+according to the APM (24593—Rev. 3.42—March 2024, Table 15-7):
+
+ The LMSW instruction treats the selective CR0-write
+ intercept as a non-selective intercept (i.e., it intercepts
+ regardless of the value being written).
+
+Skip checking the changed bits for x86_intercept_lmsw and always inject
+SVM_EXIT_CR0_SEL_WRITE.
+
+Fixes: cfec82cb7d31 ("KVM: SVM: Add intercept check for emulated cr accesses")
+Cc: stable@vger.kernel.org
+Reported-by: Matteo Rizzo <matteorizzo@google.com>
+Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev>
+Link: https://patch.msgid.link/20251024192918.3191141-3-yosry.ahmed@linux.dev
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/svm.c | 18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+--- a/arch/x86/kvm/svm/svm.c
++++ b/arch/x86/kvm/svm/svm.c
+@@ -3900,20 +3900,20 @@ static int svm_check_intercept(struct kv
+ INTERCEPT_SELECTIVE_CR0)))
+ break;
+
+- cr0 = vcpu->arch.cr0 & ~SVM_CR0_SELECTIVE_MASK;
+- val = info->src_val & ~SVM_CR0_SELECTIVE_MASK;
+-
++ /* LMSW always triggers INTERCEPT_SELECTIVE_CR0 */
+ if (info->intercept == x86_intercept_lmsw) {
+- cr0 &= 0xfUL;
+- val &= 0xfUL;
+- /* lmsw can't clear PE - catch this here */
+- if (cr0 & X86_CR0_PE)
+- val |= X86_CR0_PE;
++ icpt_info.exit_code = SVM_EXIT_CR0_SEL_WRITE;
++ break;
+ }
+
++ /*
++ * MOV-to-CR0 only triggers INTERCEPT_SELECTIVE_CR0 if any bit
++ * other than SVM_CR0_SELECTIVE_MASK is changed.
++ */
++ cr0 = vcpu->arch.cr0 & ~SVM_CR0_SELECTIVE_MASK;
++ val = info->src_val & ~SVM_CR0_SELECTIVE_MASK;
+ if (cr0 ^ val)
+ icpt_info.exit_code = SVM_EXIT_CR0_SEL_WRITE;
+-
+ break;
+ }
+ case SVM_EXIT_READ_DR0:
--- /dev/null
+From f402ecd7a8b6446547076f4bd24bd5d4dcc94481 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 13 Nov 2025 14:56:14 -0800
+Subject: KVM: nSVM: Set exit_code_hi to -1 when synthesizing SVM_EXIT_ERR (failed VMRUN)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit f402ecd7a8b6446547076f4bd24bd5d4dcc94481 upstream.
+
+Set exit_code_hi to -1u as a temporary band-aid to fix a long-standing
+(effectively since KVM's inception) bug where KVM treats the exit code as
+a 32-bit value, when in reality it's a 64-bit value. Per the APM, offset
+0x70 is a single 64-bit value:
+
+ 070h 63:0 EXITCODE
+
+And a sane reading of the error values defined in "Table C-1. SVM Intercept
+Codes" is that negative values use the full 64 bits:
+
+ –1 VMEXIT_INVALID Invalid guest state in VMCB.
+ –2 VMEXIT_BUSYBUSY bit was set in the VMSA
+ –3 VMEXIT_IDLE_REQUIREDThe sibling thread is not in an idle state
+ -4 VMEXIT_INVALID_PMC Invalid PMC state
+
+And that interpretation is confirmed by testing on Milan and Turin (by
+setting bits in CR0[63:32] to generate VMEXIT_INVALID on VMRUN).
+
+Furthermore, Xen has treated exitcode as a 64-bit value since HVM support
+was adding in 2006 (see Xen commit d1bd157fbc ("Big merge the HVM
+full-virtualisation abstractions.")).
+
+Cc: Jim Mattson <jmattson@google.com>
+Cc: Yosry Ahmed <yosry.ahmed@linux.dev>
+Cc: stable@vger.kernel.org
+Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev>
+Link: https://patch.msgid.link/20251113225621.1688428-3-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/nested.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/svm/nested.c
++++ b/arch/x86/kvm/svm/nested.c
+@@ -528,7 +528,7 @@ int nested_svm_vmrun(struct vcpu_svm *sv
+ if (!nested_vmcb_check_save(svm, vmcb12) ||
+ !nested_vmcb_check_controls(&svm->nested.ctl)) {
+ vmcb12->control.exit_code = SVM_EXIT_ERR;
+- vmcb12->control.exit_code_hi = 0;
++ vmcb12->control.exit_code_hi = -1u;
+ vmcb12->control.exit_info_1 = 0;
+ vmcb12->control.exit_info_2 = 0;
+ goto out;
+@@ -587,7 +587,7 @@ out_exit_err:
+ svm->nested.nested_run_pending = 0;
+
+ svm->vmcb->control.exit_code = SVM_EXIT_ERR;
+- svm->vmcb->control.exit_code_hi = 0;
++ svm->vmcb->control.exit_code_hi = -1u;
+ svm->vmcb->control.exit_info_1 = 0;
+ svm->vmcb->control.exit_info_2 = 0;
+
--- /dev/null
+From 9633f180ce994ab293ce4924a9b7aaf4673aa114 Mon Sep 17 00:00:00 2001
+From: fuqiang wang <fuqiang.wng@gmail.com>
+Date: Thu, 13 Nov 2025 12:51:12 -0800
+Subject: KVM: x86: Explicitly set new periodic hrtimer expiration in apic_timer_fn()
+
+From: fuqiang wang <fuqiang.wng@gmail.com>
+
+commit 9633f180ce994ab293ce4924a9b7aaf4673aa114 upstream.
+
+When restarting an hrtimer to emulate a the guest's APIC timer in periodic
+mode, explicitly set the expiration using the target expiration computed
+by advance_periodic_target_expiration() instead of adding the period to
+the existing timer. This will allow making adjustments to the expiration,
+e.g. to deal with expirations far in the past, without having to implement
+the same logic in both advance_periodic_target_expiration() and
+apic_timer_fn().
+
+Cc: stable@vger.kernel.org
+Signed-off-by: fuqiang wang <fuqiang.wng@gmail.com>
+[sean: split to separate patch, write changelog]
+Link: https://patch.msgid.link/20251113205114.1647493-3-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/lapic.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -2436,7 +2436,7 @@ static enum hrtimer_restart apic_timer_f
+
+ if (lapic_is_periodic(apic) && !WARN_ON_ONCE(!apic->lapic_timer.period)) {
+ advance_periodic_target_expiration(apic);
+- hrtimer_add_expires_ns(&ktimer->timer, ktimer->period);
++ hrtimer_set_expires(&ktimer->timer, ktimer->target_expiration);
+ return HRTIMER_RESTART;
+ } else
+ return HRTIMER_NORESTART;
--- /dev/null
+From 18ab3fc8e880791aa9f7c000261320fc812b5465 Mon Sep 17 00:00:00 2001
+From: fuqiang wang <fuqiang.wng@gmail.com>
+Date: Thu, 13 Nov 2025 12:51:13 -0800
+Subject: KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
+
+From: fuqiang wang <fuqiang.wng@gmail.com>
+
+commit 18ab3fc8e880791aa9f7c000261320fc812b5465 upstream.
+
+When advancing the target expiration for the guest's APIC timer in periodic
+mode, set the expiration to "now" if the target expiration is in the past
+(similar to what is done in update_target_expiration()). Blindly adding
+the period to the previous target expiration can result in KVM generating
+a practically unbounded number of hrtimer IRQs due to programming an
+expired timer over and over. In extreme scenarios, e.g. if userspace
+pauses/suspends a VM for an extended duration, this can even cause hard
+lockups in the host.
+
+Currently, the bug only affects Intel CPUs when using the hypervisor timer
+(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,
+a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the
+HV timer only runs while the guest is active. As a result, if the vCPU
+does not run for an extended duration, there will be a huge gap between
+the target expiration and the current time the vCPU resumes running.
+Because the target expiration is incremented by only one period on each
+timer expiration, this leads to a series of timer expirations occurring
+rapidly after the vCPU/VM resumes.
+
+More critically, when the vCPU first triggers a periodic HV timer
+expiration after resuming, advancing the expiration by only one period
+will result in a target expiration in the past. As a result, the delta
+may be calculated as a negative value. When the delta is converted into
+an absolute value (tscdeadline is an unsigned u64), the resulting value
+can overflow what the HV timer is capable of programming. I.e. the large
+value will exceed the VMX Preemption Timer's maximum bit width of
+cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the
+HV timer to the software timer (hrtimers).
+
+After switching to the software timer, periodic timer expiration callbacks
+may be executed consecutively within a single clock interrupt handler,
+because hrtimers honors KVM's request for an expiration in the past and
+immediately re-invokes KVM's callback after reprogramming. And because
+the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer
+over and over until the target expiration is advanced to "now" can result
+in a hard lockup.
+
+E.g. the following hard lockup was triggered in the host when running a
+Windows VM (only relevant because it used the APIC timer in periodic mode)
+after resuming the VM from a long suspend (in the host).
+
+ NMI watchdog: Watchdog detected hard LOCKUP on cpu 45
+ ...
+ RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]
+ ...
+ RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046
+ RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc
+ RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500
+ RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0
+ R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0
+ R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8
+ FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0
+ PKRU: 55555554
+ Call Trace:
+ <IRQ>
+ apic_timer_fn+0x31/0x50 [kvm]
+ __hrtimer_run_queues+0x100/0x280
+ hrtimer_interrupt+0x100/0x210
+ ? ttwu_do_wakeup+0x19/0x160
+ smp_apic_timer_interrupt+0x6a/0x130
+ apic_timer_interrupt+0xf/0x20
+ </IRQ>
+
+Moreover, if the suspend duration of the virtual machine is not long enough
+to trigger a hard lockup in this scenario, since commit 98c25ead5eda
+("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM
+will continue using the software timer until the guest reprograms the APIC
+timer in some way. Since the periodic timer does not require frequent APIC
+timer register programming, the guest may continue to use the software
+timer in perpetuity.
+
+Fixes: d8f2f498d9ed ("x86/kvm: fix LAPIC timer drift when guest uses periodic mode")
+Cc: stable@vger.kernel.org
+Signed-off-by: fuqiang wang <fuqiang.wng@gmail.com>
+[sean: massage comments and changelog]
+Link: https://patch.msgid.link/20251113205114.1647493-4-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/lapic.c | 28 +++++++++++++++++++++++-----
+ 1 file changed, 23 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -1790,15 +1790,33 @@ static void advance_periodic_target_expi
+ ktime_t delta;
+
+ /*
+- * Synchronize both deadlines to the same time source or
+- * differences in the periods (caused by differences in the
+- * underlying clocks or numerical approximation errors) will
+- * cause the two to drift apart over time as the errors
+- * accumulate.
++ * Use kernel time as the time source for both the hrtimer deadline and
++ * TSC-based deadline so that they stay synchronized. Computing each
++ * deadline independently will cause the two deadlines to drift apart
++ * over time as differences in the periods accumulate, e.g. due to
++ * differences in the underlying clocks or numerical approximation errors.
+ */
+ apic->lapic_timer.target_expiration =
+ ktime_add_ns(apic->lapic_timer.target_expiration,
+ apic->lapic_timer.period);
++
++ /*
++ * If the new expiration is in the past, e.g. because userspace stopped
++ * running the VM for an extended duration, then force the expiration
++ * to "now" and don't try to play catch-up with the missed events. KVM
++ * will only deliver a single interrupt regardless of how many events
++ * are pending, i.e. restarting the timer with an expiration in the
++ * past will do nothing more than waste host cycles, and can even lead
++ * to a hard lockup in extreme cases.
++ */
++ if (ktime_before(apic->lapic_timer.target_expiration, now))
++ apic->lapic_timer.target_expiration = now;
++
++ /*
++ * Note, ensuring the expiration isn't in the past also prevents delta
++ * from going negative, which could cause the TSC deadline to become
++ * excessively large due to it an unsigned value.
++ */
+ delta = ktime_sub(apic->lapic_timer.target_expiration, now);
+ apic->lapic_timer.tscdeadline = kvm_read_l1_tsc(apic->vcpu, tscl) +
+ nsec_to_cycles(apic->vcpu, delta);
--- /dev/null
+From 0ea9494be9c931ddbc084ad5e11fda91b554cf47 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 13 Nov 2025 12:51:11 -0800
+Subject: KVM: x86: WARN if hrtimer callback for periodic APIC timer fires with period=0
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 0ea9494be9c931ddbc084ad5e11fda91b554cf47 upstream.
+
+WARN and don't restart the hrtimer if KVM's callback runs with the guest's
+APIC timer in periodic mode but with a period of '0', as not advancing the
+hrtimer's deadline would put the CPU into an infinite loop of hrtimer
+events. Observing a period of '0' should be impossible, even when the
+hrtimer is running on a different CPU than the vCPU, as KVM is supposed to
+cancel the hrtimer before changing (or zeroing) the period, e.g. when
+switching from periodic to one-shot.
+
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20251113205114.1647493-2-seanjc@google.com
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/lapic.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -2434,7 +2434,7 @@ static enum hrtimer_restart apic_timer_f
+
+ apic_timer_expired(apic, true);
+
+- if (lapic_is_periodic(apic)) {
++ if (lapic_is_periodic(apic) && !WARN_ON_ONCE(!apic->lapic_timer.period)) {
+ advance_periodic_target_expiration(apic);
+ hrtimer_add_expires_ns(&ktimer->timer, ktimer->period);
+ return HRTIMER_RESTART;
--- /dev/null
+From 8c738512714e8c0aa18f8a10c072d5b01c83db39 Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+Date: Tue, 2 Dec 2025 10:32:31 +0100
+Subject: libceph: make decode_pool() more resilient against corrupted osdmaps
+
+From: Ilya Dryomov <idryomov@gmail.com>
+
+commit 8c738512714e8c0aa18f8a10c072d5b01c83db39 upstream.
+
+If the osdmap is (maliciously) corrupted such that the encoded length
+of ceph_pg_pool envelope is less than what is expected for a particular
+encoding version, out-of-bounds reads may ensue because the only bounds
+check that is there is based on that length value.
+
+This patch adds explicit bounds checks for each field that is decoded
+or skipped.
+
+Cc: stable@vger.kernel.org
+Reported-by: ziming zhang <ezrakiez@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Reviewed-by: Xiubo Li <xiubli@redhat.com>
+Tested-by: ziming zhang <ezrakiez@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/osdmap.c | 118 ++++++++++++++++++++++++------------------------------
+ 1 file changed, 53 insertions(+), 65 deletions(-)
+
+--- a/net/ceph/osdmap.c
++++ b/net/ceph/osdmap.c
+@@ -790,51 +790,49 @@ static int decode_pool(void **p, void *e
+ ceph_decode_need(p, end, len, bad);
+ pool_end = *p + len;
+
++ ceph_decode_need(p, end, 4 + 4 + 4, bad);
+ pi->type = ceph_decode_8(p);
+ pi->size = ceph_decode_8(p);
+ pi->crush_ruleset = ceph_decode_8(p);
+ pi->object_hash = ceph_decode_8(p);
+-
+ pi->pg_num = ceph_decode_32(p);
+ pi->pgp_num = ceph_decode_32(p);
+
+- *p += 4 + 4; /* skip lpg* */
+- *p += 4; /* skip last_change */
+- *p += 8 + 4; /* skip snap_seq, snap_epoch */
++ /* lpg*, last_change, snap_seq, snap_epoch */
++ ceph_decode_skip_n(p, end, 8 + 4 + 8 + 4, bad);
+
+ /* skip snaps */
+- num = ceph_decode_32(p);
++ ceph_decode_32_safe(p, end, num, bad);
+ while (num--) {
+- *p += 8; /* snapid key */
+- *p += 1 + 1; /* versions */
+- len = ceph_decode_32(p);
+- *p += len;
++ /* snapid key, pool snap (with versions) */
++ ceph_decode_skip_n(p, end, 8 + 2, bad);
++ ceph_decode_skip_string(p, end, bad);
+ }
+
+- /* skip removed_snaps */
+- num = ceph_decode_32(p);
+- *p += num * (8 + 8);
++ /* removed_snaps */
++ ceph_decode_skip_map(p, end, 64, 64, bad);
+
++ ceph_decode_need(p, end, 8 + 8 + 4, bad);
+ *p += 8; /* skip auid */
+ pi->flags = ceph_decode_64(p);
+ *p += 4; /* skip crash_replay_interval */
+
+ if (ev >= 7)
+- pi->min_size = ceph_decode_8(p);
++ ceph_decode_8_safe(p, end, pi->min_size, bad);
+ else
+ pi->min_size = pi->size - pi->size / 2;
+
+ if (ev >= 8)
+- *p += 8 + 8; /* skip quota_max_* */
++ /* quota_max_* */
++ ceph_decode_skip_n(p, end, 8 + 8, bad);
+
+ if (ev >= 9) {
+- /* skip tiers */
+- num = ceph_decode_32(p);
+- *p += num * 8;
++ /* tiers */
++ ceph_decode_skip_set(p, end, 64, bad);
+
++ ceph_decode_need(p, end, 8 + 1 + 8 + 8, bad);
+ *p += 8; /* skip tier_of */
+ *p += 1; /* skip cache_mode */
+-
+ pi->read_tier = ceph_decode_64(p);
+ pi->write_tier = ceph_decode_64(p);
+ } else {
+@@ -842,86 +840,76 @@ static int decode_pool(void **p, void *e
+ pi->write_tier = -1;
+ }
+
+- if (ev >= 10) {
+- /* skip properties */
+- num = ceph_decode_32(p);
+- while (num--) {
+- len = ceph_decode_32(p);
+- *p += len; /* key */
+- len = ceph_decode_32(p);
+- *p += len; /* val */
+- }
+- }
++ if (ev >= 10)
++ /* properties */
++ ceph_decode_skip_map(p, end, string, string, bad);
+
+ if (ev >= 11) {
+- /* skip hit_set_params */
+- *p += 1 + 1; /* versions */
+- len = ceph_decode_32(p);
+- *p += len;
++ /* hit_set_params (with versions) */
++ ceph_decode_skip_n(p, end, 2, bad);
++ ceph_decode_skip_string(p, end, bad);
+
+- *p += 4; /* skip hit_set_period */
+- *p += 4; /* skip hit_set_count */
++ /* hit_set_period, hit_set_count */
++ ceph_decode_skip_n(p, end, 4 + 4, bad);
+ }
+
+ if (ev >= 12)
+- *p += 4; /* skip stripe_width */
++ /* stripe_width */
++ ceph_decode_skip_32(p, end, bad);
+
+- if (ev >= 13) {
+- *p += 8; /* skip target_max_bytes */
+- *p += 8; /* skip target_max_objects */
+- *p += 4; /* skip cache_target_dirty_ratio_micro */
+- *p += 4; /* skip cache_target_full_ratio_micro */
+- *p += 4; /* skip cache_min_flush_age */
+- *p += 4; /* skip cache_min_evict_age */
+- }
+-
+- if (ev >= 14) {
+- /* skip erasure_code_profile */
+- len = ceph_decode_32(p);
+- *p += len;
+- }
++ if (ev >= 13)
++ /* target_max_*, cache_target_*, cache_min_* */
++ ceph_decode_skip_n(p, end, 16 + 8 + 8, bad);
++
++ if (ev >= 14)
++ /* erasure_code_profile */
++ ceph_decode_skip_string(p, end, bad);
+
+ /*
+ * last_force_op_resend_preluminous, will be overridden if the
+ * map was encoded with RESEND_ON_SPLIT
+ */
+ if (ev >= 15)
+- pi->last_force_request_resend = ceph_decode_32(p);
++ ceph_decode_32_safe(p, end, pi->last_force_request_resend, bad);
+ else
+ pi->last_force_request_resend = 0;
+
+ if (ev >= 16)
+- *p += 4; /* skip min_read_recency_for_promote */
++ /* min_read_recency_for_promote */
++ ceph_decode_skip_32(p, end, bad);
+
+ if (ev >= 17)
+- *p += 8; /* skip expected_num_objects */
++ /* expected_num_objects */
++ ceph_decode_skip_64(p, end, bad);
+
+ if (ev >= 19)
+- *p += 4; /* skip cache_target_dirty_high_ratio_micro */
++ /* cache_target_dirty_high_ratio_micro */
++ ceph_decode_skip_32(p, end, bad);
+
+ if (ev >= 20)
+- *p += 4; /* skip min_write_recency_for_promote */
++ /* min_write_recency_for_promote */
++ ceph_decode_skip_32(p, end, bad);
+
+ if (ev >= 21)
+- *p += 1; /* skip use_gmt_hitset */
++ /* use_gmt_hitset */
++ ceph_decode_skip_8(p, end, bad);
+
+ if (ev >= 22)
+- *p += 1; /* skip fast_read */
++ /* fast_read */
++ ceph_decode_skip_8(p, end, bad);
+
+- if (ev >= 23) {
+- *p += 4; /* skip hit_set_grade_decay_rate */
+- *p += 4; /* skip hit_set_search_last_n */
+- }
++ if (ev >= 23)
++ /* hit_set_grade_decay_rate, hit_set_search_last_n */
++ ceph_decode_skip_n(p, end, 4 + 4, bad);
+
+ if (ev >= 24) {
+- /* skip opts */
+- *p += 1 + 1; /* versions */
+- len = ceph_decode_32(p);
+- *p += len;
++ /* opts (with versions) */
++ ceph_decode_skip_n(p, end, 2, bad);
++ ceph_decode_skip_string(p, end, bad);
+ }
+
+ if (ev >= 25)
+- pi->last_force_request_resend = ceph_decode_32(p);
++ ceph_decode_32_safe(p, end, pi->last_force_request_resend, bad);
+
+ /* ignore the rest */
+
--- /dev/null
+From 98aabfe2d79f74613abc2b0b1cef08f97eaf5322 Mon Sep 17 00:00:00 2001
+From: Jeongjun Park <aha310510@gmail.com>
+Date: Fri, 5 Sep 2025 14:18:16 +0900
+Subject: media: vidtv: initialize local pointers upon transfer of memory ownership
+
+From: Jeongjun Park <aha310510@gmail.com>
+
+commit 98aabfe2d79f74613abc2b0b1cef08f97eaf5322 upstream.
+
+vidtv_channel_si_init() creates a temporary list (program, service, event)
+and ownership of the memory itself is transferred to the PAT/SDT/EIT
+tables through vidtv_psi_pat_program_assign(),
+vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().
+
+The problem here is that the local pointer where the memory ownership
+transfer was completed is not initialized to NULL. This causes the
+vidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, and
+in the flow that jumps to free_eit, the memory that was freed by
+vidtv_psi_*_table_destroy() can be accessed again by
+vidtv_psi_*_event_destroy() due to the uninitialized local pointer, so it
+is freed once again.
+
+Therefore, to prevent use-after-free and double-free vulnerability,
+local pointers must be initialized to NULL when transferring memory
+ownership.
+
+Cc: <stable@vger.kernel.org>
+Reported-by: syzbot+1d9c0edea5907af239e0@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=1d9c0edea5907af239e0
+Fixes: 3be8037960bc ("media: vidtv: add error checks")
+Signed-off-by: Jeongjun Park <aha310510@gmail.com>
+Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/test-drivers/vidtv/vidtv_channel.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/media/test-drivers/vidtv/vidtv_channel.c
++++ b/drivers/media/test-drivers/vidtv/vidtv_channel.c
+@@ -461,12 +461,15 @@ int vidtv_channel_si_init(struct vidtv_m
+
+ /* assemble all programs and assign to PAT */
+ vidtv_psi_pat_program_assign(m->si.pat, programs);
++ programs = NULL;
+
+ /* assemble all services and assign to SDT */
+ vidtv_psi_sdt_service_assign(m->si.sdt, services);
++ services = NULL;
+
+ /* assemble all events and assign to EIT */
+ vidtv_psi_eit_event_assign(m->si.eit, events);
++ events = NULL;
+
+ m->si.pmt_secs = vidtv_psi_pmt_create_sec_for_each_pat_entry(m->si.pat,
+ m->pcr_pid);
--- /dev/null
+From ebae102897e760e9e6bc625f701dd666b2163bd1 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Thu, 13 Nov 2025 09:31:31 +0100
+Subject: nfsd: Mark variable __maybe_unused to avoid W=1 build break
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit ebae102897e760e9e6bc625f701dd666b2163bd1 upstream.
+
+Clang is not happy about set but (in some cases) unused variable:
+
+fs/nfsd/export.c:1027:17: error: variable 'inode' set but not used [-Werror,-Wunused-but-set-variable]
+
+since it's used as a parameter to dprintk() which might be configured
+a no-op. To avoid uglifying code with the specific ifdeffery just mark
+the variable __maybe_unused.
+
+The commit [1], which introduced this behaviour, is quite old and hence
+the Fixes tag points to the first of the Git era.
+
+Link: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=0431923fb7a1 [1]
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/export.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/nfsd/export.c
++++ b/fs/nfsd/export.c
+@@ -984,7 +984,7 @@ exp_rootfh(struct net *net, struct auth_
+ {
+ struct svc_export *exp;
+ struct path path;
+- struct inode *inode;
++ struct inode *inode __maybe_unused;
+ struct svc_fh fh;
+ int err;
+ struct nfsd_net *nn = net_generic(net, nfsd_net_id);
--- /dev/null
+From 039bef30e320827bac8990c9f29d2a68cd8adb5f Mon Sep 17 00:00:00 2001
+From: Prithvi Tambewagh <activprithvi@gmail.com>
+Date: Mon, 1 Dec 2025 18:37:11 +0530
+Subject: ocfs2: fix kernel BUG in ocfs2_find_victim_chain
+
+From: Prithvi Tambewagh <activprithvi@gmail.com>
+
+commit 039bef30e320827bac8990c9f29d2a68cd8adb5f upstream.
+
+syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the
+`cl_next_free_rec` field of the allocation chain list (next free slot in
+the chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec)
+condition in ocfs2_find_victim_chain() and panicking the kernel.
+
+To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),
+just before calling ocfs2_find_victim_chain(), the code block in it being
+executed when either of the following conditions is true:
+
+1. `cl_next_free_rec` is equal to 0, indicating that there are no free
+chains in the allocation chain list
+2. `cl_next_free_rec` is greater than `cl_count` (the total number of
+chains in the allocation chain list)
+
+Either of them being true is indicative of the fact that there are no
+chains left for usage.
+
+This is addressed using ocfs2_error(), which prints
+the error log for debugging purposes, rather than panicking the kernel.
+
+Link: https://lkml.kernel.org/r/20251201130711.143900-1-activprithvi@gmail.com
+Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>
+Reported-by: syzbot+96d38c6e1655c1420a72@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72
+Tested-by: syzbot+96d38c6e1655c1420a72@syzkaller.appspotmail.com
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: Heming Zhao <heming.zhao@suse.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/suballoc.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/fs/ocfs2/suballoc.c
++++ b/fs/ocfs2/suballoc.c
+@@ -1925,6 +1925,16 @@ static int ocfs2_claim_suballoc_bits(str
+ }
+
+ cl = (struct ocfs2_chain_list *) &fe->id2.i_chain;
++ if (!le16_to_cpu(cl->cl_next_free_rec) ||
++ le16_to_cpu(cl->cl_next_free_rec) > le16_to_cpu(cl->cl_count)) {
++ status = ocfs2_error(ac->ac_inode->i_sb,
++ "Chain allocator dinode %llu has invalid next "
++ "free chain record %u, but only %u total\n",
++ (unsigned long long)le64_to_cpu(fe->i_blkno),
++ le16_to_cpu(cl->cl_next_free_rec),
++ le16_to_cpu(cl->cl_count));
++ goto bail;
++ }
+
+ victim = ocfs2_find_victim_chain(cl);
+ ac->ac_chain = victim;
--- /dev/null
+From dca7da244349eef4d78527cafc0bf80816b261f5 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Tue, 25 Nov 2025 15:23:02 +0100
+Subject: parisc: Do not reprogram affinitiy on ASP chip
+
+From: Helge Deller <deller@gmx.de>
+
+commit dca7da244349eef4d78527cafc0bf80816b261f5 upstream.
+
+The ASP chip is a very old variant of the GSP chip and is used e.g. in
+HP 730 workstations. When trying to reprogram the affinity it will crash
+with a HPMC as the relevant registers don't seem to be at the usual
+location. Let's avoid the crash by checking the sversion. Also note,
+that reprogramming isn't necessary either, as the HP730 is a just a
+single-CPU machine.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/parisc/gsc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/parisc/gsc.c
++++ b/drivers/parisc/gsc.c
+@@ -154,7 +154,9 @@ static int gsc_set_affinity_irq(struct i
+ gsc_dev->eim = ((u32) gsc_dev->gsc_irq.txn_addr) | gsc_dev->gsc_irq.txn_data;
+
+ /* switch IRQ's for devices below LASI/WAX to other CPU */
+- gsc_writel(gsc_dev->eim, gsc_dev->hpa + OFFSET_IAR);
++ /* ASP chip (svers 0x70) does not support reprogramming */
++ if (gsc_dev->gsc->id.sversion != 0x70)
++ gsc_writel(gsc_dev->eim, gsc_dev->hpa + OFFSET_IAR);
+
+ irq_data_update_effective_affinity(d, &tmask);
+
--- /dev/null
+From 944edca81e7aea15f83cf9a13a6ab67f711e8abd Mon Sep 17 00:00:00 2001
+From: Tzung-Bi Shih <tzungbi@kernel.org>
+Date: Fri, 31 Oct 2025 03:39:00 +0000
+Subject: platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driver
+
+From: Tzung-Bi Shih <tzungbi@kernel.org>
+
+commit 944edca81e7aea15f83cf9a13a6ab67f711e8abd upstream.
+
+After unbinding the driver, another kthread `cros_ec_console_log_work`
+is still accessing the device, resulting an UAF and crash.
+
+The driver doesn't unregister the EC device in .remove() which should
+shutdown sub-devices synchronously. Fix it.
+
+Fixes: 26a14267aff2 ("platform/chrome: Add ChromeOS EC ISHTP driver")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20251031033900.3577394-1-tzungbi@kernel.org
+Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/chrome/cros_ec_ishtp.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/platform/chrome/cros_ec_ishtp.c
++++ b/drivers/platform/chrome/cros_ec_ishtp.c
+@@ -714,6 +714,7 @@ static int cros_ec_ishtp_remove(struct i
+
+ cancel_work_sync(&client_data->work_ishtp_reset);
+ cancel_work_sync(&client_data->work_ec_evt);
++ cros_ec_unregister(client_data->ec_dev);
+ cros_ish_deinit(cros_ish_cl);
+ ishtp_put_device(cl_device);
+
--- /dev/null
+From 359afc8eb02a518fbdd0cbd462c8c2827c6cbec2 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Mon, 15 Dec 2025 15:21:34 +0100
+Subject: PM: runtime: Do not clear needs_force_resume with enabled runtime PM
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 359afc8eb02a518fbdd0cbd462c8c2827c6cbec2 upstream.
+
+Commit 89d9cec3b1e9 ("PM: runtime: Clear power.needs_force_resume in
+pm_runtime_reinit()") added provisional clearing of power.needs_force_resume
+to pm_runtime_reinit(), but it is done unconditionally which is a
+mistake because pm_runtime_reinit() may race with driver probing
+and removal [1].
+
+To address this, notice that power.needs_force_resume should never
+be set when runtime PM is enabled and so it only needs to be cleared
+when runtime PM is disabled, and update pm_runtime_init() to only
+clear that flag when runtime PM is disabled.
+
+Fixes: 89d9cec3b1e9 ("PM: runtime: Clear power.needs_force_resume in pm_runtime_reinit()")
+Reported-by: Ed Tsai <ed.tsai@mediatek.com>
+Closes: https://lore.kernel.org/linux-pm/20251215122154.3180001-1-ed.tsai@mediatek.com/ [1]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: 6.17+ <stable@vger.kernel.org> # 6.17+
+Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
+Link: https://patch.msgid.link/12807571.O9o76ZdvQC@rafael.j.wysocki
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/power/runtime.c | 22 ++++++++++++----------
+ 1 file changed, 12 insertions(+), 10 deletions(-)
+
+--- a/drivers/base/power/runtime.c
++++ b/drivers/base/power/runtime.c
+@@ -1749,16 +1749,18 @@ void pm_runtime_init(struct device *dev)
+ */
+ void pm_runtime_reinit(struct device *dev)
+ {
+- if (!pm_runtime_enabled(dev)) {
+- if (dev->power.runtime_status == RPM_ACTIVE)
+- pm_runtime_set_suspended(dev);
+- if (dev->power.irq_safe) {
+- spin_lock_irq(&dev->power.lock);
+- dev->power.irq_safe = 0;
+- spin_unlock_irq(&dev->power.lock);
+- if (dev->parent)
+- pm_runtime_put(dev->parent);
+- }
++ if (pm_runtime_enabled(dev))
++ return;
++
++ if (dev->power.runtime_status == RPM_ACTIVE)
++ pm_runtime_set_suspended(dev);
++
++ if (dev->power.irq_safe) {
++ spin_lock_irq(&dev->power.lock);
++ dev->power.irq_safe = 0;
++ spin_unlock_irq(&dev->power.lock);
++ if (dev->parent)
++ pm_runtime_put(dev->parent);
+ }
+ /*
+ * Clear power.needs_force_resume in case it has been set by
--- /dev/null
+From 08bd4c46d5e63b78e77f2605283874bbe868ab19 Mon Sep 17 00:00:00 2001
+From: Zhichi Lin <zhichi.lin@vivo.com>
+Date: Sat, 11 Oct 2025 16:22:22 +0800
+Subject: scs: fix a wrong parameter in __scs_magic
+
+From: Zhichi Lin <zhichi.lin@vivo.com>
+
+commit 08bd4c46d5e63b78e77f2605283874bbe868ab19 upstream.
+
+__scs_magic() needs a 'void *' variable, but a 'struct task_struct *' is
+given. 'task_scs(tsk)' is the starting address of the task's shadow call
+stack, and '__scs_magic(task_scs(tsk))' is the end address of the task's
+shadow call stack. Here should be '__scs_magic(task_scs(tsk))'.
+
+The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE
+is enabled, the shadow call stack usage checking function
+(scs_check_usage) would scan an incorrect memory range. This could lead
+to:
+
+1. **Inaccurate stack usage reporting**: The function would calculate
+ wrong usage statistics for the shadow call stack, potentially showing
+ incorrect value in kmsg.
+
+2. **Potential kernel crash**: If the value of __scs_magic(tsk)is
+ greater than that of __scs_magic(task_scs(tsk)), the for loop may
+ access unmapped memory, potentially causing a kernel panic. However,
+ this scenario is unlikely because task_struct is allocated via the slab
+ allocator (which typically returns lower addresses), while the shadow
+ call stack returned by task_scs(tsk) is allocated via vmalloc(which
+ typically returns higher addresses).
+
+However, since this is purely a debugging feature
+(CONFIG_DEBUG_STACK_USAGE), normal production systems should be not
+unaffected. The bug only impacts developers and testers who are actively
+debugging stack usage with this configuration enabled.
+
+Link: https://lkml.kernel.org/r/20251011082222.12965-1-zhichi.lin@vivo.com
+Fixes: 5bbaf9d1fcb9 ("scs: Add support for stack usage debugging")
+Signed-off-by: Jiyuan Xie <xiejiyuan@vivo.com>
+Signed-off-by: Zhichi Lin <zhichi.lin@vivo.com>
+Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
+Acked-by: Will Deacon <will@kernel.org>
+Cc: Andrey Konovalov <andreyknvl@gmail.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Marco Elver <elver@google.com>
+Cc: Will Deacon <will@kernel.org>
+Cc: Yee Lee <yee.lee@mediatek.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/scs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/scs.c
++++ b/kernel/scs.c
+@@ -71,7 +71,7 @@ static void scs_check_usage(struct task_
+ if (!IS_ENABLED(CONFIG_DEBUG_STACK_USAGE))
+ return;
+
+- for (p = task_scs(tsk); p < __scs_magic(tsk); ++p) {
++ for (p = task_scs(tsk); p < __scs_magic(task_scs(tsk)); ++p) {
+ if (!READ_ONCE_NOCHECK(*p))
+ break;
+ used += sizeof(*p);
scsi-target-reset-t_task_cdb-pointer-in-error-case.patch
f2fs-invalidate-dentry-cache-on-failed-whiteout-creation.patch
f2fs-fix-return-value-of-f2fs_recover_fsync_data.patch
+tools-testing-nvdimm-use-per-dimm-device-handle.patch
+media-vidtv-initialize-local-pointers-upon-transfer-of-memory-ownership.patch
+ocfs2-fix-kernel-bug-in-ocfs2_find_victim_chain.patch
+platform-chrome-cros_ec_ishtp-fix-uaf-after-unbinding-driver.patch
+scs-fix-a-wrong-parameter-in-__scs_magic.patch
+parisc-do-not-reprogram-affinitiy-on-asp-chip.patch
+libceph-make-decode_pool-more-resilient-against-corrupted-osdmaps.patch
+kvm-x86-warn-if-hrtimer-callback-for-periodic-apic-timer-fires-with-period-0.patch
+kvm-x86-explicitly-set-new-periodic-hrtimer-expiration-in-apic_timer_fn.patch
+kvm-x86-fix-vm-hard-lockup-after-prolonged-inactivity-with-periodic-hv-timer.patch
+kvm-nsvm-propagate-svm_exit_cr0_sel_write-correctly-for-lmsw-emulation.patch
+kvm-nsvm-set-exit_code_hi-to-1-when-synthesizing-svm_exit_err-failed-vmrun.patch
+tracing-do-not-register-unsupported-perf-events.patch
+pm-runtime-do-not-clear-needs_force_resume-with-enabled-runtime-pm.patch
+fsnotify-do-not-generate-access-modify-events-on-child-for-special-files.patch
+nfsd-mark-variable-__maybe_unused-to-avoid-w-1-build-break.patch
--- /dev/null
+From f59b701b4674f7955170b54c4167c5590f4714eb Mon Sep 17 00:00:00 2001
+From: Alison Schofield <alison.schofield@intel.com>
+Date: Fri, 31 Oct 2025 16:42:20 -0700
+Subject: tools/testing/nvdimm: Use per-DIMM device handle
+
+From: Alison Schofield <alison.schofield@intel.com>
+
+commit f59b701b4674f7955170b54c4167c5590f4714eb upstream.
+
+KASAN reports a global-out-of-bounds access when running these nfit
+tests: clear.sh, pmem-errors.sh, pfn-meta-errors.sh, btt-errors.sh,
+daxdev-errors.sh, and inject-error.sh.
+
+[] BUG: KASAN: global-out-of-bounds in nfit_test_ctl+0x769f/0x7840 [nfit_test]
+[] Read of size 4 at addr ffffffffc03ea01c by task ndctl/1215
+[] The buggy address belongs to the variable:
+[] handle+0x1c/0x1df4 [nfit_test]
+
+nfit_test_search_spa() uses handle[nvdimm->id] to retrieve a device
+handle and triggers a KASAN error when it reads past the end of the
+handle array. It should not be indexing the handle array at all.
+
+The correct device handle is stored in per-DIMM test data. Each DIMM
+has a struct nfit_mem that embeds a struct acpi_nfit_memdev that
+describes the NFIT device handle. Use that device handle here.
+
+Fixes: 10246dc84dfc ("acpi nfit: nfit_test supports translate SPA")
+Cc: stable@vger.kernel.org
+Signed-off-by: Alison Schofield <alison.schofield@intel.com>
+Reviewed-by: Dave Jiang <dave.jiang@intel.com>> ---
+Link: https://patch.msgid.link/20251031234227.1303113-1-alison.schofield@intel.com
+Signed-off-by: Ira Weiny <ira.weiny@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/nvdimm/test/nfit.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/tools/testing/nvdimm/test/nfit.c
++++ b/tools/testing/nvdimm/test/nfit.c
+@@ -673,6 +673,7 @@ static int nfit_test_search_spa(struct n
+ .addr = spa->spa,
+ .region = NULL,
+ };
++ struct nfit_mem *nfit_mem;
+ u64 dpa;
+
+ ret = device_for_each_child(&bus->dev, &ctx,
+@@ -690,8 +691,12 @@ static int nfit_test_search_spa(struct n
+ */
+ nd_mapping = &nd_region->mapping[nd_region->ndr_mappings - 1];
+ nvdimm = nd_mapping->nvdimm;
++ nfit_mem = nvdimm_provider_data(nvdimm);
++ if (!nfit_mem)
++ return -EINVAL;
+
+- spa->devices[0].nfit_device_handle = handle[nvdimm->id];
++ spa->devices[0].nfit_device_handle =
++ __to_nfit_memdev(nfit_mem)->device_handle;
+ spa->num_nvdimms = 1;
+ spa->devices[0].dpa = dpa;
+
--- /dev/null
+From ef7f38df890f5dcd2ae62f8dbde191d72f3bebae Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Tue, 16 Dec 2025 18:24:40 -0500
+Subject: tracing: Do not register unsupported perf events
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit ef7f38df890f5dcd2ae62f8dbde191d72f3bebae upstream.
+
+Synthetic events currently do not have a function to register perf events.
+This leads to calling the tracepoint register functions with a NULL
+function pointer which triggers:
+
+ ------------[ cut here ]------------
+ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272
+ Modules linked in: kvm_intel kvm irqbypass
+ CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
+ RIP: 0010:tracepoint_add_func+0x357/0x370
+ Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f
+ RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246
+ RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000
+ RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8
+ RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780
+ R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a
+ R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78
+ FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0
+ Call Trace:
+ <TASK>
+ tracepoint_probe_register+0x5d/0x90
+ synth_event_reg+0x3c/0x60
+ perf_trace_event_init+0x204/0x340
+ perf_trace_init+0x85/0xd0
+ perf_tp_event_init+0x2e/0x50
+ perf_try_init_event+0x6f/0x230
+ ? perf_event_alloc+0x4bb/0xdc0
+ perf_event_alloc+0x65a/0xdc0
+ __se_sys_perf_event_open+0x290/0x9f0
+ do_syscall_64+0x93/0x7b0
+ ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
+ ? trace_hardirqs_off+0x53/0xc0
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+
+Instead, have the code return -ENODEV, which doesn't warn and has perf
+error out with:
+
+ # perf record -e synthetic:futex_wait
+Error:
+The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).
+"dmesg | grep -i perf" may provide additional information.
+
+Ideally perf should support synthetic events, but for now just fix the
+warning. The support can come later.
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Link: https://patch.msgid.link/20251216182440.147e4453@gandalf.local.home
+Fixes: 4b147936fa509 ("tracing: Add support for 'synthetic' events")
+Reported-by: Ian Rogers <irogers@google.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/kernel/trace/trace_events.c
++++ b/kernel/trace/trace_events.c
+@@ -303,6 +303,8 @@ int trace_event_reg(struct trace_event_c
+
+ #ifdef CONFIG_PERF_EVENTS
+ case TRACE_REG_PERF_REGISTER:
++ if (!call->class->perf_probe)
++ return -ENODEV;
+ return tracepoint_probe_register(call->tp,
+ call->class->perf_probe,
+ call);
projects / thirdparty / kernel / stable-queue.git / commitdiff
