Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

289 participants
124121 discussions

[PATCH] io_uring: fix filename leak in __io_openat_prep()

by Prithvi Tambewagh

__io_openat_prep() allocates a struct filename using getname(), but it isn't freed in case the present file is installed in the fixed file table and simultaneously, it has the flag O_CLOEXEC set in the open->how.flags field. This is an erroneous condition, since for a file installed in the fixed file table, it won't be installed in the normal file table, due to which the file cannot support close on exec. Earlier, the code just returned -EINVAL error code for this condition, however, the memory allocated for that struct filename wasn't freed, resulting in a memory leak. Hence, the case of file being installed in the fixed file table as well as having O_CLOEXEC flag in open->how.flags set, is adressed by using putname() to release the memory allocated to the struct filename, then setting the field open->filename to NULL, and after that, returning -EINVAL. 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> --- io_uring/openclose.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/io_uring/openclose.c b/io_uring/openclose.c index bfeb91b31bba..fc190a3d8112 100644 --- a/io_uring/openclose.c +++ b/io_uring/openclose.c @@ -75,8 +75,11 @@ static int __io_openat_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe } open->file_slot = READ_ONCE(sqe->file_index); - if (open->file_slot && (open->how.flags & O_CLOEXEC)) + if (open->file_slot && (open->how.flags & O_CLOEXEC)) { + putname(open->filename); + open->filename = NULL; return -EINVAL; + } open->nofile = rlimit(RLIMIT_NOFILE); req->flags |= REQ_F_NEED_CLEANUP; base-commit: b927546677c876e26eba308550207c2ddf812a43 -- 2.34.1

2 weeks, 2 days

[PATCH] ARM: dts: integrator: Fix DMA ranges mismatch warning on IM-PD1

by Kuan-Wei Chiu

When compiling the device tree for the Integrator/AP with IM-PD1, the following warning is observed regarding the display controller node: arch/arm/boot/dts/arm/integratorap-im-pd1.dts:251.3-14: Warning (dma_ranges_format): /bus@c0000000/bus@c0000000/display@1000000:dma-ranges: empty "dma-ranges" property but its #address-cells (2) differs from /bus@c0000000/bus@c0000000 (1) The display node specifies an empty "dma-ranges" property, intended to describe a 1:1 identity mapping. However, the node lacks explicit "#address-cells" and "#size-cells" properties. In this case, the device tree compiler defaults the address cells to 2 (64-bit), which conflicts with the parent bus configuration (32-bit, 1 cell). Fix this by explicitly defining "#address-cells" and "#size-cells" as 1. This matches the 32-bit architecture of the Integrator platform and ensures the address translation range is correctly parsed by the compiler. Fixes: 7bea67a99430 ("ARM: dts: integrator: Fix DMA ranges") Cc: stable(a)vger.kernel.org Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> --- arch/arm/boot/dts/arm/integratorap-im-pd1.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/arm/integratorap-im-pd1.dts b/arch/arm/boot/dts/arm/integratorap-im-pd1.dts index db13e09f2fab..6d90d9a42dc9 100644 --- a/arch/arm/boot/dts/arm/integratorap-im-pd1.dts +++ b/arch/arm/boot/dts/arm/integratorap-im-pd1.dts @@ -248,6 +248,8 @@ display@1000000 { /* 640x480 16bpp @ 25.175MHz is 36827428 bytes/s */ max-memory-bandwidth = <40000000>; memory-region = <&impd1_ram>; + #address-cells = <1>; + #size-cells = <1>; dma-ranges; port@0 { -- 2.52.0.177.g9f829587af-goog

2 weeks, 2 days

[PATCH v1 0/3] mm: mm_cid static initialization fixes

by Mathieu Desnoyers

Hi Andrew, Here are 2 fixes for missing mm_cid fields for init_mm and efi_mm static initialization. The renaming of cpu_bitmap to flexible_array (patch 2) is needed for patch 3. Those are relevant for mainline, with CC stable. They are based on v6.19-rc2. Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: linux-mm(a)kvack.org Mathieu Desnoyers (3): mm: Add missing static initializer for init_mm::mm_cid.lock mm: Rename cpu_bitmap field to flexible_array mm: Take into account mm_cid size for mm_struct static definitions drivers/firmware/efi/efi.c | 2 +- include/linux/mm_types.h | 18 +++++++++++++----- mm/init-mm.c | 5 ++++- 3 files changed, 18 insertions(+), 7 deletions(-) -- 2.39.5

2 weeks, 3 days

[PATCH v3] virtio: console: fix lost wakeup when device is written and polled

by Lorenz Bauer

A process issuing blocking writes to a virtio console may get stuck indefinitely if another thread polls the device. Here is how to trigger the bug: - Thread A writes to the port until the virtqueue is full. - Thread A calls wait_port_writable() and goes to sleep, waiting on port->waitqueue. - The host processes some of the write, marks buffers as used and raises an interrupt. - Before the interrupt is serviced, thread B executes port_fops_poll(). This calls reclaim_consumed_buffers() via will_write_block() and consumes all used buffers. - The interrupt is serviced. vring_interrupt() finds no used buffers via more_used() and returns without waking port->waitqueue. - Thread A is still in wait_event(port->waitqueue), waiting for a wakeup that never arrives. The crux is that invoking reclaim_consumed_buffers() may cause vring_interrupt() to omit wakeups. Fix this by calling reclaim_consumed_buffers() in out_int() before waking. This is similar to the call to discard_port_data() in in_intr() which also frees buffer from a non-sleepable context. This in turn guarantees that port->outvq_full is up to date when handling polling. Since in_intr() already populates port->inbuf we use that to avoid changing reader state. Cc: stable(a)vger.kernel.org Signed-off-by: Lorenz Bauer <lmb(a)isovalent.com> --- As far as I can tell all currently maintained stable series kernels need this commit. Applies and builds cleanly on 5.10.247, verified to fix the issue. --- Changes in v3: - Use spin_lock_irq in port_fops_poll (Arnd) - Use spin_lock in out_intr (Arnd) - Link to v2: https://lore.kernel.org/r/20251222-virtio-console-lost-wakeup-v2-1-5de93cb3… Changes in v2: - Call reclaim_consumed_buffers() in out_intr instead of issuing another wake. - Link to v1: https://lore.kernel.org/r/20251215-virtio-console-lost-wakeup-v1-1-79a5c578… --- drivers/char/virtio_console.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 088182e54debd6029ea2c2a5542d7a28500e67b8..e6048e04c3b23d008caa2a1d31d4ac6b2841045f 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -971,10 +971,17 @@ static __poll_t port_fops_poll(struct file *filp, poll_table *wait) return EPOLLHUP; } ret = 0; - if (!will_read_block(port)) + + spin_lock_irq(&port->inbuf_lock); + if (port->inbuf) ret |= EPOLLIN | EPOLLRDNORM; - if (!will_write_block(port)) + spin_unlock_irq(&port->inbuf_lock); + + spin_lock_irq(&port->outvq_lock); + if (!port->outvq_full) ret |= EPOLLOUT; + spin_unlock_irq(&port->outvq_lock); + if (!port->host_connected) ret |= EPOLLHUP; @@ -1705,6 +1712,10 @@ static void out_intr(struct virtqueue *vq) return; } + spin_lock(&port->outvq_lock); + reclaim_consumed_buffers(port); + spin_unlock(&port->outvq_lock); + wake_up_interruptible(&port->waitqueue); } --- base-commit: d358e5254674b70f34c847715ca509e46eb81e6f change-id: 20251215-virtio-console-lost-wakeup-0f566c5cd35f Best regards, -- Lorenz Bauer <lmb(a)isovalent.com>

2 weeks, 3 days

[PATCH v6.1 0/2] x86/mm/pat: fix VM_PAT handling

by Ajay Kaher

[PATCH v6.1 1/2]: required to backport [PATCH v6.1 2/2]. [PATCH v6.1 2/2]: backport to fix VM_PAT handling when fork() fails in copy_page_range(). arch/x86/mm/pat/memtype.c | 50 +++++++++++++++++++++++---------------- include/linux/pgtable.h | 31 ++++++++++++++++++------ kernel/fork.c | 4 ++++ mm/memory.c | 10 ++++---- mm/mremap.c | 2 +- 5 files changed, 62 insertions(+), 35 deletions(-) -- 2.40.4

2 weeks, 3 days

[PATCH] usb: cdns3: fix a null pointer dereference in cdns3_gadget_ep_queue()

by Haoxiang Li

If cdns3_gadget_ep_alloc_request() fails, a null pointer dereference occurs. Add a check to prevent it. Found by code review and compiled on ubuntu 20.04. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/usb/cdns3/cdns3-gadget.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c index 168707213ed9..cc2421a34588 100644 --- a/drivers/usb/cdns3/cdns3-gadget.c +++ b/drivers/usb/cdns3/cdns3-gadget.c @@ -2659,6 +2659,8 @@ static int cdns3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request, struct cdns3_request *priv_req; zlp_request = cdns3_gadget_ep_alloc_request(ep, GFP_ATOMIC); + if (!zlp_request) + return -ENOMEM; zlp_request->buf = priv_dev->zlp_buf; zlp_request->length = 0; -- 2.25.1

2 weeks, 3 days

[PATCH] usb: cdns2: fix a null pointer dereference in cdns2_gadget_ep_queue()

by Haoxiang Li

If cdns2_gadget_ep_alloc_request() fails, a null pointer dereference occurs. Add a check to prevent it. Fixes: 3eb1f1efe204 ("usb: cdns2: Add main part of Cadence USBHS driver") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/usb/gadget/udc/cdns2/cdns2-gadget.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/udc/cdns2/cdns2-gadget.c b/drivers/usb/gadget/udc/cdns2/cdns2-gadget.c index 9b53daf76583..c5b9dae743d8 100644 --- a/drivers/usb/gadget/udc/cdns2/cdns2-gadget.c +++ b/drivers/usb/gadget/udc/cdns2/cdns2-gadget.c @@ -1725,6 +1725,8 @@ static int cdns2_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request, struct cdns2_request *preq; zlp_request = cdns2_gadget_ep_alloc_request(ep, GFP_ATOMIC); + if (!zlp_request) + return -ENOMEM; zlp_request->buf = pdev->zlp_buf; zlp_request->length = 0; -- 2.25.1

2 weeks, 3 days

[PATCH] drm/msm/dpu: Add missing NULL pointer check for pingpong interface

by Nikolay Kuratov

It is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in a single place the check is missing. Also use convenient locals instead of phys_enc->* where available. Cc: stable(a)vger.kernel.org Fixes: d7d0e73f7de33 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru> --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c index 46f348972a97..6d28f2281c76 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c @@ -247,14 +247,12 @@ static void dpu_encoder_phys_wb_setup_ctl(struct dpu_encoder_phys *phys_enc) if (hw_cdm) intf_cfg.cdm = hw_cdm->idx; - if (phys_enc->hw_pp->merge_3d && phys_enc->hw_pp->merge_3d->ops.setup_3d_mode) - phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d, - mode_3d); + if (hw_pp && hw_pp->merge_3d && hw_pp->merge_3d->ops.setup_3d_mode) + hw_pp->merge_3d->ops.setup_3d_mode(hw_pp->merge_3d, mode_3d); /* setup which pp blk will connect to this wb */ - if (hw_pp && phys_enc->hw_wb->ops.bind_pingpong_blk) - phys_enc->hw_wb->ops.bind_pingpong_blk(phys_enc->hw_wb, - phys_enc->hw_pp->idx); + if (hw_pp && hw_wb->ops.bind_pingpong_blk) + hw_wb->ops.bind_pingpong_blk(hw_wb, hw_pp->idx); phys_enc->hw_ctl->ops.setup_intf_cfg(phys_enc->hw_ctl, &intf_cfg); } else if (phys_enc->hw_ctl && phys_enc->hw_ctl->ops.setup_intf_cfg) { -- 2.34.1

2 weeks, 3 days

[PATCH V2 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: 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 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 | 24 +++++++++++--- 6 files changed, 45 insertions(+), 42 deletions(-) base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 -- 2.39.1

2 weeks, 3 days

[PATCH] media: iris: Add missing platform data entries for SM8750

by Dikshita Agarwal

Two platform-data fields for SM8750 were missed: - get_vpu_buffer_size = iris_vpu33_buf_size Without this, the driver fails to allocate the required internal buffers, leading to basic decode/encode failures during session bring-up. - max_core_mbps = ((7680 * 4320) / 256) * 60 Without this capability exposed, capability checks are incomplete and v4l2-compliance for encoder fails. Fixes: a5925a2ce077 ("media: iris: add VPU33 specific encoding buffer calculation") Fixes: a6882431a138 ("media: iris: Add support for ENUM_FRAMESIZES/FRAMEINTERVALS for encoder") Cc: stable(a)vger.kernel.org Signed-off-by: Dikshita Agarwal <dikshita.agarwal(a)oss.qualcomm.com> --- drivers/media/platform/qcom/iris/iris_platform_gen2.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen2.c b/drivers/media/platform/qcom/iris/iris_platform_gen2.c index c1989240c248601c34b84f508f1b72d72f81260a..00d1d55463179429f2ae7554546dcbe4fb1431cc 100644 --- a/drivers/media/platform/qcom/iris/iris_platform_gen2.c +++ b/drivers/media/platform/qcom/iris/iris_platform_gen2.c @@ -915,6 +915,7 @@ const struct iris_platform_data sm8750_data = { .get_instance = iris_hfi_gen2_get_instance, .init_hfi_command_ops = iris_hfi_gen2_command_ops_init, .init_hfi_response_ops = iris_hfi_gen2_response_ops_init, + .get_vpu_buffer_size = iris_vpu33_buf_size, .vpu_ops = &iris_vpu35_ops, .set_preset_registers = iris_set_sm8550_preset_registers, .icc_tbl = sm8550_icc_table, @@ -945,6 +946,7 @@ const struct iris_platform_data sm8750_data = { .num_vpp_pipe = 4, .max_session_count = 16, .max_core_mbpf = NUM_MBS_8K * 2, + .max_core_mbps = ((7680 * 4320) / 256) * 60, .dec_input_config_params_default = sm8550_vdec_input_config_params_default, .dec_input_config_params_default_size = --- base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 change-id: 20251217-iris-sm8750-fix-2d42a133058d Best regards, -- Dikshita Agarwal <dikshita.agarwal(a)oss.qualcomm.com>

2 weeks, 3 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror