July 2025 - Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] ext4: only dirty folios when data journaling regular files
by Yongjian Sun 10 Jul '25

10 Jul '25

From: Brian Foster <bfoster(a)redhat.com> mainline inclusion from mainline-v6.16-rc1 commit e26268ff1dcae5662c1b96c35f18cfa6ab73d9de category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICK4S2 CVE: CVE-2025-38220 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- fstest generic/388 occasionally reproduces a crash that looks as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ext4_block_zero_page_range+0x30c/0x380 [ext4] ext4_truncate+0x436/0x440 [ext4] ext4_process_orphan+0x5d/0x110 [ext4] ext4_orphan_cleanup+0x124/0x4f0 [ext4] ext4_fill_super+0x262d/0x3110 [ext4] get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x26/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4ed/0x6b0 do_syscall_64+0x82/0x170 ... This occurs when processing a symlink inode from the orphan list. The partial block zeroing code in the truncate path calls ext4_dirty_journalled_data() -> folio_mark_dirty(). The latter calls mapping->a_ops->dirty_folio(), but symlink inodes are not assigned an a_ops vector in ext4, hence the crash. To avoid this problem, update the ext4_dirty_journalled_data() helper to only mark the folio dirty on regular files (for which a_ops is assigned). This also matches the journaling logic in the ext4_symlink() creation path, where ext4_handle_dirty_metadata() is called directly. Fixes: d84c9ebdac1e ("ext4: Mark pages with journalled data dirty") Signed-off-by: Brian Foster <bfoster(a)redhat.com> Link: https://patch.msgid.link/20250516173800.175577-1-bfoster@redhat.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Reviewed-by: Jan Kara <jack(a)suse.cz> Cc: stable(a)kernel.org Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/ext4/inode.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 1e27155797cc..045a7213d6b6 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1019,7 +1019,12 @@ int ext4_walk_page_buffers(handle_t *handle, struct inode *inode, */ static int ext4_dirty_journalled_data(handle_t *handle, struct buffer_head *bh) { - folio_mark_dirty(bh->b_folio); + struct folio *folio = bh->b_folio; + struct inode *inode = folio->mapping->host; + + /* only regular files have a_ops */ + if (S_ISREG(inode->i_mode)) + folio_mark_dirty(folio); return ext4_handle_dirty_metadata(handle, NULL, bh); } -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] Revert "dm-bufio: don't schedule in atomic context"
by Li Lingfeng 10 Jul '25

10 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLINL CVE: NA -------------------------------- This reverts commit 33ba377620edc34fbccd07c7181c282eb0e71c46. There is a wrong adapt for commit ("dm-bufio: don't schedule in atomic context"). Function __try_evict_buffer can return false, `freed` may keep no change for a long time and so softlockup happened. The fix tag for commit ("dm-bufio: don't schedule in atomic context") is totally wrong, it's commit b32d45824aa7 ("dm bufio: Add DM_BUFIO_CLIENT_NO_SLEEP flag") that first introduce sleep in atomic bug, and has not been backport, so revert this wrong adapt patch to fix the softlockup. Moreover, calling dm_bufio_unlock() in __scan() may also cause a UAF vulnerability. Before releasing the lock, tmp retains a pointer to a dm_buffer obtained from the LRU linked list. After releasing the lock, this dm_buffer might be freed. When the process is rescheduled and reacquires the lock to access this dm_buffer, a UAF is triggered. In versions incorporating commit 450e8dee51aa ("dm bufio: improve concurrent IO performance"), releasing the lock in __scan() no longer risks UAF because the resource acquisition mechanism has been modified: no volatile pointers are held before context switching, eliminating post-resumption access to potentially freed resources. Fixes: 33ba377620ed ("dm-bufio: don't schedule in atomic context") Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/md/dm-bufio.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c index 4016d2c191ce..0b41e1db4de9 100644 --- a/drivers/md/dm-bufio.c +++ b/drivers/md/dm-bufio.c @@ -63,8 +63,6 @@ #define LIST_DIRTY 1 #define LIST_SIZE 2 -#define SCAN_RESCHED_CYCLE 16 - /* * Linking of buffers: * All buffers are linked to cache_hash with their hash_list field. @@ -1601,12 +1599,7 @@ static unsigned long __scan(struct dm_bufio_client *c, unsigned long nr_to_scan, freed++; if (!--nr_to_scan || ((count - freed) <= retain_target)) return freed; - - if (unlikely(freed % SCAN_RESCHED_CYCLE == 0)) { - dm_bufio_unlock(c); - cond_resched(); - dm_bufio_lock(c); - } + cond_resched(); } } return freed; -- 2.31.1

2 1

[PATCH OLK-6.6] drm/amd/display: Fix && vs || typos
by Xinyu Zheng 10 Jul '25

10 Jul '25

From: Dan Carpenter <dan.carpenter(a)linaro.org> mainline inclusion from mainline-v6.8-rc5 commit 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 category: bugfix bugzilla: 198751 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- These ANDs should be ORs or it will lead to a NULL dereference. Fixes: 45716b01839a ("drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'") Fixes: 2de9bab01e39 ("drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()'") Reviewed-by: Anthony Koo <anthony.koo(a)amd.com> Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Conflicts: drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c [lc: adjust context] Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c index 840dfd237247..990374857d9a 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c @@ -211,7 +211,7 @@ void dcn21_set_pipe(struct pipe_ctx *pipe_ctx) struct dmcu *dmcu = pipe_ctx->stream->ctx->dc->res_pool->dmcu; uint32_t otg_inst; - if (!abm && !tg && !panel_cntl) + if (!abm || !tg || !panel_cntl) return; otg_inst = tg->inst; @@ -245,7 +245,7 @@ bool dcn21_set_backlight_level(struct pipe_ctx *pipe_ctx, struct panel_cntl *panel_cntl = pipe_ctx->stream->link->panel_cntl; uint32_t otg_inst; - if (!abm && !tg && !panel_cntl) + if (!abm || !tg || !panel_cntl) return false; otg_inst = tg->inst; -- 2.34.1

2 1

[PATCH OLK-6.6] usb: dwc3: gadget: check that event count does not exceed event buffer length
by Xia Fukun 10 Jul '25

10 Jul '25

From: Frode Isaksen <frode(a)meta.com> stable inclusion from stable-v6.6.89 commit c4d80e41cb42008dceb35e5dbf52574d93beac0d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC6BOI CVE: CVE-2025-37810 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 63ccd26cd1f6600421795f6ca3e625076be06c9f upstream. The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34 Signed-off-by: Frode Isaksen <frode(a)meta.com> Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable <stable(a)kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/20250403072907.448524-1-fisaksen@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/usb/dwc3/gadget.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index fdaace1564f9..8b2292420581 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -4570,6 +4570,12 @@ static irqreturn_t dwc3_check_event_buf(struct dwc3_event_buffer *evt) if (!count) return IRQ_NONE; + if (count > evt->length) { + dev_err_ratelimited(dwc->dev, "invalid count(%u) > evt->length(%u)\n", + count, evt->length); + return IRQ_NONE; + } + evt->count = count; evt->flags |= DWC3_EVENT_PENDING; -- 2.34.1

2 1

[PATCH OLK-6.6] arm64/mpam: Add quirk for MPAM MSMON_MBWU monitor NRDY bit
by Zeng Heng 10 Jul '25

10 Jul '25

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/IAJLCY -------------------------------- Fix the issue where the MSMON_MBWU monitor does not properly update statistics results on certain platforms due to the absence of NRDY bit functionality. On such platforms, when configuring a new partid, the NRDY bit remains 0, causing the monitor to remain 0 or the previous statistics result. For the specified chip vendors, assume the NRDY bit is set on the time configuration update and force the software to re-read the statistics result to ensure accurate data. Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_devices.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/platform/mpam/mpam_devices.c b/drivers/platform/mpam/mpam_devices.c index 4da106d1135b..93f8efe9b3ff 100644 --- a/drivers/platform/mpam/mpam_devices.c +++ b/drivers/platform/mpam/mpam_devices.c @@ -937,6 +937,14 @@ bool resctrl_arch_would_mbm_overflow(void) return read_cpuid_implementor() != ARM_CPU_IMP_HISI; } +static bool mpam_ris_has_nrdy_bit(struct mpam_msc_ris *ris) +{ + if (ris->comp->class->type == MPAM_CLASS_MEMORY) + return read_cpuid_implementor() != ARM_CPU_IMP_HISI; + + return true; +} + static void __ris_msmon_read(void *arg) { bool nrdy = false; @@ -1011,6 +1019,9 @@ static void __ris_msmon_read(void *arg) now = FIELD_GET(MSMON___VALUE, now); } + if (config_mismatch && !mpam_ris_has_nrdy_bit(ris)) + nrdy = true; + if (nrdy) break; -- 2.25.1

2 1

[PATCH OLK-6.6] arm64/mpam: Add quirk for MPAM MSMON_MBWU monitor NRDY bit
by Zeng Heng 10 Jul '25

10 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAJLCY -------------------------------- Fix the issue where the MSMON_MBWU monitor does not properly update statistics results on certain platforms due to the absence of NRDY bit functionality. On such platforms, when configuring a new partid, the NRDY bit remains 0, causing the monitor to remain 0 or the previous statistics result. For the specified chip vendors, assume the NRDY bit is set on the time configuration update and force the software to re-read the statistics result to ensure accurate data. Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_devices.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/platform/mpam/mpam_devices.c b/drivers/platform/mpam/mpam_devices.c index 4da106d1135b..93f8efe9b3ff 100644 --- a/drivers/platform/mpam/mpam_devices.c +++ b/drivers/platform/mpam/mpam_devices.c @@ -937,6 +937,14 @@ bool resctrl_arch_would_mbm_overflow(void) return read_cpuid_implementor() != ARM_CPU_IMP_HISI; } +static bool mpam_ris_has_nrdy_bit(struct mpam_msc_ris *ris) +{ + if (ris->comp->class->type == MPAM_CLASS_MEMORY) + return read_cpuid_implementor() != ARM_CPU_IMP_HISI; + + return true; +} + static void __ris_msmon_read(void *arg) { bool nrdy = false; @@ -1011,6 +1019,9 @@ static void __ris_msmon_read(void *arg) now = FIELD_GET(MSMON___VALUE, now); } + if (config_mismatch && !mpam_ris_has_nrdy_bit(ris)) + nrdy = true; + if (nrdy) break; -- 2.25.1

2 1

[PATCH OLK-6.6] mcb: fix a double free bug in chameleon_parse_gdd()
by Xia Fukun 10 Jul '25

10 Jul '25

From: Haoxiang Li <haoxiang_li2024(a)163.com> stable inclusion from stable-v6.6.89 commit 96838eb1836fd372e42be5db84f0b333b65146a6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC6BK8 CVE: CVE-2025-37817 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 7c7f1bfdb2249f854a736d9b79778c7e5a29a150 upstream. In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev' would be released in mcb_device_register() via put_device(). Thus, goto 'err' label and free 'mdev' again causes a double free. Just return if mcb_device_register() fails. Fixes: 3764e82e5150 ("drivers: Introduce MEN Chameleon Bus") Cc: stable <stable(a)kernel.org> Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> Signed-off-by: Johannes Thumshirn <jth(a)kernel.org> Link: https://lore.kernel.org/r/6201d09e2975ae5789879f79a6de4c38de9edd4a.17415962… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/mcb/mcb-parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mcb/mcb-parse.c b/drivers/mcb/mcb-parse.c index 1ae37e693de0..d080e21df666 100644 --- a/drivers/mcb/mcb-parse.c +++ b/drivers/mcb/mcb-parse.c @@ -101,7 +101,7 @@ static int chameleon_parse_gdd(struct mcb_bus *bus, ret = mcb_device_register(bus, mdev); if (ret < 0) - goto err; + return ret; return 0; -- 2.34.1

2 1

[PATCH OLK-5.10] usb: cdns3: fix random warning message when driver load
by Guo Mengqi 10 Jul '25

10 Jul '25

From: Frank Li <Frank.Li(a)nxp.com> stable inclusion from stable-v5.15.63 commit 8e142744f0e96abc69ccd99e6d6c7eb662267f21 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICG794 CVE: CVE-2022-50151 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8659ab3d936fcf0084676f98b75b317017aa8f82 ] Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dump_backtrace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4.179613] kmalloc_fix_flags+0x60/0x88 [ 4.183550] new_slab+0x334/0x370 [ 4.186878] ___slab_alloc.part.108+0x4d4/0x748 [ 4.191419] __slab_alloc.isra.109+0x30/0x78 [ 4.195702] kmem_cache_alloc+0x40c/0x420 [ 4.199725] dma_pool_alloc+0xac/0x1f8 [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0 pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags) { ... page = kmalloc(sizeof(*page), mem_flags); page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... } kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_DMA32 flags. kmall_fix_flags() report warning. GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle DMA memory region correctly by pool->dev. GFP_DMA32 can be removed safely. Signed-off-by: Frank Li <Frank.Li(a)nxp.com> Link: https://lore.kernel.org/r/20220609154456.2871672-1-Frank.Li@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/usb/cdns3/gadget.c drivers/usb/cdns3/cdns3-gadget.c [file name is different] Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/usb/cdns3/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c index eeea892248b5..2bd24fb806fb 100644 --- a/drivers/usb/cdns3/gadget.c +++ b/drivers/usb/cdns3/gadget.c @@ -237,7 +237,7 @@ int cdns3_allocate_trb_pool(struct cdns3_endpoint *priv_ep) priv_ep->trb_pool = dma_alloc_coherent(priv_dev->sysdev, ring_size, &priv_ep->trb_pool_dma, - GFP_DMA32 | GFP_ATOMIC); + GFP_ATOMIC); if (!priv_ep->trb_pool) return -ENOMEM; -- 2.22.0

2 1

[PATCH OLK-5.10] memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
by Guo Mengqi 10 Jul '25

10 Jul '25

From: Luo Qiu <luoqiu(a)kylinsec.com.cn> stable inclusion from stable-v5.10.236 commit 9dfaf4d723c62bda8d9d1340e2e78acf0c190439 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC1PGY CVE: CVE-2025-22020 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4676741a3464b300b486e70585c3c9b692be1632 upstream. This fixes the following crash: ================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241 CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfx___schedule+0x10/0x10 ? kick_pool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? __pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 The buggy address belongs to the object at ffff888136335000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 896 bytes inside of freed 2048-byte region [ffff888136335000, ffff888136335800) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x136330 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f5(slab) raw: 0017ffffc0000040 ffff888100042f00 ffffea000417a000 dead000000000002 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 0017ffffc0000040 ffff888100042f00 ffffea000417a000 dead000000000002 head: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 0017ffffc0000003 ffffea0004d8cc01 ffffffffffffffff 0000000000000000 head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888136335280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888136335300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888136335380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888136335400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888136335480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Fixes: 6827ca573c03 ("memstick: rtsx_usb_ms: Support runtime power management") Signed-off-by: Luo Qiu <luoqiu(a)kylinsec.com.cn> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/4B7BC3E6E291E6F2+20250317101438.25650-1-luoqiu@ky… Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/memstick/host/rtsx_usb_ms.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/memstick/host/rtsx_usb_ms.c b/drivers/memstick/host/rtsx_usb_ms.c index 29271ad4728a..dec279845a75 100644 --- a/drivers/memstick/host/rtsx_usb_ms.c +++ b/drivers/memstick/host/rtsx_usb_ms.c @@ -813,6 +813,7 @@ static int rtsx_usb_ms_drv_remove(struct platform_device *pdev) host->eject = true; cancel_work_sync(&host->handle_req); + cancel_delayed_work_sync(&host->poll_card); mutex_lock(&host->host_mutex); if (host->req) { -- 2.22.0

2 1

[PATCH OLK-5.10] scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI
by Guo Mengqi 10 Jul '25

10 Jul '25

From: James Smart <jsmart2021(a)gmail.com> mainline inclusion from mainline-v5.19-rc1 commit 577a942df3de2666f6947bdd3a5c9e8d30073424 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBP6SH CVE: CVE-2022-49535 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit 577a942df3de2666f6947bdd3a5c9e8d30073424 ] If lpfc_issue_els_flogi() fails and returns non-zero status, the node reference count is decremented to trigger the release of the nodelist structure. However, if there is a prior registration or dev-loss-evt work pending, the node may be released prematurely. When dev-loss-evt completes, the released node is referenced causing a use-after-free null pointer dereference. Similarly, when processing non-zero ELS PLOGI completion status in lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport registration before triggering node removal. If dev-loss-evt work is pending, the node may be released prematurely and a subsequent call to lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference. Add test for pending dev-loss before decrementing the node reference count for FLOGI, PLOGI, PRLI, and ADISC handling. Link: https://lore.kernel.org/r/20220412222008.126521-9-jsmart2021@gmail.com Co-developed-by: Justin Tee <justin.tee(a)broadcom.com> Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Signed-off-by: James Smart <jsmart2021(a)gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/scsi/lpfc/lpfc_els.c [Some contexts are not in this version] Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/scsi/lpfc/lpfc_els.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c index deb9202307a9..f659a4014da3 100644 --- a/drivers/scsi/lpfc/lpfc_els.c +++ b/drivers/scsi/lpfc/lpfc_els.c @@ -1484,10 +1484,12 @@ lpfc_initial_flogi(struct lpfc_vport *vport) } if (lpfc_issue_els_flogi(vport, ndlp, 0)) { - /* This decrement of reference count to node shall kick off - * the release of the node. + /* A node reference should be retained while registered with a + * transport or dev-loss-evt work is pending. + * Otherwise, decrement node reference to trigger release. */ - lpfc_nlp_put(ndlp); + if (!(ndlp->nlp_flag & NLP_IN_DEV_LOSS)) + lpfc_nlp_put(ndlp); return 0; } return 1; @@ -1531,10 +1533,12 @@ lpfc_initial_fdisc(struct lpfc_vport *vport) } if (lpfc_issue_els_fdisc(vport, ndlp, 0)) { - /* decrement node reference count to trigger the release of - * the node. + /* A node reference should be retained while registered with a + * transport or dev-loss-evt work is pending. + * Otherwise, decrement node reference to trigger release. */ - lpfc_nlp_put(ndlp); + if (!(ndlp->nlp_flag & NLP_IN_DEV_LOSS)) + lpfc_nlp_put(ndlp); return 0; } return 1; -- 2.22.0

2 1