- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] io_uring: fix filename leak in __io_openat_prep()" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x b14fad555302a2104948feaff70503b64c80ac01 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025122931-primer-motivate-1780@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b14fad555302a2104948feaff70503b64c80ac01 Mon Sep 17 00:00:00 2001 From: Prithvi Tambewagh <activprithvi(a)gmail.com> Date: Thu, 25 Dec 2025 12:58:29 +0530 Subject: [PATCH] io_uring: fix filename leak in __io_openat_prep() __io_openat_prep() allocates a struct filename using getname(). However, for the condition of the file being installed in the fixed file table as well as having O_CLOEXEC flag set, the function returns early. At that point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak. Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup. Reported-by: syzbot+00e61c43eb5e4740438f(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=00e61c43eb5e4740438f Tested-by: syzbot+00e61c43eb5e4740438f(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> Fixes: b9445598d8c6 ("io_uring: openat directly into fixed fd table") Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/openclose.c b/io_uring/openclose.c index bfeb91b31bba..15dde9bd6ff6 100644 --- a/io_uring/openclose.c +++ b/io_uring/openclose.c @@ -73,13 +73,13 @@ static int __io_openat_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe open->filename = NULL; return ret; } + req->flags |= REQ_F_NEED_CLEANUP; open->file_slot = READ_ONCE(sqe->file_index); if (open->file_slot && (open->how.flags & O_CLOEXEC)) return -EINVAL; open->nofile = rlimit(RLIMIT_NOFILE); - req->flags |= REQ_F_NEED_CLEANUP; if (io_openat_force_async(open)) req->flags |= REQ_F_FORCE_ASYNC; return 0;

19 minutes

1
0
0 0

FAILED: patch "[PATCH] io_uring: fix min_wait wakeups for SQPOLL" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x e15cb2200b934e507273510ba6bc747d5cde24a3 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025122915-sensually-wasting-f5f8@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e15cb2200b934e507273510ba6bc747d5cde24a3 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Tue, 9 Dec 2025 13:25:23 -0700 Subject: [PATCH] io_uring: fix min_wait wakeups for SQPOLL Using min_wait, two timeouts are given: 1) The min_wait timeout, within which up to 'wait_nr' events are waited for. 2) The overall long timeout, which is entered if no events are generated in the min_wait window. If the min_wait has expired, any event being posted must wake the task. For SQPOLL, that isn't the case, as it won't trigger the io_has_work() condition, as it will have already processed the task_work that happened when an event was posted. This causes any event to trigger post the min_wait to not always cause the waiting application to wakeup, and instead it will wait until the overall timeout has expired. This can be shown in a test case that has a 1 second min_wait, with a 5 second overall wait, even if an event triggers after 1.5 seconds: axboe@m2max-kvm /d/iouring-mre (master)> zig-out/bin/iouring info: MIN_TIMEOUT supported: true, features: 0x3ffff info: Testing: min_wait=1000ms, timeout=5s, wait_nr=4 info: 1 cqes in 5000.2ms where the expected result should be: axboe@m2max-kvm /d/iouring-mre (master)> zig-out/bin/iouring info: MIN_TIMEOUT supported: true, features: 0x3ffff info: Testing: min_wait=1000ms, timeout=5s, wait_nr=4 info: 1 cqes in 1500.3ms When the min_wait timeout triggers, reset the number of completions needed to wake the task. This should ensure that any future events will wake the task, regardless of how many events it originally wanted to wait for. Reported-by: Tip ten Brink <tip(a)tenbrinkmeijs.com> Cc: stable(a)vger.kernel.org Fixes: 1100c4a2656d ("io_uring: add support for batch wait timeout") Link: https://github.com/axboe/liburing/issues/1477 Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index 5d130c578435..6cb24cdf8e68 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -2536,6 +2536,9 @@ static enum hrtimer_restart io_cqring_min_timer_wakeup(struct hrtimer *timer) goto out_wake; } + /* any generated CQE posted past this time should wake us up */ + iowq->cq_tail = iowq->cq_min_tail; + hrtimer_update_function(&iowq->t, io_cqring_timer_wakeup); hrtimer_set_expires(timer, iowq->timeout); return HRTIMER_RESTART;

