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

[PATCH] rust: kbuild: skip gendwarfksyms in `bindings.o` for Rust >= 1.91.0

by Miguel Ojeda

Starting with Rust 1.91.0 (released 2025-10-30), in upstream commit ab91a63d403b ("Ignore intrinsic calls in cross-crate-inlining cost model") [1][2], `bindings.o` stops containing DWARF debug information because the `Default` implementations contained `write_bytes()` calls which are now ignored in that cost model (note that `CLIPPY=1` does not reproduce it). This means `gendwarfksyms` complains: RUSTC L rust/bindings.o error: gendwarfksyms: process_module: dwarf_get_units failed: no debugging information? For the moment, conditionally skip `gendwarfksyms` for Rust >= 1.91.0. Cc: stable(a)vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Reported-by: Haiyue Wang <haiyuewa(a)163.com> Closes: https://lore.kernel.org/rust-for-linux/b8c1c73d-bf8b-4bf2-beb1-84ffdcd60547… Link: https://github.com/rust-lang/rust/commit/ab91a63d403b0105cacd72809cd292a729… [1] Link: https://github.com/rust-lang/rust/pull/145910 [2] Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- rust/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/rust/Makefile b/rust/Makefile index 3e545c1a0ff4..269bf7cf5b97 100644 --- a/rust/Makefile +++ b/rust/Makefile @@ -543,6 +543,7 @@ $(obj)/ffi.o: private skip_gendwarfksyms = 1 $(obj)/ffi.o: $(src)/ffi.rs $(obj)/compiler_builtins.o FORCE +$(call if_changed_rule,rustc_library) +$(obj)/bindings.o: private skip_gendwarfksyms := $(if $(call rustc-min-version,109100),1) $(obj)/bindings.o: private rustc_target_flags = --extern ffi --extern pin_init $(obj)/bindings.o: $(src)/bindings/lib.rs \ $(obj)/ffi.o \ base-commit: dc77806cf3b4788d328fddf245e86c5b529f31a2 -- 2.51.2

1 week, 1 day

3
3
0 0

[PATCH net v2] strparser: Fix signed/unsigned mismatch bug

by Nate Karstens

The `len` member of the sk_buff is an unsigned int. This is cast to `ssize_t` (a signed type) for the first sk_buff in the comparison, but not the second sk_buff. On 32-bit systems, this can result in an integer underflow for certain values because unsigned arithmetic is being used. This appears to be an oversight: if the intention was to use unsigned arithmetic, then the first cast would have been omitted. The change ensures both len values are cast to `ssize_t`. The underflow causes an issue with ktls when multiple TLS PDUs are included in a single TCP segment. The mainline kernel does not use strparser for ktls anymore, but this is still useful for other features that still use strparser, and for backporting. Signed-off-by: Nate Karstens <nate.karstens(a)garmin.com> Cc: stable(a)vger.kernel.org Fixes: 43a0c6751a32 ("strparser: Stream parser for messages") --- net/strparser/strparser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/strparser/strparser.c b/net/strparser/strparser.c index 43b1f558b33d..e659fea2da70 100644 --- a/net/strparser/strparser.c +++ b/net/strparser/strparser.c @@ -238,7 +238,7 @@ static int __strp_recv(read_descriptor_t *desc, struct sk_buff *orig_skb, strp_parser_err(strp, -EMSGSIZE, desc); break; } else if (len <= (ssize_t)head->len - - skb->len - stm->strp.offset) { + (ssize_t)skb->len - stm->strp.offset) { /* Length must be into new skb (and also * greater than zero) */ -- 2.34.1

1 week, 1 day

4
3
0 0

[PATCH] fsi: Fix device refcount leak in i2cr_scom_probe

by Ma Ke

This patch fixes a device reference count leak in the i2cr_scom driver by adding proper put_device() calls in both error paths and the remove function. Found by code review. Cc: stable(a)vger.kernel.org Fixes: c0b34bed0bbf ("fsi: Add I2C Responder SCOM driver") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/fsi/i2cr-scom.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/fsi/i2cr-scom.c b/drivers/fsi/i2cr-scom.c index cb7e02213032..11506d321d7e 100644 --- a/drivers/fsi/i2cr-scom.c +++ b/drivers/fsi/i2cr-scom.c @@ -104,14 +104,20 @@ static int i2cr_scom_probe(struct device *dev) ret = fsi_get_new_minor(fsi_dev, fsi_dev_scom, &scom->dev.devt, &didx); if (ret) - return ret; + goto err_put_device; dev_set_name(&scom->dev, "scom%d", didx); cdev_init(&scom->cdev, &i2cr_scom_fops); ret = cdev_device_add(&scom->cdev, &scom->dev); if (ret) - fsi_free_minor(scom->dev.devt); + goto err_free_minor; + + return ret; +err_free_minor: + fsi_free_minor(scom->dev.devt); +err_put_device: + put_device(&scom->dev); return ret; } -- 2.17.1

1 week, 1 day

3
2
0 0

[PATCH 3/6] KVM: nSVM: Fix and simplify LBR virtualization handling with nested

by Yosry Ahmed

The current scheme for handling LBRV when nested is used is very complicated, especially when L1 does not enable LBRV (i.e. does not set LBR_CTL_ENABLE_MASK). To avoid copying LBRs between VMCB01 and VMCB02 on every nested transition, the current implementation switches between using VMCB01 or VMCB02 as the source of truth for the LBRs while L2 is running. If L2 enables LBR, VMCB02 is used as the source of truth. When L2 disables LBR, the LBRs are copied to VMCB01 and VMCB01 is used as the source of truth. This introduces significant complexity, and incorrect behavior in some cases. For example, on a nested #VMEXIT, the LBRs are only copied from VMCB02 to VMCB01 if LBRV is enabled in VMCB01. This is because L2's writes to MSR_IA32_DEBUGCTLMSR to enable LBR are intercepted and propagated to VMCB01 instead of VMCB02. However, LBRV is only enabled in VMCB02 when L2 is running. This means that if L2 enables LBR and exits to L1, the LBRs will not be propagated from VMCB02 to VMCB01, because LBRV is disabled in VMCB01. There is no meaningful difference in CPUID rate in L2 when copying LBRs on every nested transition vs. the current approach, so do the simple and correct thing and always copy LBRs between VMCB01 and VMCB02 on nested transitions (when LBRV is disabled by L1). Drop the conditional LBRs copying in __svm_{enable/disable}_lbrv() as it is now unnecessary. VMCB02 becomes the only source of truth for LBRs when L2 is running, regardless of LBRV being enabled by L1, drop svm_get_lbr_vmcb() and use svm->vmcb directly in its place. Fixes: 1d5a1b5860ed ("KVM: x86: nSVM: correctly virtualize LBR msrs when L2 is running") Cc: stable(a)vger.kernel.org Signed-off-by: Yosry Ahmed <yosry.ahmed(a)linux.dev> --- arch/x86/kvm/svm/nested.c | 20 ++++++----------- arch/x86/kvm/svm/svm.c | 46 +++++++++------------------------------ 2 files changed, 17 insertions(+), 49 deletions(-) diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index 71664d54d8b2a..c81005b245222 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -678,11 +678,10 @@ static void nested_vmcb02_prepare_save(struct vcpu_svm *svm, struct vmcb *vmcb12 */ svm_copy_lbrs(vmcb02, vmcb12); vmcb02->save.dbgctl &= ~DEBUGCTL_RESERVED_BITS; - svm_update_lbrv(&svm->vcpu); - - } else if (unlikely(vmcb01->control.virt_ext & LBR_CTL_ENABLE_MASK)) { + } else { svm_copy_lbrs(vmcb02, vmcb01); } + svm_update_lbrv(&svm->vcpu); } static inline bool is_evtinj_soft(u32 evtinj) @@ -835,11 +834,7 @@ static void nested_vmcb02_prepare_control(struct vcpu_svm *svm, svm->soft_int_next_rip = vmcb12_rip; } - vmcb02->control.virt_ext = vmcb01->control.virt_ext & - LBR_CTL_ENABLE_MASK; - if (guest_cpu_cap_has(vcpu, X86_FEATURE_LBRV)) - vmcb02->control.virt_ext |= - (svm->nested.ctl.virt_ext & LBR_CTL_ENABLE_MASK); + /* LBR_CTL_ENABLE_MASK is controlled by svm_update_lbrv() */ if (!nested_vmcb_needs_vls_intercept(svm)) vmcb02->control.virt_ext |= VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK; @@ -1191,13 +1186,12 @@ int nested_svm_vmexit(struct vcpu_svm *svm) kvm_make_request(KVM_REQ_EVENT, &svm->vcpu); if (unlikely(guest_cpu_cap_has(vcpu, X86_FEATURE_LBRV) && - (svm->nested.ctl.virt_ext & LBR_CTL_ENABLE_MASK))) { + (svm->nested.ctl.virt_ext & LBR_CTL_ENABLE_MASK))) svm_copy_lbrs(vmcb12, vmcb02); - svm_update_lbrv(vcpu); - } else if (unlikely(vmcb01->control.virt_ext & LBR_CTL_ENABLE_MASK)) { + else svm_copy_lbrs(vmcb01, vmcb02); - svm_update_lbrv(vcpu); - } + + svm_update_lbrv(vcpu); if (vnmi) { if (vmcb02->control.int_ctl & V_NMI_BLOCKING_MASK) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 26ab75ecf1c67..fc42bcdbb5200 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -808,13 +808,7 @@ void svm_copy_lbrs(struct vmcb *to_vmcb, struct vmcb *from_vmcb) static void __svm_enable_lbrv(struct kvm_vcpu *vcpu) { - struct vcpu_svm *svm = to_svm(vcpu); - - svm->vmcb->control.virt_ext |= LBR_CTL_ENABLE_MASK; - - /* Move the LBR msrs to the vmcb02 so that the guest can see them. */ - if (is_guest_mode(vcpu)) - svm_copy_lbrs(svm->vmcb, svm->vmcb01.ptr); + to_svm(vcpu)->vmcb->control.virt_ext |= LBR_CTL_ENABLE_MASK; } void svm_enable_lbrv(struct kvm_vcpu *vcpu) @@ -825,35 +819,15 @@ void svm_enable_lbrv(struct kvm_vcpu *vcpu) static void __svm_disable_lbrv(struct kvm_vcpu *vcpu) { - struct vcpu_svm *svm = to_svm(vcpu); - KVM_BUG_ON(sev_es_guest(vcpu->kvm), vcpu->kvm); - svm->vmcb->control.virt_ext &= ~LBR_CTL_ENABLE_MASK; - - /* - * Move the LBR msrs back to the vmcb01 to avoid copying them - * on nested guest entries. - */ - if (is_guest_mode(vcpu)) - svm_copy_lbrs(svm->vmcb01.ptr, svm->vmcb); -} - -static struct vmcb *svm_get_lbr_vmcb(struct vcpu_svm *svm) -{ - /* - * If LBR virtualization is disabled, the LBR MSRs are always kept in - * vmcb01. If LBR virtualization is enabled and L1 is running VMs of - * its own, the MSRs are moved between vmcb01 and vmcb02 as needed. - */ - return svm->vmcb->control.virt_ext & LBR_CTL_ENABLE_MASK ? svm->vmcb : - svm->vmcb01.ptr; + to_svm(vcpu)->vmcb->control.virt_ext &= ~LBR_CTL_ENABLE_MASK; } void svm_update_lbrv(struct kvm_vcpu *vcpu) { struct vcpu_svm *svm = to_svm(vcpu); bool current_enable_lbrv = svm->vmcb->control.virt_ext & LBR_CTL_ENABLE_MASK; - bool enable_lbrv = (svm_get_lbr_vmcb(svm)->save.dbgctl & DEBUGCTLMSR_LBR) || + bool enable_lbrv = (svm->vmcb->save.dbgctl & DEBUGCTLMSR_LBR) || (is_guest_mode(vcpu) && guest_cpu_cap_has(vcpu, X86_FEATURE_LBRV) && (svm->nested.ctl.virt_ext & LBR_CTL_ENABLE_MASK)); @@ -2738,19 +2712,19 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info) msr_info->data = svm->tsc_aux; break; case MSR_IA32_DEBUGCTLMSR: - msr_info->data = svm_get_lbr_vmcb(svm)->save.dbgctl; + msr_info->data = svm->vmcb->save.dbgctl; break; case MSR_IA32_LASTBRANCHFROMIP: - msr_info->data = svm_get_lbr_vmcb(svm)->save.br_from; + msr_info->data = svm->vmcb->save.br_from; break; case MSR_IA32_LASTBRANCHTOIP: - msr_info->data = svm_get_lbr_vmcb(svm)->save.br_to; + msr_info->data = svm->vmcb->save.br_to; break; case MSR_IA32_LASTINTFROMIP: - msr_info->data = svm_get_lbr_vmcb(svm)->save.last_excp_from; + msr_info->data = svm->vmcb->save.last_excp_from; break; case MSR_IA32_LASTINTTOIP: - msr_info->data = svm_get_lbr_vmcb(svm)->save.last_excp_to; + msr_info->data = svm->vmcb->save.last_excp_to; break; case MSR_VM_HSAVE_PA: msr_info->data = svm->nested.hsave_msr; @@ -3018,10 +2992,10 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr) if (data & DEBUGCTL_RESERVED_BITS) return 1; - if (svm_get_lbr_vmcb(svm)->save.dbgctl == data) + if (svm->vmcb->save.dbgctl == data) break; - svm_get_lbr_vmcb(svm)->save.dbgctl = data; + svm->vmcb->save.dbgctl = data; vmcb_mark_dirty(svm->vmcb, VMCB_LBR); svm_update_lbrv(vcpu); break; -- 2.51.2.1041.gc1ab5b90ca-goog

1 week, 1 day

1
0
0 0

+ kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kernel/kexec: fix IMA when allocation happens in CMA area has been added to the -mm mm-hotfixes-unstable branch. Its filename is kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Pingfan Liu <piliu(a)redhat.com> Subject: kernel/kexec: fix IMA when allocation happens in CMA area Date: Thu, 6 Nov 2025 14:59:04 +0800 When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- This is caused by the fact that kexec allocates the destination directly in the CMA area. In that case, the CMA kernel address should be exported directly to the IMA component, instead of using the vmalloc'd address. Link: https://lkml.kernel.org/r/20251106065904.10772-2-piliu@redhat.com Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") Signed-off-by: Pingfan Liu <piliu(a)redhat.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Alexander Graf <graf(a)amazon.com> Cc: Steven Chen <chenste(a)linux.microsoft.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/kexec_core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/kernel/kexec_core.c~kernel-kexec-fix-ima-when-allocation-happens-in-cma-area +++ a/kernel/kexec_core.c @@ -967,6 +967,7 @@ void *kimage_map_segment(struct kimage * kimage_entry_t *ptr, entry; struct page **src_pages; unsigned int npages; + struct page *cma; void *vaddr = NULL; int i; @@ -974,6 +975,9 @@ void *kimage_map_segment(struct kimage * size = image->segment[idx].memsz; eaddr = addr + size; + cma = image->segment_cma[idx]; + if (cma) + return page_address(cma); /* * Collect the source pages and map them in a contiguous VA range. */ @@ -1014,7 +1018,8 @@ void *kimage_map_segment(struct kimage * void kimage_unmap_segment(void *segment_buffer) { - vunmap(segment_buffer); + if (is_vmalloc_addr(segment_buffer)) + vunmap(segment_buffer); } struct kexec_load_limit { _ Patches currently in -mm which might be from piliu(a)redhat.com are kernel-kexec-change-the-prototype-of-kimage_map_segment.patch kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch

1 week, 1 day

1
0
0 0

+ kernel-kexec-change-the-prototype-of-kimage_map_segment.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kernel/kexec: change the prototype of kimage_map_segment() has been added to the -mm mm-hotfixes-unstable branch. Its filename is kernel-kexec-change-the-prototype-of-kimage_map_segment.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Pingfan Liu <piliu(a)redhat.com> Subject: kernel/kexec: change the prototype of kimage_map_segment() Date: Thu, 6 Nov 2025 14:59:03 +0800 The kexec segment index will be required to extract the corresponding information for that segment in kimage_map_segment(). Additionally, kexec_segment already holds the kexec relocation destination address and size. Therefore, the prototype of kimage_map_segment() can be changed. Link: https://lkml.kernel.org/r/20251106065904.10772-1-piliu@redhat.com Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") Signed-off-by: Pingfan Liu <piliu(a)redhat.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Mimi Zohar <zohar(a)linux.ibm.com> Cc: Roberto Sassu <roberto.sassu(a)huawei.com> Cc: Alexander Graf <graf(a)amazon.com> Cc: Steven Chen <chenste(a)linux.microsoft.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/kexec.h | 4 ++-- kernel/kexec_core.c | 9 ++++++--- security/integrity/ima/ima_kexec.c | 4 +--- 3 files changed, 9 insertions(+), 8 deletions(-) --- a/include/linux/kexec.h~kernel-kexec-change-the-prototype-of-kimage_map_segment +++ a/include/linux/kexec.h @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print; #define kexec_dprintk(fmt, arg...) \ do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0) -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size); +extern void *kimage_map_segment(struct kimage *image, int idx); extern void kimage_unmap_segment(void *buffer); #else /* !CONFIG_KEXEC_CORE */ struct pt_regs; @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct static inline void crash_kexec(struct pt_regs *regs) { } static inline int kexec_should_crash(struct task_struct *p) { return 0; } static inline int kexec_crash_loaded(void) { return 0; } -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size) +static inline void *kimage_map_segment(struct kimage *image, int idx) { return NULL; } static inline void kimage_unmap_segment(void *buffer) { } #define kexec_in_progress false --- a/kernel/kexec_core.c~kernel-kexec-change-the-prototype-of-kimage_map_segment +++ a/kernel/kexec_core.c @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *i return result; } -void *kimage_map_segment(struct kimage *image, - unsigned long addr, unsigned long size) +void *kimage_map_segment(struct kimage *image, int idx) { + unsigned long addr, size, eaddr; unsigned long src_page_addr, dest_page_addr = 0; - unsigned long eaddr = addr + size; kimage_entry_t *ptr, entry; struct page **src_pages; unsigned int npages; void *vaddr = NULL; int i; + addr = image->segment[idx].mem; + size = image->segment[idx].memsz; + eaddr = addr + size; + /* * Collect the source pages and map them in a contiguous VA range. */ --- a/security/integrity/ima/ima_kexec.c~kernel-kexec-change-the-prototype-of-kimage_map_segment +++ a/security/integrity/ima/ima_kexec.c @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage * if (!image->ima_buffer_addr) return; - ima_kexec_buffer = kimage_map_segment(image, - image->ima_buffer_addr, - image->ima_buffer_size); + ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index); if (!ima_kexec_buffer) { pr_err("Could not map measurements buffer.\n"); return; _ Patches currently in -mm which might be from piliu(a)redhat.com are kernel-kexec-change-the-prototype-of-kimage_map_segment.patch kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch

1 week, 1 day

1
0
0 0

[PATCH v2] x86/amd: Disable RDSEED on AMD Zen5 because of an error.

by Gregory Price

Under unknown conditions, Zen5 chips running rdseed can produce (val=0,CF=1) over 10% of the time (when rdseed is successful). CF=1 indicates success, while val=0 is typically only produced when rdseed fails (CF=0). This suggests there is a bug which causes rdseed to silently fail. This was reproduced reliably by launching 2-threads per available core, 1-thread per for hamming on RDSEED, and 1-thread per core collectively eating and hammering on ~90% of memory. This was observed on more than 1 Zen5 model, so it should be disabled for all of Zen5 until/unless a comprehensive blacklist can be built. Cc: stable(a)vger.kernel.org Signed-off-by: Gregory Price <gourry(a)gourry.net> --- arch/x86/kernel/cpu/amd.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 5398db4dedb4..1af30518d3e7 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -1037,6 +1037,10 @@ static void init_amd_zen4(struct cpuinfo_x86 *c) static void init_amd_zen5(struct cpuinfo_x86 *c) { + /* Disable RDSEED on AMD Turin because of an error. */ + clear_cpu_cap(c, X86_FEATURE_RDSEED); + msr_clear_bit(MSR_AMD64_CPUID_FN_7, 18); + pr_emerg("RDSEED is not reliable on this platform; disabling.\n"); } static void init_amd(struct cpuinfo_x86 *c) -- 2.51.0

1 week, 1 day

5
20
0 0

Export Inquiry from Ledcor Group

by Phillip Davies

Hello , My name is Mr. Phillip Davies, representing Ledcor Group. I came across your website and was impressed by the quality of the products you offer, which we believe could meet the needs of our customers. We would like to inquire if your company is able to export to Europe and the United States (US). We look forward to your response. Best regards, Mr. Phillip Davies Ledcor Group

1 week, 1 day

1
0
0 0

[PATCH v2 2/2] media: mxl111sf: fix i2c race condition during device probe

by Nalivayko Sergey

syzbot reports a KASAN issue as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf] CPU: 1 UID: 0 PID: 5849 Comm: syz-executor279 Not tainted 6.15.0-rc2-syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:580 [inline] RIP: 0010:__mutex_lock+0x15d/0x10c0 kernel/locking/mutex.c:746 Call Trace: <TASK> dvb_usbv2_generic_write+0x26/0x50 mxl111sf_ctrl_msg+0x172/0x2e0 mxl111sf_write_reg+0xda/0x1f0 mxl111sf_i2c_start mxl111sf_i2c_sw_xfer_msg mxl111sf_i2c_xfer+0x923/0x8aa0 __i2c_transfer+0x859/0x2250 i2c_transfer+0x2c2/0x430 i2c_transfer_buffer_flags+0x182/0x260 i2c_master_recv i2cdev_read+0x10a/0x220 vfs_read+0x21f/0xb90 ksys_read+0x19d/0x2d0 do_syscall_x64 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> This occurs due to a race condition during DVB-USB-V2 device initialization. While initialization is in progress, I2C data may be read from userspace, leading to a NULL pointer dereference in dvb_usbv2_generic_write and a kernel panic. Thread 1 (probe device) Thread 2 (receive i2c data) ... dvb_usbv2_probe() ... d->priv = kzalloc( d->props->size_of_priv, GFP_KERNEL); ... dvb_usbv2_init() ... // can read data from i2c dvb_usbv2_i2c_init() ... ... i2cdev_read() ... // d->priv data is invalid. UB mxl111sf_i2c_xfer() ... mxl111sf_ctrl_msg() ... // null ptr deref dvb_usbv2_generic_write() ... ... // d->priv data is valid dvb_usbv2_adapter_init() ... Add init_ready flag check to prevent I/O on uninitialized DVB-USB-V2 device. Reported-by: syzbot+f9f5333782a854509322(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f9f5333782a854509322 Fixes: 4c66c9205c07 ("[media] dvb-usb: add ATSC support for the Hauppauge WinTV-Aero-M") Cc: stable(a)vger.kernel.org Signed-off-by: Nalivayko Sergey <Sergey.Nalivayko(a)kaspersky.com> --- drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c b/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c index 100a1052dcbc..b7bad90b16dc 100644 --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c @@ -804,7 +804,7 @@ int mxl111sf_i2c_xfer(struct i2c_adapter *adap, int hwi2c = (state->chip_rev > MXL111SF_V6); int i, ret; - if (mutex_lock_interruptible(&d->i2c_mutex) < 0) + if (!atomic_read(&d->init_ready) || mutex_lock_interruptible(&d->i2c_mutex) < 0) return -EAGAIN; for (i = 0; i < num; i++) { -- 2.39.5

1 week, 1 day

1
0
0 0

[PATCH 2/3] xhci: dbgtty: Fix data corruption when transmitting data form DbC to host

by Mathias Nyman

Data read from a DbC device may be corrupted due to a race between ongoing write and write request completion handler both queuing new transfer blocks (TRBs) if there are remining data in the kfifo. TRBs may be in incorrct order compared to the data in the kfifo. Driver fails to keep lock between reading data from kfifo into a dbc request buffer, and queuing the request to the transfer ring. This allows completed request to re-queue itself in the middle of an ongoing transfer loop, forcing itself between a kfifo read and request TRB write of another request cpu0 cpu1 (re-queue completed req2) lock(port_lock) dbc_start_tx() kfifo_out(fifo, req1->buffer) unlock(port_lock) lock(port_lock) dbc_write_complete(req2) dbc_start_tx() kfifo_out(fifo, req2->buffer) unlock(port_lock) lock(port_lock) req2->trb = ring->enqueue; ring->enqueue++ unlock(port_lock) lock(port_lock) req1->trb = ring->enqueue; ring->enqueue++ unlock(port_lock) In the above scenario a kfifo containing "12345678" would read "1234" to req1 and "5678" to req2, but req2 is queued before req1 leading to data being transmitted as "56781234" Solve this by adding a flag that prevents starting a new tx if we are already mid dbc_start_tx() during the unlocked part. The already running dbc_do_start_tx() will make sure the newly completed request gets re-queued as it is added to the request write_pool while holding the lock. Cc: stable(a)vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-dbgcap.h | 1 + drivers/usb/host/xhci-dbgtty.c | 17 ++++++++++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-dbgcap.h b/drivers/usb/host/xhci-dbgcap.h index 47ac72c2286d..5426c971d2d3 100644 --- a/drivers/usb/host/xhci-dbgcap.h +++ b/drivers/usb/host/xhci-dbgcap.h @@ -114,6 +114,7 @@ struct dbc_port { unsigned int tx_boundary; bool registered; + bool tx_running; }; struct dbc_driver { diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index d894081d8d15..b7f95565524d 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -47,7 +47,7 @@ dbc_kfifo_to_req(struct dbc_port *port, char *packet) return len; } -static int dbc_start_tx(struct dbc_port *port) +static int dbc_do_start_tx(struct dbc_port *port) __releases(&port->port_lock) __acquires(&port->port_lock) { @@ -57,6 +57,8 @@ static int dbc_start_tx(struct dbc_port *port) bool do_tty_wake = false; struct list_head *pool = &port->write_pool; + port->tx_running = true; + while (!list_empty(pool)) { req = list_entry(pool->next, struct dbc_request, list_pool); len = dbc_kfifo_to_req(port, req->buf); @@ -77,12 +79,25 @@ static int dbc_start_tx(struct dbc_port *port) } } + port->tx_running = false; + if (do_tty_wake && port->port.tty) tty_wakeup(port->port.tty); return status; } +/* must be called with port->port_lock held */ +static int dbc_start_tx(struct dbc_port *port) +{ + lockdep_assert_held(&port->port_lock); + + if (port->tx_running) + return -EBUSY; + + return dbc_do_start_tx(port); +} + static void dbc_start_rx(struct dbc_port *port) __releases(&port->port_lock) __acquires(&port->port_lock) -- 2.43.0

1 week, 1 day

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror