- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS 0/2] sch_htb: Fix CVE-2025-37932
by Dong Chenchen 07 Jul '25

07 Jul '25

Fix CVE-2025-37932 in sch_htb Cong Wang (2): sch_htb: make htb_qlen_notify() idempotent sch_htb: make htb_deactivate() idempotent net/sched/sch_htb.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) -- 2.25.1

1 2

[PATCH OLK-6.6] net_sched: red: fix a race in __red_change()
by Luo Gengkun 07 Jul '25

07 Jul '25

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v6.6.94 commit 2a71924ca4af59ffc00f0444732b6cd54b153d0e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICJT90 CVE: CVE-2025-38108 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 85a3e0ede38450ea3053b8c45d28cf55208409b8 ] Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: 0c8d13ac9607 ("net: sched: red: delay destroying child qdisc on replace") Reported-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Suggested-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20250611111515.1983366-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- net/sched/sch_red.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c index 16277b6a0238..3c6b4460cf2c 100644 --- a/net/sched/sch_red.c +++ b/net/sched/sch_red.c @@ -283,7 +283,7 @@ static int __red_change(struct Qdisc *sch, struct nlattr **tb, q->userbits = userbits; q->limit = ctl->limit; if (child) { - qdisc_tree_flush_backlog(q->qdisc); + qdisc_purge_queue(q->qdisc); old_child = q->qdisc; q->qdisc = child; } -- 2.34.1

2 1

[PATCH OLK-5.10] net_sched: red: fix a race in __red_change()
by Luo Gengkun 07 Jul '25

07 Jul '25

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.239 commit a1bf6a4e9264a685b0e642994031f9c5aad72414 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICJT90 CVE: CVE-2025-38108 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 85a3e0ede38450ea3053b8c45d28cf55208409b8 ] Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: 0c8d13ac9607 ("net: sched: red: delay destroying child qdisc on replace") Reported-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Suggested-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20250611111515.1983366-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- net/sched/sch_red.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c index 935d90874b1b..1b69b7b90d85 100644 --- a/net/sched/sch_red.c +++ b/net/sched/sch_red.c @@ -283,7 +283,7 @@ static int __red_change(struct Qdisc *sch, struct nlattr **tb, q->userbits = userbits; q->limit = ctl->limit; if (child) { - qdisc_tree_flush_backlog(q->qdisc); + qdisc_purge_queue(q->qdisc); old_child = q->qdisc; q->qdisc = child; } -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] Fix CVE-2025-38182
by Hongbo Li 07 Jul '25

07 Jul '25

Fix CVE-2025-38182. Ronnie Sahlberg (1): ublk: santizize the arguments from userspace when adding a device drivers/block/ublk_drv.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.34.1

2 2

[PATCH OLK-6.6 v2] mm: respect mmap hint address when aligning for THP
by Tong Tiangen 07 Jul '25

07 Jul '25

From: Kalesh Singh <kaleshsingh(a)google.com> mainline inclusion from mainline-v6.13-rc2 commit 249608ee47132cab3b1adacd9e463548f57bd316 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICK7OL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") updated __get_unmapped_area() to align the start address for the VMA to a PMD boundary if CONFIG_TRANSPARENT_HUGEPAGE=y. It does this by effectively looking up a region that is of size, request_size + PMD_SIZE, and aligning up the start to a PMD boundary. Commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit") opted out of this for 32bit due to regressions in mmap base randomization. Commit d4148aeab412 ("mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes") restricted this to only mmap sizes that are multiples of the PMD_SIZE due to reported regressions in some performance benchmarks -- which seemed mostly due to the reduced spatial locality of related mappings due to the forced PMD-alignment. Another unintended side effect has emerged: When a user specifies an mmap hint address, the THP alignment logic modifies the behavior, potentially ignoring the hint even if a sufficiently large gap exists at the requested hint location. Example Scenario: Consider the following simplified virtual address (VA) space: ... 0x200000-0x400000 --- VMA A 0x400000-0x600000 --- Hole 0x600000-0x800000 --- VMA B ... A call to mmap() with hint=0x400000 and len=0x200000 behaves differently: - Before THP alignment: The requested region (size 0x200000) fits into the gap at 0x400000, so the hint is respected. - After alignment: The logic searches for a region of size 0x400000 (len + PMD_SIZE) starting at 0x400000. This search fails due to the mapping at 0x600000 (VMA B), and the hint is ignored, falling back to arch_get_unmapped_area[_topdown](). In general the hint is effectively ignored, if there is any existing mapping in the below range: [mmap_hint + mmap_size, mmap_hint + mmap_size + PMD_SIZE) This changes the semantics of mmap hint; from ""Respect the hint if a sufficiently large gap exists at the requested location" to "Respect the hint only if an additional PMD-sized gap exists beyond the requested size". This has performance implications for allocators that allocate their heap using mmap but try to keep it "as contiguous as possible" by using the end of the exisiting heap as the address hint. With the new behavior it's more likely to get a much less contiguous heap, adding extra fragmentation and performance overhead. To restore the expected behavior; don't use thp_get_unmapped_area_vmflags() when the user provided a hint address, for anonymous mappings. Note: As Yang Shi pointed out: the issue still remains for filesystems which are using thp_get_unmapped_area() for their get_unmapped_area() op. It is unclear what worklaods will regress for if we ignore THP alignment when the hint address is provided for such file backed mappings -- so this fix will be handled separately. Link: https://lkml.kernel.org/r/20241118214650.3667577-1-kaleshsingh@google.com Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com> Reviewed-by: Rik van Riel <riel(a)surriel.com> Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Yang Shi <yang(a)os.amperecomputing.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Hans Boehm <hboehm(a)google.com> Cc: Lokesh Gidra <lokeshgidra(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/mmap.c [context conflict: 8a0fe564bb2e ("mm: use get_unmapped_area_vmflags()") not merged.] Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- v2: fix commit message checkformat. mm/mmap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index 59f410c03f2b..32799ed58022 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1899,7 +1899,8 @@ get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, * so use shmem's get_unmapped_area in case it can be huge. */ get_area = shmem_get_unmapped_area; - } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { + } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) + && !addr) { /* no hint */ /* Ensures that larger anonymous mappings are THP aligned. */ get_area = thp_get_unmapped_area; } -- 2.25.1

2 1

[PATCH OLK-6.6] octeon_ep: Fix host hang issue during device reboot
by Cai Xinchen 07 Jul '25

07 Jul '25

From: Sathesh B Edara <sedara(a)marvell.com> stable inclusion from stable-v6.6.90 commit 7e1ca1bed3f66e00377f7d2147be390144924276 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC991M CVE: CVE-2025-37933 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 34f42736b325287a7b2ce37e415838f539767bda ] When the host loses heartbeat messages from the device, the driver calls the device-specific ndo_stop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndo_stop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, dev_close should be called instead of the device-specific stop function.dev_close internally calls ndo_stop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndo_stop is not called. Fixes: 5cb96c29aa0e ("octeon_ep: add heartbeat monitor") Signed-off-by: Sathesh B Edara <sedara(a)marvell.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250429114624.19104-1-sedara@marvell.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- drivers/net/ethernet/marvell/octeon_ep/octep_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c index 6f1fe7e283d4..7a30095b3486 100644 --- a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c @@ -917,7 +917,7 @@ static void octep_hb_timeout_task(struct work_struct *work) miss_cnt); rtnl_lock(); if (netif_running(oct->netdev)) - octep_stop(oct->netdev); + dev_close(oct->netdev); rtnl_unlock(); } -- 2.34.1

2 1

[PATCH OLK-6.6] arm64/mpam: Fix L2 monitor issue under CDP mode
by Zeng Heng 07 Jul '25

07 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IC30P1 -------------------------------- The L2 monitor counters always reset to 0 under CDP working mode. This occurs because the L2 monitor employs cumulative statistics, and monitors a single partid within each statistical cycle. After completing the configuration for the new partid monitoring, the monitor instance starts a new monitoring cycle and resets the counter to zero. Since MPAM implements the CDP feature by allocating two partids, switching the monitor's target partid during a monitoring cycle falsely triggers a "new control group" assumption, leading to erroneous counter resets. To resolve this, use the real partid % num_mon to ensure distinct monitor instances track different partids under the CDP control group, preventing unintended resets. Fixes: 556688623b2b ("fs/resctrl: Create l2 cache monitors") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_resctrl.c | 42 ++++++++++------------------ 1 file changed, 14 insertions(+), 28 deletions(-) diff --git a/drivers/platform/mpam/mpam_resctrl.c b/drivers/platform/mpam/mpam_resctrl.c index 8de4aae95253..c3f9f0c2a94c 100644 --- a/drivers/platform/mpam/mpam_resctrl.c +++ b/drivers/platform/mpam/mpam_resctrl.c @@ -309,19 +309,8 @@ static void *resctrl_arch_mon_ctx_alloc_no_wait(struct rdt_resource *r, if (!ret) return ERR_PTR(-ENOMEM); - switch (evtid) { - case QOS_L3_OCCUP_EVENT_ID: - case QOS_L3_MBM_LOCAL_EVENT_ID: - case QOS_L3_MBM_TOTAL_EVENT_ID: - case QOS_L2_OCCUP_EVENT_ID: - case QOS_L2_MBM_CORE_EVENT_ID: - *ret = __mon_is_rmid_idx; - return ret; - - default: - kfree(ret); - return ERR_PTR(-EOPNOTSUPP); - } + *ret = __mon_is_rmid_idx; + return ret; } void *resctrl_arch_mon_ctx_alloc(struct rdt_resource *r, int evtid) @@ -371,7 +360,6 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, struct mon_cfg cfg; struct mpam_resctrl_dom *dom; struct mpam_resctrl_res *res; - u32 mon = *(u32 *)arch_mon_ctx; enum mpam_device_features type; resctrl_arch_rmid_read_context_check(); @@ -392,20 +380,15 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, return -EINVAL; } - cfg.mon = mon; - if (cfg.mon == USE_RMID_IDX) { - /* - * The number of mbwu monitors can't support free run mode, - * adapt the remainder of rmid to the num_mon as compromise. - */ - res = container_of(r, struct mpam_resctrl_res, resctrl_res); - if (type == mpam_feat_msmon_mbwu) - num_mon = res->class->props.num_mbwu_mon; - else - num_mon = res->class->props.num_csu_mon; - - cfg.mon = closid % num_mon; - } + /* + * The number of mbwu monitors can't support free run mode, + * adapt the remainder of rmid to the num_mon as compromise. + */ + res = container_of(r, struct mpam_resctrl_res, resctrl_res); + if (type == mpam_feat_msmon_mbwu) + num_mon = res->class->props.num_mbwu_mon; + else + num_mon = res->class->props.num_csu_mon; cfg.match_pmg = true; cfg.pmg = rmid; @@ -413,11 +396,13 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, if (cdp_enabled) { cfg.partid = resctrl_get_config_index(closid, CDP_DATA); + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, val); if (err) return err; cfg.partid = resctrl_get_config_index(closid, CDP_CODE); + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, &cdp_val); if (!err) { pr_debug("read monitor rmid %u %s:%u CODE/DATA: %lld/%lld\n", @@ -427,6 +412,7 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, } } else { cfg.partid = closid; + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, val); } -- 2.25.1

2 1

[PATCH OLK-6.6] arm64/mpam: Fix L2 monitor issue under CDP mode
by Zeng Heng 07 Jul '25

07 Jul '25

The L2 monitor counters always reset to 0 under CDP working mode. This occurs because the L2 monitor employs cumulative statistics, and monitors a single partid within each statistical cycle. After completing the configuration for the new partid monitoring, the monitor instance starts a new monitoring cycle and resets the counter to zero. Since MPAM implements the CDP feature by allocating two partids, switching the monitor's target partid during a monitoring cycle falsely triggers a "new control group" assumption, leading to erroneous counter resets. To resolve this, use the real partid % num_mon to ensure distinct monitor instances track different partids under the CDP control group, preventing unintended resets. Fixes: 585d757fc15c ("fs/resctrl: Create l2 cache monitors") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_resctrl.c | 42 ++++++++++------------------ 1 file changed, 14 insertions(+), 28 deletions(-) diff --git a/drivers/platform/mpam/mpam_resctrl.c b/drivers/platform/mpam/mpam_resctrl.c index 8de4aae95253..c3f9f0c2a94c 100644 --- a/drivers/platform/mpam/mpam_resctrl.c +++ b/drivers/platform/mpam/mpam_resctrl.c @@ -309,19 +309,8 @@ static void *resctrl_arch_mon_ctx_alloc_no_wait(struct rdt_resource *r, if (!ret) return ERR_PTR(-ENOMEM); - switch (evtid) { - case QOS_L3_OCCUP_EVENT_ID: - case QOS_L3_MBM_LOCAL_EVENT_ID: - case QOS_L3_MBM_TOTAL_EVENT_ID: - case QOS_L2_OCCUP_EVENT_ID: - case QOS_L2_MBM_CORE_EVENT_ID: - *ret = __mon_is_rmid_idx; - return ret; - - default: - kfree(ret); - return ERR_PTR(-EOPNOTSUPP); - } + *ret = __mon_is_rmid_idx; + return ret; } void *resctrl_arch_mon_ctx_alloc(struct rdt_resource *r, int evtid) @@ -371,7 +360,6 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, struct mon_cfg cfg; struct mpam_resctrl_dom *dom; struct mpam_resctrl_res *res; - u32 mon = *(u32 *)arch_mon_ctx; enum mpam_device_features type; resctrl_arch_rmid_read_context_check(); @@ -392,20 +380,15 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, return -EINVAL; } - cfg.mon = mon; - if (cfg.mon == USE_RMID_IDX) { - /* - * The number of mbwu monitors can't support free run mode, - * adapt the remainder of rmid to the num_mon as compromise. - */ - res = container_of(r, struct mpam_resctrl_res, resctrl_res); - if (type == mpam_feat_msmon_mbwu) - num_mon = res->class->props.num_mbwu_mon; - else - num_mon = res->class->props.num_csu_mon; - - cfg.mon = closid % num_mon; - } + /* + * The number of mbwu monitors can't support free run mode, + * adapt the remainder of rmid to the num_mon as compromise. + */ + res = container_of(r, struct mpam_resctrl_res, resctrl_res); + if (type == mpam_feat_msmon_mbwu) + num_mon = res->class->props.num_mbwu_mon; + else + num_mon = res->class->props.num_csu_mon; cfg.match_pmg = true; cfg.pmg = rmid; @@ -413,11 +396,13 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, if (cdp_enabled) { cfg.partid = resctrl_get_config_index(closid, CDP_DATA); + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, val); if (err) return err; cfg.partid = resctrl_get_config_index(closid, CDP_CODE); + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, &cdp_val); if (!err) { pr_debug("read monitor rmid %u %s:%u CODE/DATA: %lld/%lld\n", @@ -427,6 +412,7 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, } } else { cfg.partid = closid; + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, val); } -- 2.25.1

2 1

[PATCH OLK-6.6] wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds
by Tengda Wu 07 Jul '25

07 Jul '25

From: Alexey Kodanev <aleksei.kodanev(a)bell-sw.com> stable inclusion from stable-6.6.96 commit 74e18211c2c89ab66c9546baa7408288db61aa0d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICJTGV CVE: CVE-2025-38159 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4c2c372de2e108319236203cce6de44d70ae15cd ] Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], &para[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace. Fixes: 4136214f7c46 ("rtw88: add BT co-existence support") Signed-off-by: Alexey Kodanev <aleksei.kodanev(a)bell-sw.com> Signed-off-by: Ping-Ke Shih <pkshih(a)realtek.com> Link: https://patch.msgid.link/20250513121304.124141-1-aleksei.kodanev@bell-sw.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- drivers/net/wireless/realtek/rtw88/coex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtw88/coex.c b/drivers/net/wireless/realtek/rtw88/coex.c index d35f26919806..c45c7b596ffe 100644 --- a/drivers/net/wireless/realtek/rtw88/coex.c +++ b/drivers/net/wireless/realtek/rtw88/coex.c @@ -309,7 +309,7 @@ static void rtw_coex_tdma_timer_base(struct rtw_dev *rtwdev, u8 type) { struct rtw_coex *coex = &rtwdev->coex; struct rtw_coex_stat *coex_stat = &coex->stat; - u8 para[2] = {0}; + u8 para[6] = {}; u8 times; u16 tbtt_interval = coex_stat->wl_beacon_interval; -- 2.34.1

2 1

[PATCH OLK-6.6] f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()
by Cai Xinchen 07 Jul '25

07 Jul '25

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.6.88 commit 8b5e5aac44fee122947a269f9034c048e4c295de category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC5BHV CVE: CVE-2025-37739 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit e6494977bd4a83862118a05f57a8df40256951c0 ] syzbot reports an UBSAN issue as below: ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10 index 18446744073709550692 is out of range for type '__le32[5]' (aka 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 get_nid fs/f2fs/node.h:381 [inline] f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886 f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093 aio_write+0x56b/0x7c0 fs/aio.c:1633 io_submit_one+0x8a7/0x18a0 fs/aio.c:2052 __do_sys_io_submit fs/aio.c:2111 [inline] __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f238798cde9 index 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long) In f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to access .i_nid[-924], it means both offset[0] and level should zero. The possible case should be in f2fs_do_truncate_blocks(), we try to truncate inode size to zero, however, dn.ofs_in_node is zero and dn.node_page is not an inode page, so it fails to truncate inode page, and then pass zeroed free_from to f2fs_truncate_inode_blocks(), result in this issue. if (dn.ofs_in_node || IS_INODE(dn.node_page)) { f2fs_truncate_data_blocks_range(&dn, count); free_from += count; } I guess the reason why dn.node_page is not an inode page could be: there are multiple nat entries share the same node block address, once the node block address was reused, f2fs_get_node_page() may load a non-inode block. Let's add a sanity check for such condition to avoid out-of-bounds access issue. Reported-by: syzbot+6653f10281a1badc749e(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/66fdcdf3.050a0220.40bef.0025.GAE@google.com Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- fs/f2fs/node.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index dedba481b66d..d93282c1ed38 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -1134,7 +1134,14 @@ int f2fs_truncate_inode_blocks(struct inode *inode, pgoff_t from) trace_f2fs_truncate_inode_blocks_enter(inode, from); level = get_node_path(inode, from, offset, noffset); - if (level < 0) { + if (level <= 0) { + if (!level) { + level = -EFSCORRUPTED; + f2fs_err(sbi, "%s: inode ino=%lx has corrupted node block, from:%lu addrs:%u", + __func__, inode->i_ino, + from, ADDRS_PER_INODE(inode)); + set_sbi_flag(sbi, SBI_NEED_FSCK); + } trace_f2fs_truncate_inode_blocks_exit(inode, level); return level; } -- 2.34.1

2 1