19 minutes

1
0
0 0

FAILED: patch "[PATCH] io_uring/poll: correctly handle io_poll_add() return value on" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 84230ad2d2afbf0c44c32967e525c0ad92e26b4e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025122905-unused-cash-520e@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 84230ad2d2afbf0c44c32967e525c0ad92e26b4e Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Mon, 1 Dec 2025 13:25:22 -0700 Subject: [PATCH] io_uring/poll: correctly handle io_poll_add() return value on update When the core of io_uring was updated to handle completions consistently and with fixed return codes, the POLL_REMOVE opcode with updates got slightly broken. If a POLL_ADD is pending and then POLL_REMOVE is used to update the events of that request, if that update causes the POLL_ADD to now trigger, then that completion is lost and a CQE is never posted. Additionally, ensure that if an update does cause an existing POLL_ADD to complete, that the completion value isn't always overwritten with -ECANCELED. For that case, whatever io_poll_add() set the value to should just be retained. Cc: stable(a)vger.kernel.org Fixes: 97b388d70b53 ("io_uring: handle completions in the core") Reported-by: syzbot+641eec6b7af1f62f2b99(a)syzkaller.appspotmail.com Tested-by: syzbot+641eec6b7af1f62f2b99(a)syzkaller.appspotmail.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/poll.c b/io_uring/poll.c index 8aa4e3a31e73..3f1d716dcfab 100644 --- a/io_uring/poll.c +++ b/io_uring/poll.c @@ -937,12 +937,17 @@ int io_poll_remove(struct io_kiocb *req, unsigned int issue_flags) ret2 = io_poll_add(preq, issue_flags & ~IO_URING_F_UNLOCKED); /* successfully updated, don't complete poll request */ - if (!ret2 || ret2 == -EIOCBQUEUED) + if (ret2 == IOU_ISSUE_SKIP_COMPLETE) goto out; + /* request completed as part of the update, complete it */ + else if (ret2 == IOU_COMPLETE) + goto complete; } - req_set_fail(preq); io_req_set_res(preq, -ECANCELED, 0); +complete: + if (preq->cqe.res < 0) + req_set_fail(preq); preq->io_task_work.func = io_req_task_complete; io_req_task_work_add(preq); out:

20 minutes

1
0
0 0

[PATCH v5 3/3] KVM: x86: Add x2APIC "features" to control EOI broadcast suppression

by Khushit Shah

Add two flags for KVM_CAP_X2APIC_API to allow userspace to control support for Suppress EOI Broadcasts, which KVM completely mishandles. When x2APIC support was first added, KVM incorrectly advertised and "enabled" Suppress EOI Broadcast, without fully supporting the I/O APIC side of the equation, i.e. without adding directed EOI to KVM's in-kernel I/O APIC. That flaw was carried over to split IRQCHIP support, i.e. KVM advertised support for Suppress EOI Broadcasts irrespective of whether or not the userspace I/O APIC implementation supported directed EOIs. Even worse, KVM didn't actually suppress EOI broadcasts, i.e. userspace VMMs without support for directed EOI came to rely on the "spurious" broadcasts. KVM "fixed" the in-kernel I/O APIC implementation by completely disabling support for Suppress EOI Broadcasts in commit 0bcc3fb95b97 ("KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use"), but didn't do anything to remedy userspace I/O APIC implementations. KVM's bogus handling of Suppress EOI Broadcast is problematic when the guest relies on interrupts being masked in the I/O APIC until well after the initial local APIC EOI. E.g. Windows with Credential Guard enabled handles interrupts in the following order: 1. Interrupt for L2 arrives. 2. L1 APIC EOIs the interrupt. 3. L1 resumes L2 and injects the interrupt. 4. L2 EOIs after servicing. 5. L1 performs the I/O APIC EOI. Because KVM EOIs the I/O APIC at step #2, the guest can get an interrupt storm, e.g. if the IRQ line is still asserted and userspace reacts to the EOI by re-injecting the IRQ, because the guest doesn't de-assert the line until step #4, and doesn't expect the interrupt to be re-enabled until step #5. Unfortunately, simply "fixing" the bug isn't an option, as KVM has no way of knowing if the userspace I/O APIC supports directed EOIs, i.e. suppressing EOI broadcasts would result in interrupts being stuck masked in the userspace I/O APIC due to step #5 being ignored by userspace. And fully disabling support for Suppress EOI Broadcast is also undesirable, as picking up the fix would require a guest reboot, *and* more importantly would change the virtual CPU model exposed to the guest without any buy-in from userspace. Add KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST flags to allow userspace to explicitly enable or disable support for Suppress EOI Broadcasts. This gives userspace control over the virtual CPU model exposed to the guest, as KVM should never have enabled support for Suppress EOI Broadcast without userspace opt-in. Not setting either flag will result in legacy quirky behavior for backward compatibility. When KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST is set and using in-kernel IRQCHIP mode, KVM will use I/O APIC version 0x20, which includes support for the EOI Register. Note, Suppress EOI Broadcasts is defined only in Intel's SDM, not in AMD's APM. But the bit is writable on some AMD CPUs, e.g. Turin, and KVM's ABI is to support Directed EOI (KVM's name) irrespective of guest CPU vendor. Fixes: 7543a635aa09 ("KVM: x86: Add KVM exit for IOAPIC EOIs") Closes: https://lore.kernel.org/kvm/7D497EF1-607D-4D37-98E7-DAF95F099342@nutanix.com Cc: stable(a)vger.kernel.org Suggested-by: David Woodhouse <dwmw2(a)infradead.org> Co-developed-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Khushit Shah <khushit.shah(a)nutanix.com> --- Documentation/virt/kvm/api.rst | 28 +++++++++++++-- arch/x86/include/asm/kvm_host.h | 7 ++++ arch/x86/include/uapi/asm/kvm.h | 6 ++-- arch/x86/kvm/lapic.c | 64 ++++++++++++++++++++++----------- arch/x86/kvm/x86.c | 15 ++++++-- 5 files changed, 93 insertions(+), 27 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 57061fa29e6a..ad15ca519afc 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7800,8 +7800,10 @@ Will return -EBUSY if a VCPU has already been created. Valid feature flags in args[0] are:: - #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) - #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) + #define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) + #define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) + #define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (1ULL << 2) + #define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (1ULL << 3) Enabling KVM_X2APIC_API_USE_32BIT_IDS changes the behavior of KVM_SET_GSI_ROUTING, KVM_SIGNAL_MSI, KVM_SET_LAPIC, and KVM_GET_LAPIC, @@ -7814,6 +7816,28 @@ as a broadcast even in x2APIC mode in order to support physical x2APIC without interrupt remapping. This is undesirable in logical mode, where 0xff represents CPUs 0-7 in cluster 0. +Setting KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST instructs KVM to enable +Suppress EOI Broadcasts. KVM will advertise support for Suppress EOI +Broadcast to the guest and suppress LAPIC EOI broadcasts when the guest +sets the Suppress EOI Broadcast bit in the SPIV register. When using +in-kernel IRQCHIP mode, enabling this capability will cause KVM to use +I/O APIC version 0x20, which includes support for the EOI Register for +directed EOI. + +Setting KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST disables support for +Suppress EOI Broadcasts entirely, i.e. instructs KVM to NOT advertise +support to the guest. + +Modern VMMs should either enable KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST +or KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST. If not, legacy quirky +behavior will be used by KVM: in split IRQCHIP mode, KVM will advertise +support for Suppress EOI Broadcasts but not actually suppress EOI +broadcasts; for in-kernel IRQCHIP mode, KVM will not advertise support for +Suppress EOI Broadcasts. + +Setting both KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST and +KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST will fail with an EINVAL error. + 7.8 KVM_CAP_S390_USER_INSTR0 ---------------------------- diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 48598d017d6f..4a6d94dc7a2a 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1229,6 +1229,12 @@ enum kvm_irqchip_mode { KVM_IRQCHIP_SPLIT, /* created with KVM_CAP_SPLIT_IRQCHIP */ }; +enum kvm_suppress_eoi_broadcast_mode { + KVM_SUPPRESS_EOI_BROADCAST_QUIRKED, /* Legacy behavior */ + KVM_SUPPRESS_EOI_BROADCAST_ENABLED, /* Enable Suppress EOI broadcast */ + KVM_SUPPRESS_EOI_BROADCAST_DISABLED /* Disable Suppress EOI broadcast */ +}; + struct kvm_x86_msr_filter { u8 count; bool default_allow:1; @@ -1480,6 +1486,7 @@ struct kvm_arch { bool x2apic_format; bool x2apic_broadcast_quirk_disabled; + enum kvm_suppress_eoi_broadcast_mode suppress_eoi_broadcast_mode; bool has_mapped_host_mmio; bool guest_can_read_msr_platform_info; diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h index d420c9c066d4..d30241429fa8 100644 --- a/arch/x86/include/uapi/asm/kvm.h +++ b/arch/x86/include/uapi/asm/kvm.h @@ -913,8 +913,10 @@ struct kvm_sev_snp_launch_finish { __u64 pad1[4]; }; -#define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0) -#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1) +#define KVM_X2APIC_API_USE_32BIT_IDS (_BITULL(0)) +#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (_BITULL(1)) +#define KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST (_BITULL(2)) +#define KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST (_BITULL(3)) struct kvm_hyperv_eventfd { __u32 conn_id; diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index 2c24fd8d815f..36a5af218802 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -107,21 +107,31 @@ bool kvm_apic_pending_eoi(struct kvm_vcpu *vcpu, int vector) bool kvm_lapic_advertise_suppress_eoi_broadcast(struct kvm *kvm) { - /* - * The default in-kernel I/O APIC emulates the 82093AA and does not - * implement an EOI register. Some guests (e.g. Windows with the - * Hyper-V role enabled) disable LAPIC EOI broadcast without checking - * the I/O APIC version, which can cause level-triggered interrupts to - * never be EOI'd. - * - * To avoid this, KVM must not advertise Suppress EOI Broadcast support - * when using the default in-kernel I/O APIC. - * - * Historically, in split IRQCHIP mode, KVM always advertised Suppress - * EOI Broadcast support but did not actually suppress EOIs, resulting - * in quirky behavior. - */ - return !ioapic_in_kernel(kvm); + switch (kvm->arch.suppress_eoi_broadcast_mode) { + case KVM_SUPPRESS_EOI_BROADCAST_ENABLED: + return true; + case KVM_SUPPRESS_EOI_BROADCAST_DISABLED: + return false; + case KVM_SUPPRESS_EOI_BROADCAST_QUIRKED: + /* + * The default in-kernel I/O APIC emulates the 82093AA and does not + * implement an EOI register. Some guests (e.g. Windows with the + * Hyper-V role enabled) disable LAPIC EOI broadcast without + * checking the I/O APIC version, which can cause level-triggered + * interrupts to never be EOI'd. + * + * To avoid this, KVM must not advertise Suppress EOI Broadcast + * support when using the default in-kernel I/O APIC. + * + * Historically, in split IRQCHIP mode, KVM always advertised + * Suppress EOI Broadcast support but did not actually suppress + * EOIs, resulting in quirky behavior. + */ + return !ioapic_in_kernel(kvm); + default: + WARN_ON_ONCE(1); + return false; + } } bool kvm_lapic_respect_suppress_eoi_broadcast(struct kvm *kvm) @@ -129,13 +139,25 @@ bool kvm_lapic_respect_suppress_eoi_broadcast(struct kvm *kvm) /* * Returns true if KVM should honor the guest's request to suppress EOI * broadcasts, i.e. actually implement Suppress EOI Broadcast. - * - * Historically, in split IRQCHIP mode, KVM ignored the suppress EOI - * broadcast bit set by the guest and broadcasts EOIs to the userspace - * I/O APIC. For In-kernel I/O APIC, the support itself is not - * advertised, but if bit was set by the guest, it was respected. */ - return ioapic_in_kernel(kvm); + switch (kvm->arch.suppress_eoi_broadcast_mode) { + case KVM_SUPPRESS_EOI_BROADCAST_ENABLED: + return true; + case KVM_SUPPRESS_EOI_BROADCAST_DISABLED: + return false; + case KVM_SUPPRESS_EOI_BROADCAST_QUIRKED: + /* + * Historically, in split IRQCHIP mode, KVM ignored the suppress + * EOI broadcast bit set by the guest and broadcasts EOIs to the + * userspace I/O APIC. For In-kernel I/O APIC, the support itself + * is not advertised, but if bit was set by the guest, it was + * respected. + */ + return ioapic_in_kernel(kvm); + default: + WARN_ON_ONCE(1); + return false; + } } __read_mostly DEFINE_STATIC_KEY_FALSE(kvm_has_noapic_vcpu); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c9c2aa6f4705..5d56b0384dcc 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -121,8 +121,10 @@ static u64 __read_mostly efer_reserved_bits = ~((u64)EFER_SCE); #define KVM_CAP_PMU_VALID_MASK KVM_PMU_CAP_DISABLE -#define KVM_X2APIC_API_VALID_FLAGS (KVM_X2APIC_API_USE_32BIT_IDS | \ - KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK) +#define KVM_X2APIC_API_VALID_FLAGS (KVM_X2APIC_API_USE_32BIT_IDS | \ + KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK | \ + KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST | \ + KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST) static void update_cr8_intercept(struct kvm_vcpu *vcpu); static void process_nmi(struct kvm_vcpu *vcpu); @@ -6778,11 +6780,20 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, if (cap->args[0] & ~KVM_X2APIC_API_VALID_FLAGS) break; + if ((cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) && + (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST)) + break; + if (cap->args[0] & KVM_X2APIC_API_USE_32BIT_IDS) kvm->arch.x2apic_format = true; if (cap->args[0] & KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK) kvm->arch.x2apic_broadcast_quirk_disabled = true; + if (cap->args[0] & KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST) + kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_ENABLED; + if (cap->args[0] & KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST) + kvm->arch.suppress_eoi_broadcast_mode = KVM_SUPPRESS_EOI_BROADCAST_DISABLED; + r = 0; break; case KVM_CAP_X86_DISABLE_EXITS: -- 2.39.3

36 minutes

1
0
0 0

[PATCH v2 0/3] PCI: dwc: Fix missing iATU setup when ECAM is enabled

by Krishna Chaitanya Chundru

When ECAM is enabled, the driver skipped calling dw_pcie_iatu_setup() before configuring ECAM iATU entries. This left IO and MEM outbound windows unprogrammed, resulting in broken IO transactions. Additionally, dw_pcie_config_ecam_iatu() was only called during host initialization, so ECAM-related iATU entries were not restored after suspend/resume, leading to failures in configuration space access. To resolve these issues, the ECAM iATU configuration is moved into dw_pcie_setup_rc(). At the same time, dw_pcie_iatu_setup() is invoked when ECAM is enabled. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru(a)oss.qualcomm.com> --- Changes in v2: - Fixed the index 0 of the ATU window skipping. - Keep the ob_atu_index in dw_pcie instead of dw_pcie_rp & couple of nitpicks (Bjorn). - Link to v1: https://lore.kernel.org/r/20251203-ecam_io_fix-v1-0-5cc3d3769c18@oss.qualco… --- Krishna Chaitanya Chundru (3): PCI: dwc: Fix skipped index 0 in outbound ATU setup PCI: dwc: Correct iATU index increment for MSG TLP region PCI: dwc: Fix missing iATU setup when ECAM is enabled drivers/pci/controller/dwc/pcie-designware-host.c | 53 ++++++++++++++--------- drivers/pci/controller/dwc/pcie-designware.c | 3 ++ drivers/pci/controller/dwc/pcie-designware.h | 2 +- 3 files changed, 37 insertions(+), 21 deletions(-) --- base-commit: 3f9f0252130e7dd60d41be0802bf58f6471c691d change-id: 20251203-ecam_io_fix-6e060fecd3b8 Best regards, -- Krishna Chaitanya Chundru <krishna.chundru(a)oss.qualcomm.com>

1 hour, 11 minutes

1
2
0 0

[PATCH V3 0/2] LoongArch: KVM: fix "unreliable stack" issue

by Xianglai Li

When starting multi-core loongarch virtualization on loongarch physical machine, loading livepatch on the physical machine will cause an error similar to the following: [ 411.686289] livepatch: klp_try_switch_task: CPU 31/KVM:3116 has an unreliable stack The specific test steps are as follows: 1.Start a multi-core virtual machine on a physical machine 2.Enter the following command on the physical machine to turn on the debug switch: echo "file kernel/livepatch/transition.c +p" > /sys/kernel/debug/\ dynamic_debug/control 3.Load livepatch: modprobe livepatch-sample Through the above steps, similar prints can be viewed in dmesg. The reason for this issue is that the code of the kvm_exc_entry function was copied in the function kvm_loongarch_env_init. When the cpu needs to execute kvm_exc_entry, it will switch to the copied address for execution. The new address of the kvm_exc_entry function cannot be recognized in ORC, which eventually leads to the arch_stack_walk_reliable function returning an error and printing an exception message. To solve the above problems, we directly compile the switch.S file into the kernel instead of the module. In this way, the function kvm_exc_entry will no longer need to be copied. changlog: V3<-V2: 1.Replace the EXPORT_SYMBOL macro declaration symbol with the EXPORT_SYMBOL_FOR_KVM macro 2.Add some comments in kvm_enter_guest 3.Place the correct pc address in era 4.Move .p2align after .text V2<-V1: 1.Rollback the modification of function parameter types such as kvm_save_fpu. In the asm-prototypes.h header file, only the parameter types it depends on are included Cc: Huacai Chen <chenhuacai(a)kernel.org> Cc: WANG Xuerui <kernel(a)xen0n.name> Cc: Tianrui Zhao <zhaotianrui(a)loongson.cn> Cc: Bibo Mao <maobibo(a)loongson.cn> Cc: Charlie Jenkins <charlie(a)rivosinc.com> Cc: Xianglai Li <lixianglai(a)loongson.cn> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: Tiezhu Yang <yangtiezhu(a)loongson.cn> Xianglai Li (2): LoongArch: KVM: Compile the switch.S file directly into the kernel LoongArch: KVM: fix "unreliable stack" issue arch/loongarch/Kbuild | 2 +- arch/loongarch/include/asm/asm-prototypes.h | 21 +++++++++++++ arch/loongarch/include/asm/kvm_host.h | 3 -- arch/loongarch/kvm/Makefile | 2 +- arch/loongarch/kvm/main.c | 35 ++------------------- arch/loongarch/kvm/switch.S | 32 ++++++++++++++++--- 6 files changed, 53 insertions(+), 42 deletions(-) base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 -- 2.39.1

1 hour, 12 minutes

5
10
0 0

[PATCH] misc: bcm-vk: validate entry_size before memcpy_fromio()

by Guangshuo Li

The driver trusts the 'num' and 'entry_size' fields read from BAR2 and uses them directly to compute the length for memcpy_fromio() without any bounds checking. If these fields get corrupted or otherwise contain invalid values, num * entry_size can exceed the size of proc_mon_info.entries and lead to a potential out-of-bounds write. Add validation for 'entry_size' by ensuring it is non-zero and that num * entry_size does not exceed the size of proc_mon_info.entries. Fixes: ff428d052b3b ("misc: bcm-vk: add get_card_info, peerlog_info, and proc_mon_info") Cc: stable(a)vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> --- drivers/misc/bcm-vk/bcm_vk_dev.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/misc/bcm-vk/bcm_vk_dev.c b/drivers/misc/bcm-vk/bcm_vk_dev.c index a16b99bdaa13..a4a74c10f02b 100644 --- a/drivers/misc/bcm-vk/bcm_vk_dev.c +++ b/drivers/misc/bcm-vk/bcm_vk_dev.c @@ -439,6 +439,7 @@ static void bcm_vk_get_proc_mon_info(struct bcm_vk *vk) struct device *dev = &vk->pdev->dev; struct bcm_vk_proc_mon_info *mon = &vk->proc_mon_info; u32 num, entry_size, offset, buf_size; + size_t max_bytes; u8 *dst; /* calculate offset which is based on peerlog offset */ @@ -458,6 +459,9 @@ static void bcm_vk_get_proc_mon_info(struct bcm_vk *vk) num, BCM_VK_PROC_MON_MAX); return; } + if (!entry_size || (size_t)num > max_bytes / entry_size) { + return; + } mon->num = num; mon->entry_size = entry_size; -- 2.43.0

1 hour, 20 minutes

3
2
0 0

[PATCH 0/7] arm64: dts: rockchip: Sound fixes and additions on RK3576 boards

by Alexey Charkov

Here are some device tree updates to improve sound output on RK3576 boards. The first two patches fix analog audio output on FriendlyElec NanoPi M5, as it doesn't work with the current device tree. The third one is purely cosmetic, to present a more user-friendly sound card name to the userspace on NanoPi M5. The rest add new functionality: HDMI sound output on three boards that didn't enable it, and analog sound on RK3576 EVB1. Signed-off-by: Alexey Charkov <alchark(a)gmail.com> --- Alexey Charkov (7): arm64: dts: rockchip: Fix headphones widget name on NanoPi M5 arm64: dts: rockchip: Configure MCLK for analog sound on NanoPi M5 arm64: dts: rockchip: Use a readable audio card name on NanoPi M5 arm64: dts: rockchip: Enable HDMI sound on FriendlyElec NanoPi M5 arm64: dts: rockchip: Enable HDMI sound on Luckfox Core3576 arm64: dts: rockchip: Enable HDMI sound on RK3576 EVB1 arm64: dts: rockchip: Enable analog sound on RK3576 EVB1 arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 107 +++++++++++++++++++++ .../boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 8 ++ arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 22 ++++- 3 files changed, 132 insertions(+), 5 deletions(-) --- base-commit: cc3aa43b44bdb43dfbac0fcb51c56594a11338a8 change-id: 20251222-rk3576-sound-0c26e3b16924 Best regards, -- Alexey Charkov <alchark(a)gmail.com>

1 hour, 42 minutes

1
2
0 0

[PATCH] arm64: dts: imx95: correct I3C2 pclk to IMX95_CLK_BUSWAKEUP

by Carlos Song

I3C2 is in WAKEUP domain. Its pclk should be IMX95_CLK_BUSWAKEUP. Fixes: 969497ebefcf ("arm64: dts: imx95: Add i3c1 and i3c2") Signed-off-by: Carlos Song <carlos.song(a)nxp.com> Cc: <stable(a)vger.kernel.org> --- arch/arm64/boot/dts/freescale/imx95.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi index e45014d50abe..a4d854817559 100644 --- a/arch/arm64/boot/dts/freescale/imx95.dtsi +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi @@ -828,7 +828,7 @@ i3c2: i3c@42520000 { interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>; #address-cells = <3>; #size-cells = <0>; - clocks = <&scmi_clk IMX95_CLK_BUSAON>, + clocks = <&scmi_clk IMX95_CLK_BUSWAKEUP>, <&scmi_clk IMX95_CLK_I3C2SLOW>; clock-names = "pclk", "fast_clk"; status = "disabled"; -- 2.34.1

3 hours, 23 minutes

3
2
0 0

[PATCH v2 3/3] x86/kexec: Add a sanity check on previous kernel's ima kexec buffer

by Harshit Mogalapalli

When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page Other architectures already validate the range with page_is_ram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86. Without carrying the measurement list across kexec, the attestation would fail. Cc: stable(a)vger.kernel.org Fixes: b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") Reported-by: Paul Webb <paul.x.webb(a)oracle.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- V1-> V2: Added a line about carrying measure list across kexec based on suggestion from Mimi Zohar. Made use to the new generic helper [Suggestion from Borislav] --- arch/x86/kernel/setup.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 1b2edd07a3e1..383d4a4784f5 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -439,9 +439,15 @@ int __init ima_free_kexec_buffer(void) int __init ima_get_kexec_buffer(void **addr, size_t *size) { + int ret; + if (!ima_kexec_buffer_size) return -ENOENT; + ret = ima_validate_range(ima_kexec_buffer_phys, ima_kexec_buffer_size); + if (ret) + return ret; + *addr = __va(ima_kexec_buffer_phys); *size = ima_kexec_buffer_size; -- 2.50.1

3 hours, 38 minutes

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror