May 2025 - Linux-stable-mirror

[PATCH v2 1/1] Drivers: hv: Always select CONFIG_SYSFB for Hyper-V guests

by mhkelley58＠gmail.com

From: Michael Kelley <mhklinux(a)outlook.com> The Hyper-V host provides guest VMs with a range of MMIO addresses that guest VMBus drivers can use. The VMBus driver in Linux manages that MMIO space, and allocates portions to drivers upon request. As part of managing that MMIO space in a Generation 2 VM, the VMBus driver must reserve the portion of the MMIO space that Hyper-V has designated for the synthetic frame buffer, and not allocate this space to VMBus drivers other than graphics framebuffer drivers. The synthetic frame buffer MMIO area is described by the screen_info data structure that is passed to the Linux kernel at boot time, so the VMBus driver must access screen_info for Generation 2 VMs. (In Generation 1 VMs, the framebuffer MMIO space is communicated to the guest via a PCI pseudo-device, and access to screen_info is not needed.) In commit a07b50d80ab6 ("hyperv: avoid dependency on screen_info") the VMBus driver's access to screen_info is restricted to when CONFIG_SYSFB is enabled. CONFIG_SYSFB is typically enabled in kernels built for Hyper-V by virtue of having at least one of CONFIG_FB_EFI, CONFIG_FB_VESA, or CONFIG_SYSFB_SIMPLEFB enabled, so the restriction doesn't usually affect anything. But it's valid to have none of these enabled, in which case CONFIG_SYSFB is not enabled, and the VMBus driver is unable to properly reserve the framebuffer MMIO space for graphics framebuffer drivers. The framebuffer MMIO space may be assigned to some other VMBus driver, with undefined results. As an example, if a VM is using a PCI pass-thru NVMe controller to host the OS disk, the PCI NVMe controller is probed before any graphics devices, and the NVMe controller is assigned a portion of the framebuffer MMIO space. Hyper-V reports an error to Linux during the probe, and the OS disk fails to get setup. Then Linux fails to boot in the VM. Fix this by having CONFIG_HYPERV always select SYSFB. Then the VMBus driver in a Gen 2 VM can always reserve the MMIO space for the graphics framebuffer driver, and prevent the undefined behavior. But don't select SYSFB when building for HYPERV_VTL_MODE as VTLs other than VTL 0 don't have a framebuffer and aren't subject to the issue. Adding SYSFB in such cases is harmless, but would increase the image size for no purpose. Fixes: a07b50d80ab6 ("hyperv: avoid dependency on screen_info") Signed-off-by: Michael Kelley <mhklinux(a)outlook.com> Reviewed-by: Saurabh Sengar <ssengar(a)linux.microsoft.com> --- Changes in v2: * Made "select SYSFB" conditional on not being a build for VTL mode (Saurabh Sengar) drivers/hv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig index eefa0b559b73..1cd188b73b74 100644 --- a/drivers/hv/Kconfig +++ b/drivers/hv/Kconfig @@ -9,6 +9,7 @@ config HYPERV select PARAVIRT select X86_HV_CALLBACK_VECTOR if X86 select OF_EARLY_FLATTREE if OF + select SYSFB if !HYPERV_VTL_MODE help Select this option to run Linux as a Hyper-V client operating system. -- 2.25.1

5 months, 2 weeks

3
2
0 0

Investment Help

by Calib Cassim

Good Day, How are you? My name is Calib Cassim from Eskom Holdings Ltd. SA. I got your email from my personal search. I have in my position an (over-invoice / over-estimated) contract amount executed by a Foreign Contractor through my Department, which the contractor has been paid, and left the remaining amount of $25.5M with the payment Management. So, I need your help to receive the amount on my behalf as a Co-contractor, I will obtain all the needed legal documents for the transfer to you for an investment in your area. If you can handle it, please reply with your phone number for more discussions and guidelines. Thanks, Mr. Calib

5 months, 2 weeks

1
0
0 0

[PATCH] firmware: cs_dsp: Fix OOB memory read access in KUnit test

by Jaroslav Kysela

KASAN reported out of bounds access - cs_dsp_mock_bin_add_name_or_info(), because the source string length was rounded up to the allocation size. Cc: Simon Trimmer <simont(a)opensource.cirrus.com> Cc: Charles Keepax <ckeepax(a)opensource.cirrus.com> Cc: Richard Fitzgerald <rf(a)opensource.cirrus.com> Cc: patches(a)opensource.cirrus.com Cc: stable(a)vger.kernel.org Signed-off-by: Jaroslav Kysela <perex(a)perex.cz> --- drivers/firmware/cirrus/test/cs_dsp_mock_bin.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/cirrus/test/cs_dsp_mock_bin.c b/drivers/firmware/cirrus/test/cs_dsp_mock_bin.c index 49d84f7e59e6..a0601b23b1bd 100644 --- a/drivers/firmware/cirrus/test/cs_dsp_mock_bin.c +++ b/drivers/firmware/cirrus/test/cs_dsp_mock_bin.c @@ -96,10 +96,11 @@ static void cs_dsp_mock_bin_add_name_or_info(struct cs_dsp_mock_bin_builder *bui if (info_len % 4) { /* Create a padded string with length a multiple of 4 */ + size_t copy_len = info_len; info_len = round_up(info_len, 4); tmp = kunit_kzalloc(builder->test_priv->test, info_len, GFP_KERNEL); KUNIT_ASSERT_NOT_ERR_OR_NULL(builder->test_priv->test, tmp); - memcpy(tmp, info, info_len); + memcpy(tmp, info, copy_len); info = tmp; } -- 2.49.0

5 months, 2 weeks

3
2
0 0

[PATCH V2] hfsplus: Return null terminated string from hfsplus_uni2asc()

by Aaro Mäkinen

In case hfsplus_uni2asc() is called with reused buffer there is a possibility that the buffer contains remains of the last string and the null character is only after that. This can and has caused problems in functions that call hfsplus_uni2asc(). Also correct the error handling for call to copy_name() where the above problem caused error to be not passed in hfsplus_listxattr(). Fixes: 7dcbf17e3f91 ("hfsplus: refactor copy_name to not use strncpy") Cc: stable(a)vger.kernel.org Cc: linux-fsdevel(a)vger.kernel.org Signed-off-by: Aaro Mäkinen <aaro(a)tuxera.com> Reviewed-by: Anton Altaparmakov <anton(a)tuxera.com> --- Changes in v2: - Add Cc tag to sign-off area --- fs/hfsplus/unicode.c | 1 + fs/hfsplus/xattr.c | 13 ++++++++++--- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c index 73342c925a4b..1f122e3c9583 100644 --- a/fs/hfsplus/unicode.c +++ b/fs/hfsplus/unicode.c @@ -246,6 +246,7 @@ int hfsplus_uni2asc(struct super_block *sb, res = 0; out: *len_p = (char *)op - astr; + *op = '\0'; return res; } diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c index 9a1a93e3888b..f20487ad4e8a 100644 --- a/fs/hfsplus/xattr.c +++ b/fs/hfsplus/xattr.c @@ -746,9 +746,16 @@ ssize_t hfsplus_listxattr(struct dentry *dentry, char *buffer, size_t size) if (size < (res + name_len(strbuf, xattr_name_len))) { res = -ERANGE; goto end_listxattr; - } else - res += copy_name(buffer + res, - strbuf, xattr_name_len); + } else { + err = copy_name(buffer + res, + strbuf, xattr_name_len); + if (err < 0) { + res = err; + goto end_listxattr; + } + else + res += err; + } } if (hfs_brec_goto(&fd, 1)) -- 2.43.0

5 months, 2 weeks

1
0
0 0

[PATCH net,v2] hv_netvsc: fix potential deadlock in netvsc_vf_setxdp()

by Saurabh Sengar

The MANA driver's probe registers netdevice via the following call chain: mana_probe() register_netdev() register_netdevice() register_netdevice() calls notifier callback for netvsc driver, holding the netdev mutex via netdev_lock_ops(). Further this netvsc notifier callback end up attempting to acquire the same lock again in dev_xdp_propagate() leading to deadlock. netvsc_netdev_event() netvsc_vf_setxdp() dev_xdp_propagate() This deadlock was not observed so far because net_shaper_ops was never set, and thus the lock was effectively a no-op in this case. Fix this by using netif_xdp_propagate() instead of dev_xdp_propagate() to avoid recursive locking in this path. Also, clean up the unregistration path by removing the unnecessary call to netvsc_vf_setxdp(), since unregister_netdevice_many_notify() already performs this cleanup via dev_xdp_uninstall(). Fixes: 97246d6d21c2 ("net: hold netdev instance lock during ndo_bpf") Cc: stable(a)vger.kernel.org Signed-off-by: Saurabh Sengar <ssengar(a)linux.microsoft.com> Tested-by: Erni Sri Satya Vennela <ernis(a)linux.microsoft.com> Reviewed-by: Haiyang Zhang <haiyangz(a)microsoft.com> --- [V2] - Modified commit message drivers/net/hyperv/netvsc_bpf.c | 2 +- drivers/net/hyperv/netvsc_drv.c | 2 -- net/core/dev.c | 1 + 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/hyperv/netvsc_bpf.c b/drivers/net/hyperv/netvsc_bpf.c index e01c5997a551..1dd3755d9e6d 100644 --- a/drivers/net/hyperv/netvsc_bpf.c +++ b/drivers/net/hyperv/netvsc_bpf.c @@ -183,7 +183,7 @@ int netvsc_vf_setxdp(struct net_device *vf_netdev, struct bpf_prog *prog) xdp.command = XDP_SETUP_PROG; xdp.prog = prog; - ret = dev_xdp_propagate(vf_netdev, &xdp); + ret = netif_xdp_propagate(vf_netdev, &xdp); if (ret && prog) bpf_prog_put(prog); diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index d8b169ac0343..ee3aaf9c10e6 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2462,8 +2462,6 @@ static int netvsc_unregister_vf(struct net_device *vf_netdev) netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name); - netvsc_vf_setxdp(vf_netdev, NULL); - reinit_completion(&net_device_ctx->vf_add); netdev_rx_handler_unregister(vf_netdev); netdev_upper_dev_unlink(vf_netdev, ndev); diff --git a/net/core/dev.c b/net/core/dev.c index fccf2167b235..8c6c9d7fba26 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -9953,6 +9953,7 @@ int netif_xdp_propagate(struct net_device *dev, struct netdev_bpf *bpf) return dev->netdev_ops->ndo_bpf(dev, bpf); } +EXPORT_SYMBOL_GPL(netif_xdp_propagate); u32 dev_xdp_prog_id(struct net_device *dev, enum bpf_xdp_mode mode) { -- 2.43.0

5 months, 2 weeks

4
4
0 0

Re: Patch "x86/relocs: Handle R_X86_64_REX_GOTPCRELX relocations" has been added to the 6.14-stable tree

by Nathan Chancellor

On Thu, May 22, 2025 at 05:30:09PM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > x86/relocs: Handle R_X86_64_REX_GOTPCRELX relocations > > to the 6.14-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > x86-relocs-handle-r_x86_64_rex_gotpcrelx-relocations.patch > and it can be found in the queue-6.14 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit d8e603969259e50aa632d1a3fde8883f41e26150 > Author: Brian Gerst <brgerst(a)gmail.com> > Date: Thu Jan 23 14:07:37 2025 -0500 > > x86/relocs: Handle R_X86_64_REX_GOTPCRELX relocations > > [ Upstream commit cb7927fda002ca49ae62e2782c1692acc7b80c67 ] > > Clang may produce R_X86_64_REX_GOTPCRELX relocations when redefining the > stack protector location. Treat them as another type of PC-relative > relocation. > > Signed-off-by: Brian Gerst <brgerst(a)gmail.com> > Signed-off-by: Ingo Molnar <mingo(a)kernel.org> > Reviewed-by: Ard Biesheuvel <ardb(a)kernel.org> > Cc: Linus Torvalds <torvalds(a)linux-foundation.org> > Link: https://lore.kernel.org/r/20250123190747.745588-6-brgerst@gmail.com > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c > index e937be979ec86..92a1e503305ef 100644 > --- a/arch/x86/tools/relocs.c > +++ b/arch/x86/tools/relocs.c > @@ -32,6 +32,11 @@ static struct relocs relocs32; > static struct relocs relocs32neg; > static struct relocs relocs64; > # define FMT PRIu64 > + > +#ifndef R_X86_64_REX_GOTPCRELX > +# define R_X86_64_REX_GOTPCRELX 42 > +#endif > + > #else > # define FMT PRIu32 > #endif > @@ -227,6 +232,7 @@ static const char *rel_type(unsigned type) > REL_TYPE(R_X86_64_PC16), > REL_TYPE(R_X86_64_8), > REL_TYPE(R_X86_64_PC8), > + REL_TYPE(R_X86_64_REX_GOTPCRELX), > #else > REL_TYPE(R_386_NONE), > REL_TYPE(R_386_32), > @@ -861,6 +867,7 @@ static int do_reloc64(struct section *sec, Elf_Rel *rel, ElfW(Sym) *sym, > > case R_X86_64_PC32: > case R_X86_64_PLT32: > + case R_X86_64_REX_GOTPCRELX: > /* > * PC relative relocations don't need to be adjusted unless > * referencing a percpu symbol. Didn't Ard just say this has no purpose in stable? https://lore.kernel.org/CAMj1kXGtasdqRPn8koNN095VEEU4K409QvieMdgGXNUK0kPgkw… Cheers, Nathan

5 months, 2 weeks

2
1
0 0

[PATCH] drm/xe/sched: stop re-submitting signalled jobs

by Matthew Auld

Customer is reporting a really subtle issue where we get random DMAR faults, hangs and other nasties for kernel migration jobs when stressing stuff like s2idle/s3/s4. The explosions seems to happen somewhere after resuming the system with splats looking something like: PM: suspend exit rfkill: input handler disabled xe 0000:00:02.0: [drm] GT0: Engine reset: engine_class=bcs, logical_mask: 0x2, guc_id=0 xe 0000:00:02.0: [drm] GT0: Timedout job: seqno=24496, lrc_seqno=24496, guc_id=0, flags=0x13 in no process [-1] xe 0000:00:02.0: [drm] GT0: Kernel-submitted job timed out The likely cause appears to be a race between suspend cancelling the worker that processes the free_job()'s, such that we still have pending jobs to be freed after the cancel. Following from this, on resume the pending_list will now contain at least one already complete job, but it looks like we call drm_sched_resubmit_jobs(), which will then call run_job() on everything still on the pending_list. But if the job was already complete, then all the resources tied to the job, like the bb itself, any memory that is being accessed, the iommu mappings etc. might be long gone since those are usually tied to the fence signalling. This scenario can be seen in ftrace when running a slightly modified xe_pm (kernel was only modified to inject artificial latency into free_job to make the race easier to hit): xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ... xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_exec_queue_stop: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=1, guc_state=0x0, flags=0x4 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=0, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 1:0x1, gt=1, width=1, guc_id=1, guc_state=0x0, flags=0x3 xe_exec_queue_stop: dev=0000:00:02.0, 4:0x1, gt=1, width=1, guc_id=2, guc_state=0x0, flags=0x3 xe_exec_queue_resubmit: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x0, flags=0x13 xe_sched_job_run: dev=0000:00:02.0, fence=0xffff888276cc8540, seqno=0, lrc_seqno=0, gt=0, guc_id=0, batch_addr=0x000000146910 ... ..... xe_exec_queue_memory_cat_error: dev=0000:00:02.0, 3:0x2, gt=0, width=1, guc_id=0, guc_state=0x3, flags=0x13 So the job_run() is clearly triggered twice, even though the first must have already signalled to completion during suspend. We can also see a CAT error after the re-submit. To prevent this try to call xe_sched_stop() to forcefully remove anything on the pending_list that has already signalled, before we re-submit. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4856 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: William Tseng <william.tseng(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ --- drivers/gpu/drm/xe/xe_gpu_scheduler.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/xe/xe_gpu_scheduler.h b/drivers/gpu/drm/xe/xe_gpu_scheduler.h index c250ea773491..9315da58d02d 100644 --- a/drivers/gpu/drm/xe/xe_gpu_scheduler.h +++ b/drivers/gpu/drm/xe/xe_gpu_scheduler.h @@ -51,6 +51,7 @@ static inline void xe_sched_tdr_queue_imm(struct xe_gpu_scheduler *sched) static inline void xe_sched_resubmit_jobs(struct xe_gpu_scheduler *sched) { + xe_sched_stop(sched); drm_sched_resubmit_jobs(&sched->base); } -- 2.49.0

5 months, 2 weeks

1
0
0 0

[PATCH] mm: fix copy_vma() error handling for hugetlb mappings

by Ricardo Cañuelo Navarro

If, during a mremap() operation for a hugetlb-backed memory mapping, copy_vma() fails after the source vma has been duplicated and opened (ie. vma_link() fails), the error is handled by closing the new vma. This updates the hugetlbfs reservation counter of the reservation map which at this point is referenced by both the source vma and the new copy. As a result, once the new vma has been freed and copy_vma() returns, the reservation counter for the source vma will be incorrect. This patch addresses this corner case by clearing the hugetlb private page reservation reference for the new vma and decrementing the reference before closing the vma, so that vma_close() won't update the reservation counter. The issue was reported by a private syzbot instance, see the error report log [1] and reproducer [2]. Possible duplicate of public syzbot report [3]. Signed-off-by: Ricardo Cañuelo Navarro <rcn(a)igalia.com> Cc: stable(a)vger.kernel.org # 6.12+ Link: https://people.igalia.com/rcn/kernel_logs/20250422__WARNING_in_page_counter… [1] Link: https://people.igalia.com/rcn/kernel_logs/20250422__WARNING_in_page_counter… [2] Link: https://lore.kernel.org/all/67000a50.050a0220.49194.048d.GAE@google.com/ [3] --- mm/vma.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/vma.c b/mm/vma.c index 839d12f02c885d3338d8d233583eb302d82bb80b..9d9f699ace977c9c869e5da5f88f12be183adcfb 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -1834,6 +1834,8 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap, return new_vma; out_vma_link: + if (is_vm_hugetlb_page(new_vma)) + clear_vma_resv_huge_pages(new_vma); vma_close(new_vma); if (new_vma->vm_file) --- base-commit: 94305e83eccb3120c921cd3a015cd74731140bac change-id: 20250523-warning_in_page_counter_cancel-e8c71a6b4c88

5 months, 2 weeks

3
6
0 0

[PATCH] i2c: qup: Add error handling in qup_i2c_xfer_v2()

by Wentao Liang

The qup_i2c_xfer_v2() calls the qup_i2c_change_state() but does not check its return value. A proper implementation can be found in qup_i2c_xfer(). Add error handling for qup_i2c_change_state(). If the function fails, return the error code. Fixes: 7545c7dba169 ("i2c: qup: reorganization of driver code to remove polling for qup v2") Cc: stable(a)vger.kernel.org # v4.17 Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/i2c/busses/i2c-qup.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c index da20b4487c9a..2477f570fe86 100644 --- a/drivers/i2c/busses/i2c-qup.c +++ b/drivers/i2c/busses/i2c-qup.c @@ -1538,7 +1538,7 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap, int num) { struct qup_i2c_dev *qup = i2c_get_adapdata(adap); - int ret, idx = 0; + int ret, err, idx = 0; qup->bus_err = 0; qup->qup_err = 0; @@ -1588,7 +1588,9 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap, ret = qup_i2c_bus_active(qup, ONE_BYTE); if (!ret) - qup_i2c_change_state(qup, QUP_RESET_STATE); + err = qup_i2c_change_state(qup, QUP_RESET_STATE); + if (err) + return err; if (ret == 0) ret = num; -- 2.42.0.windows.2

5 months, 2 weeks

5
5
0 0

[PATCH] drm/nouveau/mmu: fix potential overflow in PFN size calculation

by Alexey Nepomnyashih

On most Linux-supported platforms, `int` is 32-bit, making (1 << 47) undefined and potentially dangerous. To ensure defined behavior and correct 64-bit arithmetic, replace `1` with `1ULL`. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable(a)vger.kernel.org # v5.1+ Fixes: a5ff307fe1f2 ("drm/nouveau/mmu: add a privileged method to directly manage PTEs") Signed-off-by: Alexey Nepomnyashih <sdl(a)nppct.ru> --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c index 9c97800fe037..29da1acbe3a8 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c @@ -1383,7 +1383,7 @@ nvkm_vmm_pfn_map(struct nvkm_vmm *vmm, u8 shift, u64 addr, u64 size, u64 *pfn) */ while (size) { pfn[pi++] = NVKM_VMM_PFN_NONE; - size -= 1 << page->shift; + size -= 1ULL << page->shift; } } else { pi += size >> page->shift; -- 2.43.0

5 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025