December 2025 - Linux-stable-mirror

+ mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.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: Jiayuan Chen <jiayuan.chen(a)linux.dev> Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN Date: Fri, 28 Nov 2025 19:15:14 +0800 Syzkaller reported a memory out-of-bounds bug [1]. This patch fixes two issues: 1. In vrealloc, we were missing the KASAN_VMALLOC_VM_ALLOC flag when unpoisoning the extended region. This flag is required to correctly associate the allocation with KASAN's vmalloc tracking. Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) explicitly sets KASAN_VMALLOC_VM_ALLOC and calls kasan_unpoison_vmalloc() with it. vrealloc must behave consistently �� especially when reusing existing vmalloc regions �� to ensure KASAN can track allocations correctly. 2. When vrealloc reuses an existing vmalloc region (without allocating new pages), KASAN previously generated a new tag, which broke tag-based memory access tracking. We now add a 'reuse_tag' parameter to __kasan_unpoison_vmalloc() to preserve the original tag in such cases. A new helper kasan_unpoison_vralloc() is introduced to handle this reuse scenario, ensuring consistent tag behavior during reallocation. Link: https://lkml.kernel.org/r/20251128111516.244497-1-jiayuan.chen@linux.dev Link: https://syzkaller.appspot.com/bug?extid=997752115a851cb0cf36 [1] Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing") Signed-off-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Reported-by: syzbot+997752115a851cb0cf36(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68e243a2.050a0220.1696c6.007d.GAE@google.com/T/ Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: Dmitriy Vyukov <dvyukov(a)google.com> Cc: Kees Cook <kees(a)kernel.org> Cc: "Uladzislau Rezki (Sony)" <urezki(a)gmail.com> Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/kasan.h | 21 +++++++++++++++++++-- mm/kasan/hw_tags.c | 4 ++-- mm/kasan/shadow.c | 6 ++++-- mm/vmalloc.c | 4 ++-- 4 files changed, 27 insertions(+), 8 deletions(-) --- a/include/linux/kasan.h~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/include/linux/kasan.h @@ -596,13 +596,23 @@ static inline void kasan_release_vmalloc #endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */ void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, - kasan_vmalloc_flags_t flags); + kasan_vmalloc_flags_t flags, bool reuse_tag); + +static __always_inline void *kasan_unpoison_vrealloc(const void *start, + unsigned long size, + kasan_vmalloc_flags_t flags) +{ + if (kasan_enabled()) + return __kasan_unpoison_vmalloc(start, size, flags, true); + return (void *)start; +} + static __always_inline void *kasan_unpoison_vmalloc(const void *start, unsigned long size, kasan_vmalloc_flags_t flags) { if (kasan_enabled()) - return __kasan_unpoison_vmalloc(start, size, flags); + return __kasan_unpoison_vmalloc(start, size, flags, false); return (void *)start; } @@ -629,6 +639,13 @@ static inline void kasan_release_vmalloc unsigned long free_region_end, unsigned long flags) { } +static inline void *kasan_unpoison_vrealloc(const void *start, + unsigned long size, + kasan_vmalloc_flags_t flags) +{ + return (void *)start; +} + static inline void *kasan_unpoison_vmalloc(const void *start, unsigned long size, kasan_vmalloc_flags_t flags) --- a/mm/kasan/hw_tags.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/mm/kasan/hw_tags.c @@ -317,7 +317,7 @@ static void init_vmalloc_pages(const voi } void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, - kasan_vmalloc_flags_t flags) + kasan_vmalloc_flags_t flags, bool reuse_tag) { u8 tag; unsigned long redzone_start, redzone_size; @@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const voi return (void *)start; } - tag = kasan_random_tag(); + tag = reuse_tag ? get_tag(start) : kasan_random_tag(); start = set_tag(start, tag); /* Unpoison and initialize memory up to size. */ --- a/mm/kasan/shadow.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/mm/kasan/shadow.c @@ -625,7 +625,7 @@ void kasan_release_vmalloc(unsigned long } void *__kasan_unpoison_vmalloc(const void *start, unsigned long size, - kasan_vmalloc_flags_t flags) + kasan_vmalloc_flags_t flags, bool reuse_tag) { /* * Software KASAN modes unpoison both VM_ALLOC and non-VM_ALLOC @@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const voi !(flags & KASAN_VMALLOC_PROT_NORMAL)) return (void *)start; - start = set_tag(start, kasan_random_tag()); + if (!reuse_tag) + start = set_tag(start, kasan_random_tag()); + kasan_unpoison(start, size, false); return (void *)start; } --- a/mm/vmalloc.c~mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan +++ a/mm/vmalloc.c @@ -4175,8 +4175,8 @@ void *vrealloc_node_align_noprof(const v * We already have the bytes available in the allocation; use them. */ if (size <= alloced_size) { - kasan_unpoison_vmalloc(p + old_size, size - old_size, - KASAN_VMALLOC_PROT_NORMAL); + kasan_unpoison_vrealloc(p, size, + KASAN_VMALLOC_PROT_NORMAL | KASAN_VMALLOC_VM_ALLOC); /* * No need to zero memory here, as unused memory will have * already been zeroed at initial allocation time or during _ Patches currently in -mm which might be from jiayuan.chen(a)linux.dev are mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch mm-vmscan-skip-increasing-kswapd_failures-when-reclaim-was-boosted.patch

2 weeks, 6 days

3
3
0 0

[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

3 weeks

1
0
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

3 weeks

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

3 weeks

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

3 weeks

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

3 weeks

2
4
0 0

Loan and Investment offer/ Account Reprofilling

by Gerald Johnson

3 weeks

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

3 weeks

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

3 weeks

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

3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2025