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

[PATCH] usb: renesas_usbhs: Fix a resource leak in usbhs_pipe_malloc()

by Haoxiang Li

usbhsp_get_pipe() set pipe's flags to IS_USED. In error paths, usbhsp_put_pipe() is required to clear pipe's flags to prevent pipe exhaustion. Fixes: f1407d5c6624 ("usb: renesas_usbhs: Add Renesas USBHS common code") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- drivers/usb/renesas_usbhs/pipe.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/renesas_usbhs/pipe.c b/drivers/usb/renesas_usbhs/pipe.c index 75fff2e4cbc6..56fc3ff5016f 100644 --- a/drivers/usb/renesas_usbhs/pipe.c +++ b/drivers/usb/renesas_usbhs/pipe.c @@ -713,11 +713,13 @@ struct usbhs_pipe *usbhs_pipe_malloc(struct usbhs_priv *priv, /* make sure pipe is not busy */ ret = usbhsp_pipe_barrier(pipe); if (ret < 0) { + usbhsp_put_pipe(pipe); dev_err(dev, "pipe setup failed %d\n", usbhs_pipe_number(pipe)); return NULL; } if (usbhsp_setup_pipecfg(pipe, is_host, dir_in, &pipecfg)) { + usbhsp_put_pipe(pipe); dev_err(dev, "can't setup pipe\n"); return NULL; } -- 2.25.1

2 weeks, 1 day

1
0
0 0

[PATCH 0/2] 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> --- Krishna Chaitanya Chundru (2): 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 | 37 ++++++++++++++--------- drivers/pci/controller/dwc/pcie-designware.c | 3 ++ drivers/pci/controller/dwc/pcie-designware.h | 2 +- 3 files changed, 26 insertions(+), 16 deletions(-) --- base-commit: 3f9f0252130e7dd60d41be0802bf58f6471c691d change-id: 20251203-ecam_io_fix-6e060fecd3b8 Best regards, -- Krishna Chaitanya Chundru <krishna.chundru(a)oss.qualcomm.com>

2 weeks, 1 day

3
3
0 0

[PATCH] drm/i915/dmc: fix an unlikely NULL pointer deference at probe

by Jani Nikula

intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been initialized, and dmc is thus NULL. That would be the case when the call path is intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() -> gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as intel_power_domains_init_hw() is called *before* intel_dmc_init(). However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count() conditionally, depending on the current and target DC states. At probe, the target is disabled, but if DC6 is enabled, the function is called, and an oops follows. Apparently it's quite unlikely that DC6 is enabled at probe, as we haven't seen this failure mode before. Add NULL checks and switch the dmc->display references to just display. Fixes: 88c1f9a4d36d ("drm/i915/dmc: Create debugfs entry for dc6 counter") Cc: Mohammed Thasleem <mohammed.thasleem(a)intel.com> Cc: Imre Deak <imre.deak(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.16+ Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- Rare case, but this may also throw off the rc6 counting in debugfs when it does happen. --- drivers/gpu/drm/i915/display/intel_dmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c index 2fb6fec6dc99..169bbbc91f6d 100644 --- a/drivers/gpu/drm/i915/display/intel_dmc.c +++ b/drivers/gpu/drm/i915/display/intel_dmc.c @@ -1570,10 +1570,10 @@ void intel_dmc_update_dc6_allowed_count(struct intel_display *display, struct intel_dmc *dmc = display_to_dmc(display); u32 dc5_cur_count; - if (DISPLAY_VER(dmc->display) < 14) + if (!dmc || DISPLAY_VER(display) < 14) return; - dc5_cur_count = intel_de_read(dmc->display, DG1_DMC_DEBUG_DC5_COUNT); + dc5_cur_count = intel_de_read(display, DG1_DMC_DEBUG_DC5_COUNT); if (!start_tracking) dmc->dc6_allowed.count += dc5_cur_count - dmc->dc6_allowed.dc5_start; @@ -1587,7 +1587,7 @@ static bool intel_dmc_get_dc6_allowed_count(struct intel_display *display, u32 * struct intel_dmc *dmc = display_to_dmc(display); bool dc6_enabled; - if (DISPLAY_VER(display) < 14) + if (!dmc || DISPLAY_VER(display) < 14) return false; mutex_lock(&power_domains->lock); -- 2.47.3

2 weeks, 1 day

2
6
0 0

[PATCH 5.10.y] HID: core: Harden s32ton() against conversion to 0 bits

by jetlan9＠163.com

From: Alan Stern <stern(a)rowland.harvard.edu> [ Upstream commit a6b87bfc2ab5bccb7ad953693c85d9062aef3fdd ] Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-by: syzbot+b63d677d63bcac06cf90(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.… Tested-by: syzbot+b63d677d63bcac06cf90(a)syzkaller.appspotmail.com Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/613a66cd-4309-4bce-a4f7-2905f9bce0c9@rowland.harva… Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> [ s32ton() was moved by c653ffc28340 ("HID: stop exporting hid_snto32()"). Minor context change fixed. ] Signed-off-by: Wenshan Lan <jetlan9(a)163.com> --- drivers/hid/hid-core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 89aa7a0e51de..e789452181fe 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1349,7 +1349,12 @@ EXPORT_SYMBOL_GPL(hid_snto32); static u32 s32ton(__s32 value, unsigned n) { - s32 a = value >> (n - 1); + s32 a; + + if (!value || !n) + return 0; + + a = value >> (n - 1); if (a && a != -1) return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1; return value & ((1 << n) - 1); -- 2.43.0

2 weeks, 1 day

1
0
0 0

[PATCH 5.15.y] HID: core: Harden s32ton() against conversion to 0 bits

by jetlan9＠163.com

From: Alan Stern <stern(a)rowland.harvard.edu> [ Upstream commit a6b87bfc2ab5bccb7ad953693c85d9062aef3fdd ] Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-by: syzbot+b63d677d63bcac06cf90(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-usb/68753a08.050a0220.33d347.0008.GAE@google.… Tested-by: syzbot+b63d677d63bcac06cf90(a)syzkaller.appspotmail.com Fixes: dde5845a529f ("[PATCH] Generic HID layer - code split") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/613a66cd-4309-4bce-a4f7-2905f9bce0c9@rowland.harva… Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> [ s32ton() was moved by c653ffc28340 ("HID: stop exporting hid_snto32()"). Minor context change fixed. ] Signed-off-by: Wenshan Lan <jetlan9(a)163.com> --- drivers/hid/hid-core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index a6c2c55daebb..d49a8c458206 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -1349,7 +1349,12 @@ EXPORT_SYMBOL_GPL(hid_snto32); static u32 s32ton(__s32 value, unsigned n) { - s32 a = value >> (n - 1); + s32 a; + + if (!value || !n) + return 0; + + a = value >> (n - 1); if (a && a != -1) return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1; return value & ((1 << n) - 1); -- 2.43.0

2 weeks, 1 day

1
0
0 0

[PATCH v3 1/2] hfs: ensure sb->s_fs_info is always cleaned up

by Mehdi Ben Hadj Khelifa

When hfs was converted to the new mount api a bug was introduced by changing the allocation pattern of sb->s_fs_info. If setup_bdev_super() fails after a new superblock has been allocated by sget_fc(), but before hfs_fill_super() takes ownership of the filesystem-specific s_fs_info data it was leaked. Fix this by freeing sb->s_fs_info in hfs_kill_super(). Cc: stable(a)vger.kernel.org Fixes: ffcd06b6d13b ("hfs: convert hfs to use the new mount api") Reported-by: syzbot+ad45f827c88778ff7df6(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ad45f827c88778ff7df6 Tested-by: Viacheslav Dubeyko <Slava.Dubeyko(a)ibm.com> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa(a)gmail.com> --- fs/hfs/mdb.c | 35 ++++++++++++++--------------------- fs/hfs/super.c | 10 +++++++++- 2 files changed, 23 insertions(+), 22 deletions(-) diff --git a/fs/hfs/mdb.c b/fs/hfs/mdb.c index 53f3fae60217..f28cd24dee84 100644 --- a/fs/hfs/mdb.c +++ b/fs/hfs/mdb.c @@ -92,7 +92,7 @@ int hfs_mdb_get(struct super_block *sb) /* See if this is an HFS filesystem */ bh = sb_bread512(sb, part_start + HFS_MDB_BLK, mdb); if (!bh) - goto out; + return -EIO; if (mdb->drSigWord == cpu_to_be16(HFS_SUPER_MAGIC)) break; @@ -102,13 +102,14 @@ int hfs_mdb_get(struct super_block *sb) * (should do this only for cdrom/loop though) */ if (hfs_part_find(sb, &part_start, &part_size)) - goto out; + return -EIO; } HFS_SB(sb)->alloc_blksz = size = be32_to_cpu(mdb->drAlBlkSiz); if (!size || (size & (HFS_SECTOR_SIZE - 1))) { pr_err("bad allocation block size %d\n", size); - goto out_bh; + brelse(bh); + return -EIO; } size = min(HFS_SB(sb)->alloc_blksz, (u32)PAGE_SIZE); @@ -125,14 +126,16 @@ int hfs_mdb_get(struct super_block *sb) brelse(bh); if (!sb_set_blocksize(sb, size)) { pr_err("unable to set blocksize to %u\n", size); - goto out; + return -EIO; } bh = sb_bread512(sb, part_start + HFS_MDB_BLK, mdb); if (!bh) - goto out; - if (mdb->drSigWord != cpu_to_be16(HFS_SUPER_MAGIC)) - goto out_bh; + return -EIO; + if (mdb->drSigWord != cpu_to_be16(HFS_SUPER_MAGIC)) { + brelse(bh); + return -EIO; + } HFS_SB(sb)->mdb_bh = bh; HFS_SB(sb)->mdb = mdb; @@ -174,7 +177,7 @@ int hfs_mdb_get(struct super_block *sb) HFS_SB(sb)->bitmap = kzalloc(8192, GFP_KERNEL); if (!HFS_SB(sb)->bitmap) - goto out; + return -EIO; /* read in the bitmap */ block = be16_to_cpu(mdb->drVBMSt) + part_start; @@ -185,7 +188,7 @@ int hfs_mdb_get(struct super_block *sb) bh = sb_bread(sb, off >> sb->s_blocksize_bits); if (!bh) { pr_err("unable to read volume bitmap\n"); - goto out; + return -EIO; } off2 = off & (sb->s_blocksize - 1); len = min((int)sb->s_blocksize - off2, size); @@ -199,12 +202,12 @@ int hfs_mdb_get(struct super_block *sb) HFS_SB(sb)->ext_tree = hfs_btree_open(sb, HFS_EXT_CNID, hfs_ext_keycmp); if (!HFS_SB(sb)->ext_tree) { pr_err("unable to open extent tree\n"); - goto out; + return -EIO; } HFS_SB(sb)->cat_tree = hfs_btree_open(sb, HFS_CAT_CNID, hfs_cat_keycmp); if (!HFS_SB(sb)->cat_tree) { pr_err("unable to open catalog tree\n"); - goto out; + return -EIO; } attrib = mdb->drAtrb; @@ -229,12 +232,6 @@ int hfs_mdb_get(struct super_block *sb) } return 0; - -out_bh: - brelse(bh); -out: - hfs_mdb_put(sb); - return -EIO; } /* @@ -359,8 +356,6 @@ void hfs_mdb_close(struct super_block *sb) * Release the resources associated with the in-core MDB. */ void hfs_mdb_put(struct super_block *sb) { - if (!HFS_SB(sb)) - return; /* free the B-trees */ hfs_btree_close(HFS_SB(sb)->ext_tree); hfs_btree_close(HFS_SB(sb)->cat_tree); @@ -373,6 +368,4 @@ void hfs_mdb_put(struct super_block *sb) unload_nls(HFS_SB(sb)->nls_disk); kfree(HFS_SB(sb)->bitmap); - kfree(HFS_SB(sb)); - sb->s_fs_info = NULL; } diff --git a/fs/hfs/super.c b/fs/hfs/super.c index 47f50fa555a4..df289cbdd4e8 100644 --- a/fs/hfs/super.c +++ b/fs/hfs/super.c @@ -431,10 +431,18 @@ static int hfs_init_fs_context(struct fs_context *fc) return 0; } +static void hfs_kill_super(struct super_block *sb) +{ + struct hfs_sb_info *hsb = HFS_SB(sb); + + kill_block_super(sb); + kfree(hsb); +} + static struct file_system_type hfs_fs_type = { .owner = THIS_MODULE, .name = "hfs", - .kill_sb = kill_block_super, + .kill_sb = hfs_kill_super, .fs_flags = FS_REQUIRES_DEV, .init_fs_context = hfs_init_fs_context, }; -- 2.52.0

2 weeks, 1 day

2
4
0 0

Loan and Investment offer/ Account Reprofilling

by Gerald Johnson

2 weeks, 1 day

1
0
0 0

[PATCH] soc: mediatek: SVS: Fix a reference leak bug in svs_add_device_link()

by Haoxiang Li

svs_get_subsys_device() increases the reference count of the returned device, if error happens, put_device() is required to drop the device reference. Fixes: 681a02e95000 ("soc: mediatek: SVS: introduce MTK SVS engine") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- drivers/soc/mediatek/mtk-svs.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c index f45537546553..c8f15bb139c6 100644 --- a/drivers/soc/mediatek/mtk-svs.c +++ b/drivers/soc/mediatek/mtk-svs.c @@ -2155,12 +2155,15 @@ static struct device *svs_add_device_link(struct svs_platform *svsp, sup_link = device_link_add(svsp->dev, dev, DL_FLAG_AUTOREMOVE_CONSUMER); if (!sup_link) { + put_device(dev); dev_err(svsp->dev, "sup_link is NULL\n"); return ERR_PTR(-EINVAL); } - if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND) + if (sup_link->supplier->links.status != DL_DEV_DRIVER_BOUND) { + put_device(dev); return ERR_PTR(-EPROBE_DEFER); + } return dev; } -- 2.25.1

2 weeks, 1 day

1
0
0 0

[PATCH v2] drm/xe/exec: Validate num_syncs to prevent oversized allocations

by Shuicheng Lin

The exec ioctl allows userspace to specify an arbitrary num_syncs value. Without bounds checking, a very large num_syncs can force an excessively large allocation, leading to kernel warnings from the page allocator as below. Introduce XE_EXEC_MAX_SYNCS (set to 64) and reject any request exceeding this limit. " ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124 ... Call Trace: <TASK> alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416 ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388 kmalloc_noprof include/linux/slab.h:909 [inline] kmalloc_array_noprof include/linux/slab.h:948 [inline] xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158 drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797 drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894 xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:598 [inline] __se_sys_ioctl fs/ioctl.c:584 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... " v2: Add "Reported-by" and Cc stable kernels. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6450 Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reported-by: Koen Koning <koen.koning(a)intel.com> Reported-by: Peter Senna Tschudin <peter.senna(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Cc: Matthew Brost <matthew.brost(a)intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin(a)intel.com> --- drivers/gpu/drm/xe/xe_exec.c | 5 +++++ include/uapi/drm/xe_drm.h | 1 + 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_exec.c b/drivers/gpu/drm/xe/xe_exec.c index 4d81210e41f5..01c56fd95d5b 100644 --- a/drivers/gpu/drm/xe/xe_exec.c +++ b/drivers/gpu/drm/xe/xe_exec.c @@ -162,6 +162,11 @@ int xe_exec_ioctl(struct drm_device *dev, void *data, struct drm_file *file) } if (args->num_syncs) { + if (XE_IOCTL_DBG(xe, args->num_syncs > XE_EXEC_MAX_SYNCS)) { + err = -EINVAL; + goto err_exec_queue; + } + syncs = kcalloc(args->num_syncs, sizeof(*syncs), GFP_KERNEL); if (!syncs) { err = -ENOMEM; diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h index 47853659a705..1901ca26621a 100644 --- a/include/uapi/drm/xe_drm.h +++ b/include/uapi/drm/xe_drm.h @@ -1463,6 +1463,7 @@ struct drm_xe_exec { /** @exec_queue_id: Exec queue ID for the batch buffer */ __u32 exec_queue_id; +#define XE_EXEC_MAX_SYNCS 64 /** @num_syncs: Amount of struct drm_xe_sync in array. */ __u32 num_syncs; -- 2.49.0

2 weeks, 1 day

3
2
0 0

[PATCH] powerpc: cell: Fix a reference leak bug in create_spu()

by Haoxiang Li

spu_create_dev() calls device_register(), if it fails, put_device() is required to drop the device reference. Fixes: 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck' sysdev_class to a regular subsystem") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- arch/powerpc/platforms/cell/spu_base.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c index 2c07387201d0..18145142d3ac 100644 --- a/arch/powerpc/platforms/cell/spu_base.c +++ b/arch/powerpc/platforms/cell/spu_base.c @@ -581,8 +581,10 @@ static int __init create_spu(void *data) goto out_destroy; ret = spu_create_dev(spu); - if (ret) + if (ret) { + put_device(&spu->dev); goto out_free_irqs; + } mutex_lock(&cbe_spu_info[spu->node].list_mutex); list_add(&spu->cbe_list, &cbe_spu_info[spu->node].spus); -- 2.25.1

2 weeks, 1 day

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror