- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] arm64/mpam: Fix L2 MBWU monitor multiplexing issue
by Zeng Heng 25 Oct '25

25 Oct '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID29QH -------------------------------- The MBWU monitor performs long-term cumulative statistics on bandwidth for a specified PARTID. However, the number of L2 physical monitors is very limited. To support the expanded quantities of PARTIDs and PMGs, the MBWU monitors need to multiplex. Therefore, when a monitor tracks a new PARTID or PMG, which means a change in monitor configuration is detected, the accumulated correction should set to zero. Fixes: 21ac9fc8f275 ("arm_mpam: Track bandwidth counter state for overflow and power management") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_devices.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/platform/mpam/mpam_devices.c b/drivers/platform/mpam/mpam_devices.c index c2e58fc4c0e8..ae6791b05e8a 100644 --- a/drivers/platform/mpam/mpam_devices.c +++ b/drivers/platform/mpam/mpam_devices.c @@ -1011,7 +1011,7 @@ static void __ris_msmon_read(void *arg) bool reset_on_next_read = false; struct mpam_msc_ris *ris = m->ris; struct mpam_msc *msc = m->ris->msc; - struct msmon_mbwu_state *mbwu_state; + struct msmon_mbwu_state *mbwu_state = NULL; u32 mon_sel, ctl_val, flt_val, cur_ctl, cur_flt; lockdep_assert_held(&msc->lock); @@ -1043,8 +1043,14 @@ static void __ris_msmon_read(void *arg) config_mismatch = cur_flt != flt_val || cur_ctl != (ctl_val | MSMON_CFG_x_CTL_EN); - if (config_mismatch || reset_on_next_read) + if (config_mismatch || reset_on_next_read) { write_msmon_ctl_flt_vals(m, ctl_val, flt_val); + if (mbwu_state) { + mbwu_state->prev_val = 0; + mbwu_state->correction = 0; + mbwu_overflow = false; + } + } /* * Selects the monitor instance associated to the specified PARTID -- 2.25.1

2 1

[PATCH OLK-6.6 0/2] arm64/mpam: Fix MBWU monitor overflow handling
by Zeng Heng 25 Oct '25

25 Oct '25

Zeng Heng (2): arm64/mpam: Fix MBWU monitor overflow handling arm64/mpam: Print MPAM register operation for debug drivers/platform/mpam/mpam_devices.c | 29 ++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS] posix-timers: Ensure timer ID search-loop limit is valid
by Jinjie Ruan 25 Oct '25

25 Oct '25

From: Thomas Gleixner <tglx(a)linutronix.de> stable inclusion from stable-v4.19.291 commit 9ea26a8494a0a9337e7415eafd6f3ed940327dc5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID33F2 CVE: CVE-2023-53728 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8ce8849dd1e78dadcee0ec9acbd259d239b7069f ] posix_timer_add() tries to allocate a posix timer ID by starting from the cached ID which was stored by the last successful allocation. This is done in a loop searching the ID space for a free slot one by one. The loop has to terminate when the search wrapped around to the starting point. But that's racy vs. establishing the starting point. That is read out lockless, which leads to the following problem: CPU0 CPU1 posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0; So CPU1 can observe a negative start value, i.e. -1, and the loop break never happens because the condition can never be true: if (sig->posix_timer_id == start) break; While this is unlikely to ever turn into an endless loop as the ID space is huge (INT_MAX), the racy read of the start value caught the attention of KCSAN and Dmitry unearthed that incorrectness. Rewrite it so that all id operations are under the hash lock. Reported-by: syzbot+5c54bd3eb218bb595aa9(a)syzkaller.appspotmail.com Reported-by: Dmitry Vyukov <dvyukov(a)google.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Frederic Weisbecker <frederic(a)kernel.org> Link: https://lore.kernel.org/r/87bkhzdn6g.ffs@tglx Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: include/linux/sched/signal.h [ conflict because of kabi change. ] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- include/linux/sched/signal.h | 4 ++++ kernel/time/posix-timers.c | 31 ++++++++++++++++++------------- 2 files changed, 22 insertions(+), 13 deletions(-) diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h index 8bde85ac0e77..66afd36b7de9 100644 --- a/include/linux/sched/signal.h +++ b/include/linux/sched/signal.h @@ -128,7 +128,11 @@ struct signal_struct { #ifdef CONFIG_POSIX_TIMERS /* POSIX.1b Interval Timers */ +#ifdef __GENKSYMS__ int posix_timer_id; +#else + unsigned int next_posix_timer_id; +#endif struct list_head posix_timers; /* ITIMER_REAL timer for the process */ diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c index d86fdabc5748..9b22171f7339 100644 --- a/kernel/time/posix-timers.c +++ b/kernel/time/posix-timers.c @@ -159,25 +159,30 @@ static struct k_itimer *posix_timer_by_id(timer_t id) static int posix_timer_add(struct k_itimer *timer) { struct signal_struct *sig = current->signal; - int first_free_id = sig->posix_timer_id; struct hlist_head *head; - int ret = -ENOENT; + unsigned int cnt, id; - do { + /* + * FIXME: Replace this by a per signal struct xarray once there is + * a plan to handle the resulting CRIU regression gracefully. + */ + for (cnt = 0; cnt <= INT_MAX; cnt++) { spin_lock(&hash_lock); - head = &posix_timers_hashtable[hash(sig, sig->posix_timer_id)]; - if (!__posix_timers_find(head, sig, sig->posix_timer_id)) { + id = sig->next_posix_timer_id; + + /* Write the next ID back. Clamp it to the positive space */ + sig->next_posix_timer_id = (id + 1) & INT_MAX; + + head = &posix_timers_hashtable[hash(sig, id)]; + if (!__posix_timers_find(head, sig, id)) { hlist_add_head_rcu(&timer->t_hash, head); - ret = sig->posix_timer_id; + spin_unlock(&hash_lock); + return id; } - if (++sig->posix_timer_id < 0) - sig->posix_timer_id = 0; - if ((sig->posix_timer_id == first_free_id) && (ret == -ENOENT)) - /* Loop over all possible ids completed */ - ret = -EAGAIN; spin_unlock(&hash_lock); - } while (ret == -ENOENT); - return ret; + } + /* POSIX return code when no timer ID could be allocated */ + return -EAGAIN; } static inline void unlock_timer(struct k_itimer *timr, unsigned long flags) -- 2.34.1

2 1

[PATCH OLK-6.6] cpu/SMT: recover global num_threads after disable smt switch fail
by Bowen You 25 Oct '25

25 Oct '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID3F7S CVE: NA ------------------------------------------------- When executing `echo off > /sys/devices/system/cpu/smt/control`, if `cpuhp_smt_disable` fails, a "resource busy" error is reported. However, the global variable `cpu_smt_num_threads` is incorrectly updated to the target value despite the failure. If SMT is subsequently disabled again, the command will not take effect due to a state machine inconsistency. To recover functionality, `echo on > /sys/devices/system/cpu/smt/control` must be executed manually. This commit adds exception handling to restore `cpu_smt_num_threads` to its original value when `cpuhp_smt_disable` fails, ensuring proper state management. Fixes: 7f48405c3c34 ("cpu/SMT: Allow enabling partial SMT states via sysfs") Signed-off-by: Bowen You <youbowen2(a)huawei.com> --- kernel/cpu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/cpu.c b/kernel/cpu.c index 88e81b8b1700..e5ebc498e328 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -2934,6 +2934,9 @@ __store_smt_control(struct device *dev, struct device_attribute *attr, else if (num_threads < orig_threads || force_off) ret = cpuhp_smt_disable(ctrlval); + if (ret) + cpu_smt_num_threads = orig_threads; + unlock_device_hotplug(); return ret ? ret : count; } -- 2.34.1

2 1

[PATCH OLK-5.10] i40e: fix idx validation in config queues msg
by Fanhua Li 25 Oct '25

25 Oct '25

From: Lukasz Czapnik <lukasz.czapnik(a)intel.com> stable inclusion from stable-v5.10.245 commit f5f91d164af22e7147130ef8bebbdb28d8ecc6e2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ID2290 CVE: CVE-2025-39971 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit f1ad24c5abe1eaef69158bac1405a74b3c365115 ] Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40e_vc_config_queues_msg(). Fixes: c27eac48160d ("i40e: Enable ADq and create queue channel/s on VF") Cc: stable(a)vger.kernel.org Signed-off-by: Lukasz Czapnik <lukasz.czapnik(a)intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Signed-off-by: Przemek Kitszel <przemyslaw.kitszel(a)intel.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Tested-by: Kamakshi Nellore <nellorex.kamakshi(a)intel.com> (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> [ Adjust context ] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c index 4f23243bbfbb6..3ce6d18cc2e5e 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c @@ -2326,7 +2326,7 @@ static int i40e_vc_config_queues_msg(struct i40e_vf *vf, u8 *msg) } if (vf->adq_enabled) { - if (idx >= ARRAY_SIZE(vf->ch)) { + if (idx >= vf->num_tc) { aq_ret = I40E_ERR_NO_AVAILABLE_VSI; goto error_param; } @@ -2347,7 +2347,7 @@ static int i40e_vc_config_queues_msg(struct i40e_vf *vf, u8 *msg) * to its appropriate VSIs based on TC mapping */ if (vf->adq_enabled) { - if (idx >= ARRAY_SIZE(vf->ch)) { + if (idx >= vf->num_tc) { aq_ret = I40E_ERR_NO_AVAILABLE_VSI; goto error_param; } -- 2.43.0

2 1

[PATCH OLK-6.6] fs/notify: call exportfs_encode_fid with s_umount
by Wang Zhaolong 25 Oct '25

25 Oct '25

From: Jakub Acs <acsjakub(a)amazon.de> mainline inclusion from mainline-v6.18 commit a7c4bb43bfdc2b9f06ee9d036028ed13a83df42a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID2VH3 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr. This issue was found by syzkaller. Race Condition Diagram: Thread 1 Thread 2 -------- -------- generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL | | vfs_read() | inotify_fdinfo() | * inode get from mark * | show_mark_fhandle(m, inode) | exportfs_encode_fid(inode, ..) | ovl_encode_fh(inode, ..) | ovl_check_encode_origin(inode) | * deref i_sb->s_root * | | v fsnotify_sb_delete(sb) Which then leads to: [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none) <snip registers, unreliable trace> [ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240 IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path. Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock. This form of fix was suggested by Amir in [1]. [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJ… Fixes: c45beebfde34 ("ovl: support encoding fid from inode with no alias") Signed-off-by: Jakub Acs <acsjakub(a)amazon.de> Cc: Jan Kara <jack(a)suse.cz> Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: Miklos Szeredi <miklos(a)szeredi.hu> Cc: Christian Brauner <brauner(a)kernel.org> Cc: linux-unionfs(a)vger.kernel.org Cc: linux-fsdevel(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> Conflicts: fs/notify/fdinfo.c [Conflicts with mainline commit 4d69c58ef2e4 ("fsnotify: Avoid -Wflex-array-member-not-at-end warning").] Signed-off-by: Wang Zhaolong <wangzhaolong(a)huaweicloud.com> --- fs/notify/fdinfo.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c index 26655572975d..1aa7de55094c 100644 --- a/fs/notify/fdinfo.c +++ b/fs/notify/fdinfo.c @@ -15,10 +15,11 @@ #include "inotify/inotify.h" #include "fanotify/fanotify.h" #include "fdinfo.h" #include "fsnotify.h" +#include "../internal.h" #if defined(CONFIG_PROC_FS) #if defined(CONFIG_INOTIFY_USER) || defined(CONFIG_FANOTIFY) @@ -48,11 +49,16 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode) int size, ret, i; f.handle.handle_bytes = sizeof(f.pad); size = f.handle.handle_bytes >> 2; + if (!super_trylock_shared(inode->i_sb)) + return; + ret = exportfs_encode_fid(inode, (struct fid *)f.handle.f_handle, &size); + up_read(&inode->i_sb->s_umount); + if ((ret == FILEID_INVALID) || (ret < 0)) return; f.handle.handle_type = ret; f.handle.handle_bytes = size * sizeof(u32); -- 2.34.3

2 1

[PATCH OLK-6.6 v3 00/38] Support xfs atomic write of COW
by Long Li 25 Oct '25

25 Oct '25

The software solution supports XFS atomic write, but the hardware solution does not fully support it. Christoph Hellwig (1): xfs: cleanup xfs_vn_getattr Darrick J. Wong (5): xfs: add helpers to compute log item overhead xfs: add helpers to compute transaction reservation for finishing intent items xfs: separate out setting buftarg atomic writes limits xfs: ignore HW which cannot atomic write a single block xfs: allow sysadmins to specify a maximum atomic write limit at mount time John Garry (30): block: Pass blk_queue_get_max_sectors() a request pointer block: Generalize chunk_sectors support as boundary support block: Add core atomic write support block: Call blkdev_dio_unaligned() from blkdev_direct_IO() block: Add fops atomic write support block/fs: Pass an iocb to generic_atomic_write_valid() fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid() block: Add bdev atomic write limits helpers fs: Export generic_atomic_write_valid() fs: iomap: Atomic write support xfs: Support atomic write for statx xfs: Validate atomic writes xfs: Support setting FMODE_CAN_ATOMIC_WRITE iomap: Minor code simplification in iomap_dio_bio_iter() iomap: Rename IOMAP_ATOMIC -> IOMAP_ATOMIC_HW iomap: Support SW-based atomic writes iomap: inline iomap_dio_bio_opflags() iomap: comment on atomic write checks in iomap_dio_bio_iter() iomap: rework IOMAP atomic flags fs: add atomic write unit max opt to statx xfs: rename xfs_inode_can_atomicwrite() -> xfs_inode_can_hw_atomic_write() xfs: allow block allocator to take an alignment hint xfs: refactor xfs_reflink_end_cow_extent() xfs: refine atomic write size check in xfs_file_write_iter() xfs: add xfs_atomic_write_cow_iomap_begin() xfs: add large atomic writes checks in xfs_direct_write_iomap_begin() xfs: commit CoW-based atomic writes atomically xfs: add xfs_file_dio_write_atomic() xfs: add xfs_calc_atomic_write_unit_max() xfs: update atomic write limits Prasad Singamsetty (2): fs: Initial atomic write support fs: Add initial atomic write support info to statx Documentation/ABI/stable/sysfs-block | 53 +++++ block/blk-core.c | 22 ++ block/blk-merge.c | 67 +++++- block/blk-mq.c | 2 +- block/blk-settings.c | 88 ++++++++ block/blk-sysfs.c | 33 +++ block/blk.h | 9 +- block/fops.c | 51 +++-- drivers/md/dm.c | 2 +- fs/aio.c | 8 +- fs/btrfs/ioctl.c | 2 +- fs/iomap/direct-io.c | 144 +++++++------ fs/iomap/trace.h | 3 +- fs/read_write.c | 22 +- fs/stat.c | 35 ++++ fs/xfs/libxfs/xfs_bmap.c | 5 + fs/xfs/libxfs/xfs_bmap.h | 6 +- fs/xfs/libxfs/xfs_log_rlimit.c | 3 + fs/xfs/libxfs/xfs_trans_resv.c | 291 +++++++++++++++++++++++++-- fs/xfs/libxfs/xfs_trans_resv.h | 21 ++ fs/xfs/xfs_bmap_item.c | 10 + fs/xfs/xfs_bmap_item.h | 3 + fs/xfs/xfs_buf.c | 37 +++- fs/xfs/xfs_buf.h | 6 +- fs/xfs/xfs_buf_item.c | 19 ++ fs/xfs/xfs_buf_item.h | 3 + fs/xfs/xfs_extfree_item.c | 10 + fs/xfs/xfs_extfree_item.h | 3 + fs/xfs/xfs_file.c | 87 +++++++- fs/xfs/xfs_inode.h | 5 + fs/xfs/xfs_iomap.c | 195 +++++++++++++++++- fs/xfs/xfs_iomap.h | 1 + fs/xfs/xfs_iops.c | 101 +++++++++- fs/xfs/xfs_iops.h | 3 + fs/xfs/xfs_log_cil.c | 4 +- fs/xfs/xfs_log_priv.h | 13 ++ fs/xfs/xfs_mount.c | 126 ++++++++++++ fs/xfs/xfs_mount.h | 17 ++ fs/xfs/xfs_refcount_item.c | 10 + fs/xfs/xfs_refcount_item.h | 3 + fs/xfs/xfs_reflink.c | 146 +++++++++++--- fs/xfs/xfs_reflink.h | 5 + fs/xfs/xfs_rmap_item.c | 10 + fs/xfs/xfs_rmap_item.h | 3 + fs/xfs/xfs_super.c | 64 +++++- fs/xfs/xfs_trace.h | 108 ++++++++++ include/linux/blk_types.h | 8 +- include/linux/blkdev.h | 84 +++++++- include/linux/fs.h | 19 +- include/linux/iomap.h | 5 + include/linux/stat.h | 4 + include/uapi/linux/fs.h | 5 +- include/uapi/linux/stat.h | 13 +- io_uring/rw.c | 8 +- 54 files changed, 1820 insertions(+), 185 deletions(-) -- 2.39.2

2 39

[PATCH OLK-6.6] regulator: core: fix NULL dereference on unbind due to stale coupling data
by Chen Ridong 25 Oct '25

25 Oct '25

From: Alessandro Carminati <acarmina(a)redhat.com> stable inclusion from stable-v6.6.101 commit 233d3c54c9620e95193923859ea1d0b0f5d748ca category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICTWCN CVE: CVE-2025-38668 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ca46946a482238b0cdea459fb82fc837fb36260e ] Failing to reset coupling_desc.n_coupled after freeing coupled_rdevs can lead to NULL pointer dereference when regulators are accessed post-unbind. This can happen during runtime PM or other regulator operations that rely on coupling metadata. For example, on ridesx4, unbinding the 'reg-dummy' platform device triggers a panic in regulator_lock_recursive() due to stale coupling state. Ensure n_coupled is set to 0 to prevent access to invalid pointers. Signed-off-by: Alessandro Carminati <acarmina(a)redhat.com> Link: https://patch.msgid.link/20250626083809.314842-1-acarmina@redhat.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Chen Ridong <chenridong(a)huawei.com> --- drivers/regulator/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index d2e21dc61dd7d..1d49612eeb7e5 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -5422,6 +5422,7 @@ static void regulator_remove_coupling(struct regulator_dev *rdev) ERR_PTR(err)); } + rdev->coupling_desc.n_coupled = 0; kfree(rdev->coupling_desc.coupled_rdevs); rdev->coupling_desc.coupled_rdevs = NULL; } -- 2.34.1

2 1

[PATCH OLK-6.6] HID: multitouch: fix slab out-of-bounds access in mt_report_fixup()
by Chen Ridong 25 Oct '25

25 Oct '25

From: Qasim Ijaz <qasdev00(a)gmail.com> stable inclusion from stable-v6.6.104 commit d4e6e2680807671e1c73cd6a986b33659ce92f2b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICXO12 CVE: CVE-2025-39806 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0379eb8691b9c4477da0277ae0832036ca4410b4 upstream. A malicious HID device can trigger a slab out-of-bounds during mt_report_fixup() by passing in report descriptor smaller than 607 bytes. mt_report_fixup() attempts to patch byte offset 607 of the descriptor with 0x25 by first checking if byte offset 607 is 0x15 however it lacks bounds checks to verify if the descriptor is big enough before conducting this check. Fix this bug by ensuring the descriptor size is at least 608 bytes before accessing it. Below is the KASAN splat after the out of bounds access happens: [ 13.671954] ================================================================== [ 13.672667] BUG: KASAN: slab-out-of-bounds in mt_report_fixup+0x103/0x110 [ 13.673297] Read of size 1 at addr ffff888103df39df by task kworker/0:1/10 [ 13.673297] [ 13.673297] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0-00005-gec5d573d83f4-dirty #3 [ 13.673297] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/04 [ 13.673297] Call Trace: [ 13.673297] <TASK> [ 13.673297] dump_stack_lvl+0x5f/0x80 [ 13.673297] print_report+0xd1/0x660 [ 13.673297] kasan_report+0xe5/0x120 [ 13.673297] __asan_report_load1_noabort+0x18/0x20 [ 13.673297] mt_report_fixup+0x103/0x110 [ 13.673297] hid_open_report+0x1ef/0x810 [ 13.673297] mt_probe+0x422/0x960 [ 13.673297] hid_device_probe+0x2e2/0x6f0 [ 13.673297] really_probe+0x1c6/0x6b0 [ 13.673297] __driver_probe_device+0x24f/0x310 [ 13.673297] driver_probe_device+0x4e/0x220 [ 13.673297] __device_attach_driver+0x169/0x320 [ 13.673297] bus_for_each_drv+0x11d/0x1b0 [ 13.673297] __device_attach+0x1b8/0x3e0 [ 13.673297] device_initial_probe+0x12/0x20 [ 13.673297] bus_probe_device+0x13d/0x180 [ 13.673297] device_add+0xe3a/0x1670 [ 13.673297] hid_add_device+0x31d/0xa40 [...] Fixes: c8000deb6836 ("HID: multitouch: Add support for GT7868Q") Cc: stable(a)vger.kernel.org Signed-off-by: Qasim Ijaz <qasdev00(a)gmail.com> Reviewed-by: Jiri Slaby <jirislaby(a)kernel.org> Signed-off-by: Jiri Kosina <jkosina(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Chen Ridong <chenridong(a)huawei.com> --- drivers/hid/hid-multitouch.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index 6386043aab0bb..08efe665ae111 100644 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -1448,6 +1448,14 @@ static __u8 *mt_report_fixup(struct hid_device *hdev, __u8 *rdesc, if (hdev->vendor == I2C_VENDOR_ID_GOODIX && (hdev->product == I2C_DEVICE_ID_GOODIX_01E8 || hdev->product == I2C_DEVICE_ID_GOODIX_01E9)) { + if (*size < 608) { + dev_info( + &hdev->dev, + "GT7868Q fixup: report descriptor is only %u bytes, skipping\n", + *size); + return rdesc; + } + if (rdesc[607] == 0x15) { rdesc[607] = 0x25; dev_info( -- 2.34.1

2 1

[PATCH OLK-6.6] fs/resctrl: Re-allocate rmid for the monitor when migrating across control groups
by Zeng Heng 25 Oct '25

25 Oct '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ID29XA -------------------------------- On x86 RDT, RMIDs are completely independent of CLOSIDs, so a monitor group can move between control groups freely without modifying rmid_entry. On ARM64 MPAM, however, a CLOSID owns a slice of RMID space. When migrate the monitor group to another control group, it should therefore re-allocate for a RMID tied to the new CLOSID. If the migrated monitor keeps the old CLOSID, tasks of the monitor will still adopt the previous CLOSID's settings and when the monitor group is later destroyed, the same rmid_entry will be added to the rmid_free_lru list twice, which corrupting the list. Fixes: 8da2b938eb7e ("x86/resctrl: Implement rename op for mon groups") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- fs/resctrl/internal.h | 1 + fs/resctrl/monitor.c | 2 +- fs/resctrl/rdtgroup.c | 17 +++++++++++++++++ 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h index 839fbcf51ed2..0e8865bf012a 100644 --- a/fs/resctrl/internal.h +++ b/fs/resctrl/internal.h @@ -294,5 +294,6 @@ bool has_busy_rmid(struct rdt_domain *d); void __check_limbo(struct rdt_domain *d, bool force_free); void rdt_staged_configs_clear(void); int resctrl_find_cleanest_closid(void); +struct rmid_entry *resctrl_find_free_rmid(u32 closid); #endif /* _FS_RESCTRL_INTERNAL_H */ diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index d10497013638..b651b37e7e65 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -178,7 +178,7 @@ bool has_busy_rmid(struct rdt_domain *d) return find_first_bit(d->rmid_busy_llc, idx_limit) != idx_limit; } -static struct rmid_entry *resctrl_find_free_rmid(u32 closid) +struct rmid_entry *resctrl_find_free_rmid(u32 closid) { struct rmid_entry *itr; u32 itr_idx, cmp_idx; diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index 091dc20d0cc0..4f26c883e893 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -3813,6 +3813,8 @@ static void mongrp_reparent(struct rdtgroup *rdtgrp, list_move_tail(&rdtgrp->mon.crdtgrp_list, &new_prdtgrp->mon.crdtgrp_list); + free_rmid(rdtgrp->closid, rdtgrp->mon.rmid); + rdtgrp->mon.rmid = alloc_rmid(new_prdtgrp->closid); rdtgrp->mon.parent = new_prdtgrp; rdtgrp->closid = new_prdtgrp->closid; @@ -3826,6 +3828,7 @@ static int rdtgroup_rename(struct kernfs_node *kn, struct kernfs_node *new_parent, const char *new_name) { struct rdtgroup *new_prdtgrp; + struct rmid_entry *entry; struct rdtgroup *rdtgrp; cpumask_var_t tmpmask; int ret; @@ -3884,6 +3887,20 @@ static int rdtgroup_rename(struct kernfs_node *kn, goto out; } + /* + * Unlike RDT, the rmid and closid in MPAM have a hierarchical + * relationship. Therefore, first check whether there are still + * free rmids available under the target closid. + */ + if (IS_ENABLED(CONFIG_ARM64_MPAM)) { + entry = resctrl_find_free_rmid(new_prdtgrp->closid); + if (IS_ERR(entry)) { + rdt_last_cmd_puts("Destination has been out of RMIDs\n"); + ret = PTR_ERR(entry); + goto out; + } + } + /* * Allocate the cpumask for use in mongrp_reparent() to avoid the * possibility of failing to allocate it after kernfs_rename() has -- 2.25.1

2 1