- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10 V1] padata: use integer wrap around to prevent deadlock on seq_nr overflow
by Cheng Yu 25 Oct '24

25 Oct '24

From: VanGiang Nguyen <vangiang.nguyen(a)rohde-schwarz.com> stable inclusion from stable-v5.10.227 commit 46c4079460f4dcaf445860679558eedef4e1bc91 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYQSB CVE: CVE-2024-47739 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 9a22b2812393d93d84358a760c347c21939029a6 upstream. When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow. Fixes: bfde23ce200e ("padata: unbind parallel jobs from specific CPUs") Cc: <stable(a)vger.kernel.org> Co-developed-by: Christian Gafert <christian.gafert(a)rohde-schwarz.com> Signed-off-by: Christian Gafert <christian.gafert(a)rohde-schwarz.com> Co-developed-by: Max Ferger <max.ferger(a)rohde-schwarz.com> Signed-off-by: Max Ferger <max.ferger(a)rohde-schwarz.com> Signed-off-by: Van Giang Nguyen <vangiang.nguyen(a)rohde-schwarz.com> Acked-by: Daniel Jordan <daniel.m.jordan(a)oracle.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cheng Yu <serein.chengyu(a)huawei.com> --- kernel/padata.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/padata.c b/kernel/padata.c index 7b8d92f44b16..e24244c9c2cc 100644 --- a/kernel/padata.c +++ b/kernel/padata.c @@ -409,7 +409,8 @@ void padata_do_serial(struct padata_priv *padata) /* Sort in ascending order of sequence number. */ list_for_each_prev(pos, &reorder->list) { cur = list_entry(pos, struct padata_priv, list); - if (cur->seq_nr < padata->seq_nr) + /* Compare by difference to consider integer wrap around */ + if ((signed int)(cur->seq_nr - padata->seq_nr) < 0) break; } list_add(&padata->list, pos); -- 2.25.1

2 1

[openeuler:openEuler-1.0-LTS 15045/23857] drivers/clocksource/arm_arch_timer.c:554:44: error: 'hisi_161010101_read_cntvct_el0' undeclared
by kernel test robot 25 Oct '24

25 Oct '24

Hi Yang, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: fc5b1a61061cb6d640f3336024fb616182ef2614 commit: e63b4759933f6a5c5ce6cdc1d11c7bf2201d0612 [15045/23857] arm64: arch_timer: only do cntvct workaround on VDSO path on D05 config: arm64-randconfig-004-20241024 (https://download.01.org/0day-ci/archive/20241025/202410250213.xpJhjcfg-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241025/202410250213.xpJhjcfg-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410250213.xpJhjcfg-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/clocksource/arm_arch_timer.c: In function 'arch_timer_enable_workaround': >> drivers/clocksource/arm_arch_timer.c:554:44: error: 'hisi_161010101_read_cntvct_el0' undeclared (first use in this function) 554 | if (wa->read_cntvct_el0 == hisi_161010101_read_cntvct_el0) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/clocksource/arm_arch_timer.c:554:44: note: each undeclared identifier is reported only once for each function it appears in vim +/hisi_161010101_read_cntvct_el0 +554 drivers/clocksource/arm_arch_timer.c 527 528 static 529 void arch_timer_enable_workaround(const struct arch_timer_erratum_workaround *wa, 530 bool local) 531 { 532 int i; 533 534 if (local) { 535 __this_cpu_write(timer_unstable_counter_workaround, wa); 536 } else { 537 for_each_possible_cpu(i) 538 per_cpu(timer_unstable_counter_workaround, i) = wa; 539 } 540 541 /* 542 * Use the locked version, as we're called from the CPU 543 * hotplug framework. Otherwise, we end-up in deadlock-land. 544 */ 545 static_branch_enable_cpuslocked(&arch_timer_read_ool_enabled); 546 547 /* 548 * Don't use the vdso fastpath if errata require using the 549 * out-of-line counter accessor. We may change our mind pretty 550 * late in the game (with a per-CPU erratum, for example), so 551 * change both the default value and the vdso itself. 552 */ 553 if (wa->read_cntvct_el0) { > 554 if (wa->read_cntvct_el0 == hisi_161010101_read_cntvct_el0) { 555 clocksource_counter.archdata.vdso_direct = true; 556 vdso_default = true; 557 vdso_fix = true; 558 } else { 559 clocksource_counter.archdata.vdso_direct = false; 560 vdso_default = false; 561 } 562 } 563 } 564 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS 5421/23857] arch/arm64/kernel/smp.c:1217:14: error: 'pmu_nmi_enable' undeclared; did you mean 'perf_pmu_enable'?
by kernel test robot 25 Oct '24

25 Oct '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: fc5b1a61061cb6d640f3336024fb616182ef2614 commit: 71e217e85c3dff8a9151707ed3afc7b4b054a2d4 [5421/23857] selinux: use kernel linux/socket.h for genheaders and mdp config: arm64-randconfig-004-20241024 (https://download.01.org/0day-ci/archive/20241025/202410250017.rJYuRb99-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241025/202410250017.rJYuRb99-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410250017.rJYuRb99-lkp@intel.com/ All errors (new ones prefixed by >>): arch/arm64/kernel/smp.c:840:6: warning: no previous prototype for 'arch_irq_work_raise' [-Wmissing-prototypes] 840 | void arch_irq_work_raise(void) | ^~~~~~~~~~~~~~~~~~~ arch/arm64/kernel/smp.c: In function 'hw_nmi_get_sample_period': >> arch/arm64/kernel/smp.c:1217:14: error: 'pmu_nmi_enable' undeclared (first use in this function); did you mean 'perf_pmu_enable'? 1217 | if (!pmu_nmi_enable) | ^~~~~~~~~~~~~~ | perf_pmu_enable arch/arm64/kernel/smp.c:1217:14: note: each undeclared identifier is reported only once for each function it appears in In file included from include/linux/kernel.h:14, from include/linux/list.h:9, from include/linux/resource_ext.h:17, from include/linux/acpi.h:26, from arch/arm64/kernel/smp.c:20: arch/arm64/kernel/smp.c: In function '__cpu_up': include/linux/printk.h:346:9: warning: this statement may fall through [-Wimplicit-fallthrough=] 346 | printk(KERN_CRIT pr_fmt(fmt), ##__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm64/kernel/smp.c:169:25: note: in expansion of macro 'pr_crit' 169 | pr_crit("CPU%u: may not have shut down cleanly\n", cpu); | ^~~~~~~ arch/arm64/kernel/smp.c:170:17: note: here 170 | case CPU_STUCK_IN_KERNEL: | ^~~~ vim +1217 arch/arm64/kernel/smp.c c17272c92d2ee1 Wei Li 2019-03-28 1212 5bffbe2174676c Wei Li 2019-03-20 1213 u64 hw_nmi_get_sample_period(int watchdog_thresh) 5bffbe2174676c Wei Li 2019-03-20 1214 { c17272c92d2ee1 Wei Li 2019-03-28 1215 u64 cpu_freq; c17272c92d2ee1 Wei Li 2019-03-28 1216 9f05210dfee3a2 Yang Yingliang 2019-03-23 @1217 if (!pmu_nmi_enable) :::::: The code at line 1217 was first introduced by commit :::::: 9f05210dfee3a2319a61302f9bfd7317b522fa96 arm64: perf: add pmu_nmi_enable to control pmu nmi support :::::: TO: Yang Yingliang <yangyingliang(a)huawei.com> :::::: CC: Xie XiuQi <xiexiuqi(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6 7453/15273] mm/kasan/shadow.c:90:undefined reference to `__memcpy_mc'
by kernel test robot 24 Oct '24

24 Oct '24

Hi Tong, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: ed7fbeaf3f3511bb3db6134d07f614d513c4273f commit: b991780c836ceb9a479c6c6e385e914b487e353a [7453/15273] arm64: introduce copy_mc_to_kernel() implementation config: arm64-randconfig-003-20241024 (https://download.01.org/0day-ci/archive/20241024/202410242202.olRfrxYG-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410242202.olRfrxYG-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410242202.olRfrxYG-lkp@intel.com/ All errors (new ones prefixed by >>): aarch64-linux-ld: Unexpected GOT/PLT entries detected! aarch64-linux-ld: Unexpected run-time procedure linkages detected! aarch64-linux-ld: mm/kasan/shadow.o: in function `memcpy_mc': >> mm/kasan/shadow.c:90:(.text+0x6bc): undefined reference to `__memcpy_mc' vim +90 mm/kasan/shadow.c 81 82 #ifdef __HAVE_ARCH_MEMCPY_MC 83 #undef memcpy_mc 84 int memcpy_mc(void *dest, const void *src, size_t len) 85 { 86 if (!kasan_check_range(src, len, false, _RET_IP_) || 87 !kasan_check_range(dest, len, true, _RET_IP_)) 88 return (int)len; 89 > 90 return __memcpy_mc(dest, src, len); 91 } 92 #endif 93 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-5.10 0/2] fix CVE-2024-43841
by dinglongwei 24 Oct '24

24 Oct '24

fix CVE-2024-43841 En-Wei Wu (1): wifi: virt_wifi: avoid reporting connection success with wrong SSID Johannes Berg (1): wifi: virt_wifi: don't use strlen() in const context drivers/net/wireless/virt_wifi.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) -- 2.17.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-43841
by dinglongwei 24 Oct '24

24 Oct '24

fix CVE-2024-43841 En-Wei Wu (1): wifi: virt_wifi: avoid reporting connection success with wrong SSID Johannes Berg (1): wifi: virt_wifi: don't use strlen() in const context drivers/net/wireless/virt_wifi.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) -- 2.17.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/1] fix CVE-2024-49954
by Liao Chen 24 Oct '24

24 Oct '24

fix CVE-2024-49954 Thomas Gleixner (1): static_call: Replace pointless WARN_ON() in static_call_module_notify() kernel/static_call.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/1] fix CVE-2024-49954
by Liao Chen 24 Oct '24

24 Oct '24

fix CVE-2024-49954 Thomas Gleixner (1): [Backport] static_call: Replace pointless WARN_ON() in static_call_module_notify() kernel/static_call_inline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
by Yi Yang 24 Oct '24

24 Oct '24

From: Junlin Li <make24(a)iscas.ac.cn> mainline inclusion from mainline-v6.12-rc1 commit 8ae06f360cfaca2b88b98ca89144548b3186aab1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYPJY CVE: CVE-2024-47698 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. Signed-off-by: Junlin Li <make24(a)iscas.ac.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Fixes: 4b01e01a81b6 ("[media] rtl2832: implement PID filter") [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg] Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/media/dvb-frontends/rtl2832.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c index 2f1f5cbaf03c..a7a6c4e5d1cc 100644 --- a/drivers/media/dvb-frontends/rtl2832.c +++ b/drivers/media/dvb-frontends/rtl2832.c @@ -995,7 +995,7 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8 index, u16 pid, index, pid, onoff, dev->slave_ts); /* skip invalid PIDs (0x2000) */ - if (pid > 0x1fff || index > 32) + if (pid > 0x1fff || index >= 32) return 0; if (onoff) -- 2.25.1

2 2

[PATCH OLK-5.10] drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
by Yi Yang 24 Oct '24

24 Oct '24

From: Junlin Li <make24(a)iscas.ac.cn> stable inclusion from stable-v5.10.227 commit 6ae3b9aee42616ee93c4585174f40c767828006d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYPJY CVE: CVE-2024-47698 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8ae06f360cfaca2b88b98ca89144548b3186aab1 ] Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. Signed-off-by: Junlin Li <make24(a)iscas.ac.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Fixes: 4b01e01a81b6 ("[media] rtl2832: implement PID filter") [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/media/dvb-frontends/rtl2832.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c index e5bffaaeed38..1c3e572cad3f 100644 --- a/drivers/media/dvb-frontends/rtl2832.c +++ b/drivers/media/dvb-frontends/rtl2832.c @@ -982,7 +982,7 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8 index, u16 pid, index, pid, onoff, dev->slave_ts); /* skip invalid PIDs (0x2000) */ - if (pid > 0x1fff || index > 32) + if (pid > 0x1fff || index >= 32) return 0; if (onoff) -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
by Yi Yang 24 Oct '24

24 Oct '24

From: Junlin Li <make24(a)iscas.ac.cn> stable inclusion from stable-v5.10.227 commit 6ae3b9aee42616ee93c4585174f40c767828006d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYPJY CVE: CVE-2024-47698 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8ae06f360cfaca2b88b98ca89144548b3186aab1 ] Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. Signed-off-by: Junlin Li <make24(a)iscas.ac.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Fixes: 4b01e01a81b6 ("[media] rtl2832: implement PID filter") [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/media/dvb-frontends/rtl2832.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c index e5bffaaeed38..1c3e572cad3f 100644 --- a/drivers/media/dvb-frontends/rtl2832.c +++ b/drivers/media/dvb-frontends/rtl2832.c @@ -982,7 +982,7 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8 index, u16 pid, index, pid, onoff, dev->slave_ts); /* skip invalid PIDs (0x2000) */ - if (pid > 0x1fff || index > 32) + if (pid > 0x1fff || index >= 32) return 0; if (onoff) -- 2.25.1

2 1

[PATCH OLK-6.6] drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
by Yi Yang 24 Oct '24

24 Oct '24

From: Junlin Li <make24(a)iscas.ac.cn> stable inclusion from stable-v6.6.54 commit 527ab3eb3b0b4a6ee00e183c1de6a730239e2835 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYPJY CVE: CVE-2024-47698 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8ae06f360cfaca2b88b98ca89144548b3186aab1 ] Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. Signed-off-by: Junlin Li <make24(a)iscas.ac.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Fixes: 4b01e01a81b6 ("[media] rtl2832: implement PID filter") [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg] Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/media/dvb-frontends/rtl2832.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c index 601cf45c3935..e6a7877a9854 100644 --- a/drivers/media/dvb-frontends/rtl2832.c +++ b/drivers/media/dvb-frontends/rtl2832.c @@ -983,7 +983,7 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, u8 index, u16 pid, index, pid, onoff, dev->slave_ts); /* skip invalid PIDs (0x2000) */ - if (pid > 0x1fff || index > 32) + if (pid > 0x1fff || index >= 32) return 0; if (onoff) -- 2.25.1

2 1

[PATCH OLK-6.6] wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he
by Zheng Yejian 24 Oct '24

24 Oct '24

From: Ma Ke <make24(a)iscas.ac.cn> stable inclusion from stable-v6.6.54 commit 8e4b60ae8a047ad2fb175fcfdd54feee80983a45 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYPJK CVE: CVE-2024-47681 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f503ae90c7355e8506e68498fe84c1357894cd5b upstream. Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> Link: https://patch.msgid.link/20240813081242.3991814-1-make24@iscas.ac.cn Signed-off-by: Felix Fietkau <nbd(a)nbd.name> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c index b66f712e1b17..531e948b0e3f 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c @@ -1303,6 +1303,9 @@ mt7996_mcu_sta_bfer_he(struct ieee80211_sta *sta, struct ieee80211_vif *vif, u8 nss_mcs = mt7996_mcu_get_sta_nss(mcs_map); u8 snd_dim, sts; + if (!vc) + return; + bf->tx_mode = MT_PHY_TYPE_HE_SU; mt7996_mcu_sta_sounding_rate(bf); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/2] Fix CVE-2022-49006
by Zheng Yejian 24 Oct '24

24 Oct '24

Steven Rostedt (Google) (2): tracing: Free buffers when a used dynamic event is removed tracing: Add tracing_reset_all_online_cpus_unlocked() function kernel/trace/trace.c | 11 ++++++++++- kernel/trace/trace.h | 1 + kernel/trace/trace_dynevent.c | 2 ++ kernel/trace/trace_events.c | 13 +++++++++++-- kernel/trace/trace_events_synth.c | 2 -- 5 files changed, 24 insertions(+), 5 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6] tracing/timerlat: Drop interface_lock in stop_kthread()
by Zheng Yejian 24 Oct '24

24 Oct '24

From: Wei Li <liwei391(a)huawei.com> stable inclusion from stable-v6.6.55 commit a4a05ceffe8fad68b45de38fe2311bda619e76e2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRD5 CVE: CVE-2024-49976 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit b484a02c9cedf8703eff8f0756f94618004bd165 upstream. stop_kthread() is the offline callback for "trace/osnoise:online", since commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the "kthread" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again. Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Link: https://lore.kernel.org/20240924094515.3561410-3-liwei391@huawei.com Fixes: 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()") Signed-off-by: Wei Li <liwei391(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/trace_osnoise.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index 461b4ab60b50..9d93e2232ad8 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -1953,12 +1953,8 @@ static void stop_kthread(unsigned int cpu) { struct task_struct *kthread; - mutex_lock(&interface_lock); - kthread = per_cpu(per_cpu_osnoise_var, cpu).kthread; + kthread = xchg_relaxed(&(per_cpu(per_cpu_osnoise_var, cpu).kthread), NULL); if (kthread) { - per_cpu(per_cpu_osnoise_var, cpu).kthread = NULL; - mutex_unlock(&interface_lock); - if (cpumask_test_and_clear_cpu(cpu, &kthread_cpumask) && !WARN_ON(!test_bit(OSN_WORKLOAD, &osnoise_options))) { kthread_stop(kthread); @@ -1972,7 +1968,6 @@ static void stop_kthread(unsigned int cpu) put_task_struct(kthread); } } else { - mutex_unlock(&interface_lock); /* if no workload, just return */ if (!test_bit(OSN_WORKLOAD, &osnoise_options)) { /* @@ -1994,8 +1989,12 @@ static void stop_per_cpu_kthreads(void) { int cpu; - for_each_possible_cpu(cpu) + cpus_read_lock(); + + for_each_online_cpu(cpu) stop_kthread(cpu); + + cpus_read_unlock(); } /* -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] tracing/timerlat: Fix a race during cpuhp processing
by Zheng Yejian 24 Oct '24

24 Oct '24

From: Wei Li <liwei391(a)huawei.com> stable inclusion from stable-v6.6.55 commit a6e9849063a6c8f4cb2f652a437e44e3ed24356c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRAT CVE: CVE-2024-49866 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 829e0c9f0855f26b3ae830d17b24aec103f7e915 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Link: https://lore.kernel.org/20240924094515.3561410-4-liwei391@huawei.com Fixes: c8895e271f79 ("trace/osnoise: Support hotplug operations") Conflicts: kernel/trace/trace_osnoise.c [Resolve conflicts due to the refactor commit 99c37d1a63ea ("tracing: Replace deprecated CPU-hotplug functions." not merged] Signed-off-by: Wei Li <liwei391(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/trace_osnoise.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index d23304b7f12c..fd09e68b7740 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -1741,6 +1741,8 @@ static void osnoise_hotplug_workfn(struct work_struct *dummy) mutex_lock(&interface_lock); get_online_cpus(); + if (!cpu_online(cpu)) + goto out_unlock; if (!cpumask_test_cpu(cpu, &osnoise_cpumask)) goto out_unlock; -- 2.25.1

2 1

[PATCH OLK-5.10] tracing/timerlat: Fix a race during cpuhp processing
by Zheng Yejian 24 Oct '24

24 Oct '24

From: Wei Li <liwei391(a)huawei.com> stable inclusion from stable-v6.6.55 commit a6e9849063a6c8f4cb2f652a437e44e3ed24356c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRAT CVE: CVE-2024-49866 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 829e0c9f0855f26b3ae830d17b24aec103f7e915 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Link: https://lore.kernel.org/20240924094515.3561410-4-liwei391@huawei.com Fixes: c8895e271f79 ("trace/osnoise: Support hotplug operations") Conflicts: kernel/trace/trace_osnoise.c [Resolve conflicts due to the refactor commit 99c37d1a63ea ("tracing: Replace deprecated CPU-hotplug functions." not merged] Signed-off-by: Wei Li <liwei391(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/trace_osnoise.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index d23304b7f12c..fd09e68b7740 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -1741,6 +1741,8 @@ static void osnoise_hotplug_workfn(struct work_struct *dummy) mutex_lock(&interface_lock); get_online_cpus(); + if (!cpu_online(cpu)) + goto out_unlock; if (!cpumask_test_cpu(cpu, &osnoise_cpumask)) goto out_unlock; -- 2.25.1

2 1

[PATCH OLK-6.6] tracing/timerlat: Fix a race during cpuhp processing
by Zheng Yejian 24 Oct '24

24 Oct '24

From: Wei Li <liwei391(a)huawei.com> stable inclusion from stable-v6.6.55 commit a6e9849063a6c8f4cb2f652a437e44e3ed24356c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRAT CVE: CVE-2024-49866 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 829e0c9f0855f26b3ae830d17b24aec103f7e915 upstream. There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Link: https://lore.kernel.org/20240924094515.3561410-4-liwei391@huawei.com Fixes: c8895e271f79 ("trace/osnoise: Support hotplug operations") Signed-off-by: Wei Li <liwei391(a)huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- kernel/trace/trace_osnoise.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c index 9d93e2232ad8..26bb7fa51416 100644 --- a/kernel/trace/trace_osnoise.c +++ b/kernel/trace/trace_osnoise.c @@ -2094,6 +2094,8 @@ static void osnoise_hotplug_workfn(struct work_struct *dummy) mutex_lock(&interface_lock); cpus_read_lock(); + if (!cpu_online(cpu)) + goto out_unlock; if (!cpumask_test_cpu(cpu, &osnoise_cpumask)) goto out_unlock; -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] mm/swapfile: skip HugeTLB pages for unuse_vma
by Liu Shixin 24 Oct '24

24 Oct '24

mainline inclusion from mainline-v6.12-rc4 commit 4d939780b70592e0f4bc6c397e52e518f8fb7916 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAXWWM CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. Link: https://lkml.kernel.org/r/20241015014521.570237-1-liushixin2@huawei.com Fixes: 0fe6e20b9c4c ("hugetlb, rmap: add reverse mapping for hugepage") Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Acked-by: Muchun Song <muchun.song(a)linux.dev> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/swapfile.c [ Context conflict. ] Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/swapfile.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index 1d98be001d3d8..b505a827e5897 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -2047,7 +2047,8 @@ static int unuse_mm(struct mm_struct *mm, lock_page(page); } for (vma = mm->mmap; vma; vma = vma->vm_next) { - if (vma->anon_vma && (ret = unuse_vma(vma, entry, page))) + if (vma->anon_vma && !is_vm_hugetlb_page(vma) + && (ret = unuse_vma(vma, entry, page))) break; cond_resched(); } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] mm/swapfile: skip HugeTLB pages for unuse_vma
by Liu Shixin 24 Oct '24

24 Oct '24

stable inclusion from stable-v5.10.228 commit 417d5838ca73c6331ae2fe692fab6c25c00d9a0b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAXWWM Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 7528c4fb1237512ee18049f852f014eba80bbe8d upstream. I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. Link: https://lkml.kernel.org/r/20241015014521.570237-1-liushixin2@huawei.com Fixes: 0fe6e20b9c4c ("hugetlb, rmap: add reverse mapping for hugepage") Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Acked-by: Muchun Song <muchun.song(a)linux.dev> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/swapfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index e46a2ca1c679a..edcf6335aba4d 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -2144,7 +2144,7 @@ static int unuse_mm(struct mm_struct *mm, unsigned int type, mmap_read_lock(mm); for (vma = mm->mmap; vma; vma = vma->vm_next) { - if (vma->anon_vma) { + if (vma->anon_vma && !is_vm_hugetlb_page(vma)) { ret = unuse_vma(vma, type, frontswap, fs_pages_to_unuse); if (ret) -- 2.34.1

2 1

[PATCH OLK-5.10] mm/swapfile: skip HugeTLB pages for unuse_vma
by Liu Shixin 24 Oct '24

24 Oct '24

stable inclusion from stable-v5.10.228 commit 417d5838ca73c6331ae2fe692fab6c25c00d9a0b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAXWWM Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 7528c4fb1237512ee18049f852f014eba80bbe8d upstream. I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. Link: https://lkml.kernel.org/r/20241015014521.570237-1-liushixin2@huawei.com Fixes: 0fe6e20b9c4c ("hugetlb, rmap: add reverse mapping for hugepage") Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Acked-by: Muchun Song <muchun.song(a)linux.dev> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/swapfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index 2f8a099f014b1..07f50d5f5bb77 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -2238,7 +2238,7 @@ static int unuse_mm(struct mm_struct *mm, unsigned int type, mmap_read_lock(mm); for (vma = mm->mmap; vma; vma = vma->vm_next) { - if (vma->anon_vma) { + if (vma->anon_vma && !is_vm_hugetlb_page(vma)) { ret = unuse_vma(vma, type, frontswap, fs_pages_to_unuse); if (ret) -- 2.34.1

2 1

[PATCH OLK-6.6] RDMA/hns: Fix missing spin_lock_init() for qp flush lock
by Chengchang Tang 24 Oct '24

24 Oct '24

From: wenglianfa <wenglianfa(a)huawei.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAZKOG ---------------------------------------------------------------------- Fix missing spin_lock_init() for qp flush lock. Fixes: 9130e79bca7e ("RDMA/hns: Fix flush cqe error when racing with destroy qp") Signed-off-by: wenglianfa <wenglianfa(a)huawei.com> Signed-off-by: Xinghai Cen <cenxinghai(a)h-partners.com> --- drivers/infiniband/hw/hns/hns_roce_qp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/infiniband/hw/hns/hns_roce_qp.c b/drivers/infiniband/hw/hns/hns_roce_qp.c index a62b1b96655a..34f18a07b85e 100644 --- a/drivers/infiniband/hw/hns/hns_roce_qp.c +++ b/drivers/infiniband/hw/hns/hns_roce_qp.c @@ -1241,6 +1241,7 @@ static int hns_roce_create_qp_common(struct hns_roce_dev *hr_dev, mutex_init(&hr_qp->mutex); spin_lock_init(&hr_qp->sq.lock); spin_lock_init(&hr_qp->rq.lock); + spin_lock_init(&hr_qp->flush_lock); hr_qp->state = IB_QPS_RESET; hr_qp->flush_flag = 0; -- 2.33.0

2 1

[PATCH OLK-6.6] mm/swapfile: skip HugeTLB pages for unuse_vma
by Liu Shixin 24 Oct '24

24 Oct '24

stable inclusion from stable-v6.6.58 commit bed2b9037806c62166a0ef9a559a1e7e3e1275b8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAXWWM Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 7528c4fb1237512ee18049f852f014eba80bbe8d upstream. I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. Link: https://lkml.kernel.org/r/20241015014521.570237-1-liushixin2@huawei.com Fixes: 0fe6e20b9c4c ("hugetlb, rmap: add reverse mapping for hugepage") Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> Acked-by: Muchun Song <muchun.song(a)linux.dev> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/swapfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index cfb768d3ed730..7f39bebaee348 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -2190,7 +2190,7 @@ static int unuse_mm(struct mm_struct *mm, unsigned int type) mmap_read_lock(mm); for_each_vma(vmi, vma) { - if (vma->anon_vma) { + if (vma->anon_vma && !is_vm_hugetlb_page(vma)) { ret = unuse_vma(vma, type); if (ret) break; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] spi: nxp-fspi: fix the KASAN report out-of-bounds bug
by Lin Ruifeng 24 Oct '24

24 Oct '24

From: Han Xu <han.xu(a)nxp.com> stable inclusion from stable-v6.6.52 commit af9ca9ca3e44f48b2a191e100d452fbf850c3d87 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAU9NZ CVE: CVE-2024-46853 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 2a8787c1cdc7be24fdd8953ecd1a8743a1006235 upstream. Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO. To reproduce the issue, write 3 bytes data to NOR chip. dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ================================================================== [ 37.254394] Disabling lock debugging due to kernel taint 0+1 records in 0+1 records out 3 bytes copied, 0.335911 s, 0.0 kB/s Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller") Cc: stable(a)kernel.org Signed-off-by: Han Xu <han.xu(a)nxp.com> Link: https://patch.msgid.link/20240911211146.3337068-1-han.xu@nxp.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/spi/spi-nxp-fspi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c index bcc0b5a3a459..c8f2b4f86414 100644 --- a/drivers/spi/spi-nxp-fspi.c +++ b/drivers/spi/spi-nxp-fspi.c @@ -731,14 +731,15 @@ static void nxp_fspi_fill_txfifo(struct nxp_fspi *f, if (i < op->data.nbytes) { u32 data = 0; int j; + int remaining = op->data.nbytes - i; /* Wait for TXFIFO empty */ ret = fspi_readl_poll_tout(f, f->iobase + FSPI_INTR, FSPI_INTR_IPTXWE, 0, POLL_TOUT, true); WARN_ON(ret); - for (j = 0; j < ALIGN(op->data.nbytes - i, 4); j += 4) { - memcpy(&data, buf + i + j, 4); + for (j = 0; j < ALIGN(remaining, 4); j += 4) { + memcpy(&data, buf + i + j, min_t(int, 4, remaining - j)); fspi_writel(f, data, base + FSPI_TFDR + j); } fspi_writel(f, FSPI_INTR_IPTXWE, base + FSPI_INTR); -- 2.17.1

2 1

[PATCH OLK-5.10] spi: nxp-fspi: fix the KASAN report out-of-bounds bug
by Lin Ruifeng 24 Oct '24

24 Oct '24

From: Han Xu <han.xu(a)nxp.com> stable inclusion from stable-v6.6.52 commit af9ca9ca3e44f48b2a191e100d452fbf850c3d87 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAU9NZ CVE: CVE-2024-46853 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 2a8787c1cdc7be24fdd8953ecd1a8743a1006235 upstream. Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO. To reproduce the issue, write 3 bytes data to NOR chip. dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ================================================================== [ 37.254394] Disabling lock debugging due to kernel taint 0+1 records in 0+1 records out 3 bytes copied, 0.335911 s, 0.0 kB/s Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller") Cc: stable(a)kernel.org Signed-off-by: Han Xu <han.xu(a)nxp.com> Link: https://patch.msgid.link/20240911211146.3337068-1-han.xu@nxp.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/spi/spi-nxp-fspi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c index f40b93960b89..d5c62c6e03d3 100644 --- a/drivers/spi/spi-nxp-fspi.c +++ b/drivers/spi/spi-nxp-fspi.c @@ -731,14 +731,15 @@ static void nxp_fspi_fill_txfifo(struct nxp_fspi *f, if (i < op->data.nbytes) { u32 data = 0; int j; + int remaining = op->data.nbytes - i; /* Wait for TXFIFO empty */ ret = fspi_readl_poll_tout(f, f->iobase + FSPI_INTR, FSPI_INTR_IPTXWE, 0, POLL_TOUT, true); WARN_ON(ret); - for (j = 0; j < ALIGN(op->data.nbytes - i, 4); j += 4) { - memcpy(&data, buf + i + j, 4); + for (j = 0; j < ALIGN(remaining, 4); j += 4) { + memcpy(&data, buf + i + j, min_t(int, 4, remaining - j)); fspi_writel(f, data, base + FSPI_TFDR + j); } fspi_writel(f, FSPI_INTR_IPTXWE, base + FSPI_INTR); -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
by Lin Ruifeng 24 Oct '24

24 Oct '24

From: Ma Jun <Jun.Ma2(a)amd.com> stable inclusion from stable-v5.10.226 commit 725b728cc0c8c5fafdfb51cb0937870d33a40fa4 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IARV1E CVE: CVE-2024-46724 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d768394fa99467bcf2703bde74ddc96eeb0b71fa ] Check the fb_channel_number range to avoid the array out-of-bounds read error Signed-off-by: Ma Jun <Jun.Ma2(a)amd.com> Reviewed-by: Tim Huang <Tim.Huang(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c index d6aca1c08068..9587e8672a01 100644 --- a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c +++ b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c @@ -70,6 +70,8 @@ static u32 df_v1_7_get_hbm_channel_number(struct amdgpu_device *adev) int fb_channel_number; fb_channel_number = adev->df.funcs->get_fb_channel_number(adev); + if (fb_channel_number >= ARRAY_SIZE(df_v1_7_channel_number)) + fb_channel_number = 0; return df_v1_7_channel_number[fb_channel_number]; } -- 2.17.1

2 1

[PATCH OLK-5.10] drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
by Lin Ruifeng 24 Oct '24

24 Oct '24

From: Ma Jun <Jun.Ma2(a)amd.com> stable inclusion from stable-v5.10.226 commit 725b728cc0c8c5fafdfb51cb0937870d33a40fa4 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IARV1E CVE: CVE-2024-46724 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d768394fa99467bcf2703bde74ddc96eeb0b71fa ] Check the fb_channel_number range to avoid the array out-of-bounds read error Signed-off-by: Ma Jun <Jun.Ma2(a)amd.com> Reviewed-by: Tim Huang <Tim.Huang(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c index d6aca1c08068..9587e8672a01 100644 --- a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c +++ b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c @@ -70,6 +70,8 @@ static u32 df_v1_7_get_hbm_channel_number(struct amdgpu_device *adev) int fb_channel_number; fb_channel_number = adev->df.funcs->get_fb_channel_number(adev); + if (fb_channel_number >= ARRAY_SIZE(df_v1_7_channel_number)) + fb_channel_number = 0; return df_v1_7_channel_number[fb_channel_number]; } -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number
by Lin Ruifeng 24 Oct '24

24 Oct '24

From: Ma Jun <Jun.Ma2(a)amd.com> stable inclusion from stable-v5.10.226 commit 725b728cc0c8c5fafdfb51cb0937870d33a40fa4 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IARV1E CVE: CVE-2024-46724 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d768394fa99467bcf2703bde74ddc96eeb0b71fa ] Check the fb_channel_number range to avoid the array out-of-bounds read error Signed-off-by: Ma Jun <Jun.Ma2(a)amd.com> Reviewed-by: Tim Huang <Tim.Huang(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/gpu/drm/amd/amdgpu/df_v1_7.c [Context conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c index 9935371db7ce..7aecb52365e9 100644 --- a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c +++ b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c @@ -63,6 +63,8 @@ static u32 df_v1_7_get_hbm_channel_number(struct amdgpu_device *adev) int fb_channel_number; fb_channel_number = adev->df_funcs->get_fb_channel_number(adev); + if (fb_channel_number >= ARRAY_SIZE(df_v1_7_channel_number)) + fb_channel_number = 0; return df_v1_7_channel_number[fb_channel_number]; } -- 2.17.1

2 1

[PATCH openEuler-1.0-LTS] x86/ioapic: Handle allocation failures gracefully
by Jinjie Ruan 24 Oct '24

24 Oct '24

From: Thomas Gleixner <tglx(a)linutronix.de> stable inclusion from stable-v5.15.168 commit e479cb835feeb2abff97f25766e23b96a6eabe28 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCY CVE: CVE-2024-49927 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f ] Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully. Reported-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Breno Leitao <leitao(a)debian.org> Tested-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Link: https://lore.kernel.org/all/ZqfJmUF8sXIyuSHN@gmail.com Link: https://lore.kernel.org/all/20240802155440.275200843@linutronix.de Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/x86/kernel/apic/io_apic.c [adjust context conflicts] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/x86/kernel/apic/io_apic.c | 46 ++++++++++++++++------------------ 1 file changed, 22 insertions(+), 24 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index a63366344fcf..00a9f9aede42 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -371,27 +371,26 @@ static void ioapic_mask_entry(int apic, int pin) * shared ISA-space IRQs, so we have to support them. We are super * fast in the common case, and fast for shared ISA-space IRQs. */ -static int __add_pin_to_irq_node(struct mp_chip_data *data, - int node, int apic, int pin) +static bool add_pin_to_irq_node(struct mp_chip_data *data, int node, int apic, int pin) { struct irq_pin_list *entry; - /* don't allow duplicates */ - for_each_irq_pin(entry, data->irq_2_pin) + /* Don't allow duplicates */ + for_each_irq_pin(entry, data->irq_2_pin) { if (entry->apic == apic && entry->pin == pin) - return 0; + return true; + } entry = kzalloc_node(sizeof(struct irq_pin_list), GFP_ATOMIC, node); if (!entry) { - pr_err("can not alloc irq_pin_list (%d,%d,%d)\n", - node, apic, pin); - return -ENOMEM; + pr_err("Cannot allocate irq_pin_list (%d,%d,%d)\n", node, apic, pin); + return false; } + entry->apic = apic; entry->pin = pin; list_add_tail(&entry->list, &data->irq_2_pin); - - return 0; + return true; } static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin) @@ -406,13 +405,6 @@ static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin) } } -static void add_pin_to_irq_node(struct mp_chip_data *data, - int node, int apic, int pin) -{ - if (__add_pin_to_irq_node(data, node, apic, pin)) - panic("IO-APIC: failed to add irq-pin. Can not proceed\n"); -} - /* * Reroute an IRQ to a different pin. */ @@ -1012,8 +1004,7 @@ static int alloc_isa_irq_from_domain(struct irq_domain *domain, if (irq_data && irq_data->parent_data) { if (!mp_check_pin_attr(irq, info)) return -EBUSY; - if (__add_pin_to_irq_node(irq_data->chip_data, node, ioapic, - info->ioapic_pin)) + if (!add_pin_to_irq_node(irq_data->chip_data, node, ioapic, info->ioapic_pin)) return -ENOMEM; } else { info->flags |= X86_IRQ_ALLOC_LEGACY; @@ -2993,10 +2984,8 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, info->ioapic_entry = &data->entry; ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, info); - if (ret < 0) { - kfree(data); - return ret; - } + if (ret < 0) + goto free_data; INIT_LIST_HEAD(&data->irq_2_pin); irq_data->hwirq = info->ioapic_pin; @@ -3006,7 +2995,10 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, mp_irqdomain_get_attr(mp_pin_to_gsi(ioapic, pin), data, info); cfg = irqd_cfg(irq_data); - add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin); + if (!add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin)) { + ret = -ENOMEM; + goto free_irqs; + } local_irq_save(flags); if (info->ioapic_entry) @@ -3022,6 +3014,12 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, virq, data->trigger, data->polarity, cfg->dest_apicid); return 0; + +free_irqs: + irq_domain_free_irqs_parent(domain, virq, nr_irqs); +free_data: + kfree(data); + return ret; } void mp_irqdomain_free(struct irq_domain *domain, unsigned int virq, -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] fix CVE-2024-46675
by Lin Ruifeng 24 Oct '24

24 Oct '24

fix CVE-2024-46675 Krishna Kurapati (1): usb: dwc3: core: Skip setting event buffers for host only controllers Selvarasu Ganesan (1): usb: dwc3: core: Prevent USB core invalid event buffer address access drivers/usb/dwc3/core.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) -- 2.17.1

2 3

[openeuler:OLK-5.10 24524/30000] drivers/crypto/montage/tsse/tsse_dev.h:85:6: warning: variable 'cpu' set but not used
by kernel test robot 24 Oct '24

24 Oct '24

tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 52e62ae625fcfe934330b24239cf61af5b5ce33f commit: d55c499d1e3a11eef5557afc31af5ef6baa44b8e [24524/30000] add support for Mont-TSSE Driver config: x86_64-randconfig-r064-20241024 (https://download.01.org/0day-ci/archive/20241024/202410241950.tFucKzUb-lkp@…) compiler: clang version 19.1.2 (https://github.com/llvm/llvm-project 7ba7d8e2f7b6445b60679da826210cdde29eaf8b) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410241950.tFucKzUb-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410241950.tFucKzUb-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from drivers/crypto/montage/tsse/tsse_dev_mgr.c:13: In file included from include/linux/iommu.h:10: In file included from include/linux/scatterlist.h:8: In file included from include/linux/mm.h:1581: include/linux/vmstat.h:431:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 431 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ In file included from drivers/crypto/montage/tsse/tsse_dev_mgr.c:15: >> drivers/crypto/montage/tsse/tsse_dev.h:85:6: warning: variable 'cpu' set but not used [-Wunused-but-set-variable] 85 | int cpu, node; | ^ 2 warnings generated. -- In file included from drivers/crypto/montage/tsse/tsse_vuart.c:25: In file included from drivers/crypto/montage/tsse/tsse_dev.h:13: In file included from include/linux/pci.h:1499: In file included from include/linux/dmapool.h:14: In file included from include/linux/scatterlist.h:8: In file included from include/linux/mm.h:1581: include/linux/vmstat.h:431:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 431 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ In file included from drivers/crypto/montage/tsse/tsse_vuart.c:25: >> drivers/crypto/montage/tsse/tsse_dev.h:85:6: warning: variable 'cpu' set but not used [-Wunused-but-set-variable] 85 | int cpu, node; | ^ drivers/crypto/montage/tsse/tsse_vuart.c:77:13: warning: unused function 'vuart_wait_for_xmitr' [-Wunused-function] 77 | static void vuart_wait_for_xmitr(struct uart_port *port) | ^~~~~~~~~~~~~~~~~~~~ 3 warnings generated. Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for PGP_PRELOAD Depends on [n]: CRYPTO [=y] && ASYMMETRIC_KEY_TYPE [=n] Selected by [y]: - PGP_PRELOAD_PUBLIC_KEYS [=y] && CRYPTO [=y] vim +/cpu +85 drivers/crypto/montage/tsse/tsse_dev.h 82 83 static inline int tsse_get_cur_node(void) 84 { > 85 int cpu, node; 86 87 cpu = get_cpu(); 88 node = topology_physical_package_id(cpu); 89 put_cpu(); 90 91 return node; 92 } 93 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-22.03-LTS-SP1 0/2] fix CVE-2024-46675
by Lin Ruifeng 24 Oct '24

24 Oct '24

fix CVE-2024-46675 Krishna Kurapati (1): usb: dwc3: core: Skip setting event buffers for host only controllers Selvarasu Ganesan (1): usb: dwc3: core: Prevent USB core invalid event buffer address access drivers/usb/dwc3/core.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) -- 2.17.1

2 3

[PATCH openEuler-1.0-LTS 0/2] fix CVE-2024-46675
by Lin Ruifeng 24 Oct '24

24 Oct '24

fix CVE-2024-46675 Krishna Kurapati (1): usb: dwc3: core: Skip setting event buffers for host only controllers Selvarasu Ganesan (1): usb: dwc3: core: Prevent USB core invalid event buffer address access drivers/usb/dwc3/core.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) -- 2.17.1

2 3

[PATCH openEuler-22.03-LTS-SP1] nfsd: return -EINVAL when namelen is 0
by Li Lingfeng 24 Oct '24

24 Oct '24

mainline inclusion from mainline-v6.12-rc1 commit 22451a16b7ab7debefce660672566be887db1637 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYQ6P Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen. Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> Fixes: 74725959c33c ("nfsd: un-deprecate nfsdcld") Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Reviewed-by: Scott Mayhew <smayhew(a)redhat.com> Tested-by: Scott Mayhew <smayhew(a)redhat.com> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Conflicts: fs/nfsd/nfs4recover.c [Commit 30a30fcc3fc1 ("nfsd: Propagate some error code returned by memdup_user()") return PTR_ERR(name.data) instead of -EFAULT] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/nfs4recover.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c index 83c4e6883953..f2801eaea7c6 100644 --- a/fs/nfsd/nfs4recover.c +++ b/fs/nfsd/nfs4recover.c @@ -806,6 +806,10 @@ __cld_pipe_inprogress_downcall(const struct cld_msg_v2 __user *cmsg, ci = &cmsg->cm_u.cm_clntinfo; if (get_user(namelen, &ci->cc_name.cn_len)) return -EFAULT; + if (!namelen) { + dprintk("%s: namelen should not be zero", __func__); + return -EINVAL; + } name.data = memdup_user(&ci->cc_name.cn_id, namelen); if (IS_ERR_OR_NULL(name.data)) return -EFAULT; @@ -828,6 +832,10 @@ __cld_pipe_inprogress_downcall(const struct cld_msg_v2 __user *cmsg, cnm = &cmsg->cm_u.cm_name; if (get_user(namelen, &cnm->cn_len)) return -EFAULT; + if (!namelen) { + dprintk("%s: namelen should not be zero", __func__); + return -EINVAL; + } name.data = memdup_user(&cnm->cn_id, namelen); if (IS_ERR_OR_NULL(name.data)) return -EFAULT; -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS 1/2] usb: dwc3: core: Skip setting event buffers for host only controllers
by Lin Ruifeng 24 Oct '24

24 Oct '24

From: Krishna Kurapati <quic_kriskura(a)quicinc.com> stable inclusion from stable-v4.19.321 commit 320bb9a5a6b79ba123d1e1f746edb52b41c7c1fb bugzilla: https://gitee.com/src-openeuler/kernel/issues/ CVE: CVE-2024-46675 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 89d7f962994604a3e3d480832788d06179abefc5 ] On some SoC's like SA8295P where the tertiary controller is host-only capable, GEVTADDRHI/LO, GEVTSIZ, GEVTCOUNT registers are not accessible. Trying to access them leads to a crash. For DRD/Peripheral supported controllers, event buffer setup is done again in gadget_pullup. Skip setup or cleanup of event buffers if controller is host-only capable. Suggested-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Krishna Kurapati <quic_kriskura(a)quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org> Reviewed-by: Bjorn Andersson <andersson(a)kernel.org> Tested-by: Johan Hovold <johan+linaro(a)kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-4-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/usb/dwc3/core.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 8e3c23568faf..aa1f69464126 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -388,6 +388,13 @@ static void dwc3_free_event_buffers(struct dwc3 *dwc) static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length) { struct dwc3_event_buffer *evt; + unsigned int hw_mode; + + hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0); + if (hw_mode == DWC3_GHWPARAMS0_MODE_HOST) { + dwc->ev_buf = NULL; + return 0; + } evt = dwc3_alloc_one_event_buffer(dwc, length); if (IS_ERR(evt)) { @@ -409,6 +416,9 @@ int dwc3_event_buffers_setup(struct dwc3 *dwc) { struct dwc3_event_buffer *evt; + if (!dwc->ev_buf) + return 0; + evt = dwc->ev_buf; evt->lpos = 0; dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(0), @@ -426,6 +436,9 @@ void dwc3_event_buffers_cleanup(struct dwc3 *dwc) { struct dwc3_event_buffer *evt; + if (!dwc->ev_buf) + return; + evt = dwc->ev_buf; evt->lpos = 0; -- 2.17.1

2 2

[openeuler:OLK-5.10 28544/30000] drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c:2327:6: warning: no previous prototype for 'mcp251xfd_tx_obj_write_sync'
by kernel test robot 24 Oct '24

24 Oct '24

Hi Vitor, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 52e62ae625fcfe934330b24239cf61af5b5ce33f commit: b4eaf3e808dc2abcab55bc72df3b0d15961f33f0 [28544/30000] can: mcp251xfd: fix infinite loop when xmit fails config: x86_64-buildonly-randconfig-006-20241024 (https://download.01.org/0day-ci/archive/20241024/202410241814.11iTrBh6-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410241814.11iTrBh6-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410241814.11iTrBh6-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c:2327:6: warning: no previous prototype for 'mcp251xfd_tx_obj_write_sync' [-Wmissing-prototypes] 2327 | void mcp251xfd_tx_obj_write_sync(struct work_struct *work) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ vim +/mcp251xfd_tx_obj_write_sync +2327 drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c 2326 > 2327 void mcp251xfd_tx_obj_write_sync(struct work_struct *work) 2328 { 2329 struct mcp251xfd_priv *priv = container_of(work, struct mcp251xfd_priv, 2330 tx_work); 2331 struct mcp251xfd_tx_obj *tx_obj = priv->tx_work_obj; 2332 struct mcp251xfd_tx_ring *tx_ring = priv->tx; 2333 int err; 2334 2335 err = spi_sync(priv->spi, &tx_obj->msg); 2336 if (err) 2337 mcp251xfd_tx_failure_drop(priv, tx_ring, err); 2338 } 2339 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] cgroup: Protect css->cgroup write under css_set_lock
by Chen Ridong 24 Oct '24

24 Oct '24

From: Waiman Long <longman(a)redhat.com> stable inclusion from stable-v4.19.322 commit 6760357063f593a17613e015aed2051cfd4197c6 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYN0Z Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 57b56d16800e8961278ecff0dc755d46c4575092 ] The writing of css->cgroup associated with the cgroup root in rebind_subsystems() is currently protected only by cgroup_mutex. However, the reading of css->cgroup in both proc_cpuset_show() and proc_cgroup_show() is protected just by css_set_lock. That makes the readers susceptible to racing problems like data tearing or caching. It is also a problem that can be reported by KCSAN. This can be fixed by using READ_ONCE() and WRITE_ONCE() to access css->cgroup. Alternatively, the writing of css->cgroup can be moved under css_set_lock as well which is done by this patch. Signed-off-by: Waiman Long <longman(a)redhat.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Ridong <chenridong(a)huawei.com> --- kernel/cgroup/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 1339b93f7054..7b3c1491cc88 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -1717,9 +1717,9 @@ int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask) RCU_INIT_POINTER(scgrp->subsys[ssid], NULL); rcu_assign_pointer(dcgrp->subsys[ssid], css); ss->root = dst_root; - css->cgroup = dcgrp; spin_lock_irq(&css_set_lock); + css->cgroup = dcgrp; WARN_ON(!list_empty(&dcgrp->e_csets[ss->id])); list_for_each_entry_safe(cset, cset_pos, &scgrp->e_csets[ss->id], e_cset_node[ss->id]) { -- 2.34.1

2 2

[PATCH OLK-6.6] ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()
by Zhang Kunbo 24 Oct '24

24 Oct '24

From: Dan Carpenter <alexander.sverdlin(a)gmail.com> stable inclusion from stable-v6.6.54 commit 66e78ade976dbd9bea09166aa8d66afc0963cde4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYPJL CVE: CVE-2024-47686 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit c7f06284a6427475e3df742215535ec3f6cd9662 ] The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read. Fixes: 9645ccc7bd7a ("ep93xx: clock: convert in-place to COMMON_CLK") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Acked-by: Alexander Sverdlin <alexander.sverdlin(a)gmail.com> Reviewed-by: Nikita Shubin <nikita.shubin(a)maquefel.me> Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)gmail.com> Link: https://lore.kernel.org/r/1caf01ad4c0a8069535813c26c7f0b8ea011155e.camel@li… Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/arm/mach-ep93xx/clock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c index 85a496ddc619..e9f72a529b50 100644 --- a/arch/arm/mach-ep93xx/clock.c +++ b/arch/arm/mach-ep93xx/clock.c @@ -359,7 +359,7 @@ static unsigned long ep93xx_div_recalc_rate(struct clk_hw *hw, u32 val = __raw_readl(psc->reg); u8 index = (val & psc->mask) >> psc->shift; - if (index > psc->num_div) + if (index >= psc->num_div) return 0; return DIV_ROUND_UP_ULL(parent_rate, psc->div[index]); -- 2.34.1

2 1

[openeuler:OLK-5.10 24216/30000] drivers/net/dsa/mv88e6xxx/chip.c:2320:25: error: implicit declaration of function 'mv88e6xxx_g2_eeprom_wait'; did you mean 'mv88e6xxx_g2_pvt_write'?
by kernel test robot 24 Oct '24

24 Oct '24

Hi Fabio, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 5faf5aae71283199f69c2a60ed91ab2847f3ffd8 commit: 02956abc74ede6549249eb21e5b319b92dd147f3 [24216/30000] net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent config: x86_64-buildonly-randconfig-006-20241024 (https://download.01.org/0day-ci/archive/20241024/202410241622.JPCqkyC5-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410241622.JPCqkyC5-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202410241622.JPCqkyC5-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/net/dsa/mv88e6xxx/chip.c: In function 'mv88e6xxx_hardware_reset': >> drivers/net/dsa/mv88e6xxx/chip.c:2320:25: error: implicit declaration of function 'mv88e6xxx_g2_eeprom_wait'; did you mean 'mv88e6xxx_g2_pvt_write'? [-Werror=implicit-function-declaration] 2320 | mv88e6xxx_g2_eeprom_wait(chip); | ^~~~~~~~~~~~~~~~~~~~~~~~ | mv88e6xxx_g2_pvt_write cc1: some warnings being treated as errors vim +2320 drivers/net/dsa/mv88e6xxx/chip.c 2306 2307 static void mv88e6xxx_hardware_reset(struct mv88e6xxx_chip *chip) 2308 { 2309 struct gpio_desc *gpiod = chip->reset; 2310 2311 /* If there is a GPIO connected to the reset pin, toggle it */ 2312 if (gpiod) { 2313 /* If the switch has just been reset and not yet completed 2314 * loading EEPROM, the reset may interrupt the I2C transaction 2315 * mid-byte, causing the first EEPROM read after the reset 2316 * from the wrong location resulting in the switch booting 2317 * to wrong mode and inoperable. 2318 */ 2319 if (chip->info->ops->get_eeprom) > 2320 mv88e6xxx_g2_eeprom_wait(chip); 2321 2322 gpiod_set_value_cansleep(gpiod, 1); 2323 usleep_range(10000, 20000); 2324 gpiod_set_value_cansleep(gpiod, 0); 2325 usleep_range(10000, 20000); 2326 2327 if (chip->info->ops->get_eeprom) 2328 mv88e6xxx_g2_eeprom_wait(chip); 2329 } 2330 } 2331 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] wifi: mac80211: fix NULL dereference at band check in starting tx ba session
by Dong Chenchen 24 Oct '24

24 Oct '24

From: Zong-Zhe Yang <kevin_yang(a)realtek.com> mainline inclusion from mainline-v6.11-rc1 commit 021d53a3d87eeb9dbba524ac515651242a2a7e3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMMA0 CVE: CVE-2024-43911 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink. Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz Code starting with the faulting instruction =========================================== 0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator 3)) [ 9890.526353] ? ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 Signed-off-by: Zong-Zhe Yang <kevin_yang(a)realtek.com> Link: https://patch.msgid.link/20240617115217.22344-1-kevin_yang@realtek.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/mac80211/agg-tx.c [Conflicts due to different line numbers] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/mac80211/agg-tx.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c index 0a69e47f1c55..444edd6364c5 100644 --- a/net/mac80211/agg-tx.c +++ b/net/mac80211/agg-tx.c @@ -616,7 +616,9 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid, return -EINVAL; if (!pubsta->deflink.ht_cap.ht_supported && - sta->sdata->vif.bss_conf.chandef.chan->band != NL80211_BAND_6GHZ) + !pubsta->deflink.vht_cap.vht_supported && + !pubsta->deflink.he_cap.has_he && + !pubsta->deflink.eht_cap.has_eht) return -EINVAL; if (WARN_ON_ONCE(!local->ops->ampdu_action)) -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] wifi: mac80211: fix NULL dereference at band check in starting tx ba session
by Dong Chenchen 24 Oct '24

24 Oct '24

From: Zong-Zhe Yang <kevin_yang(a)realtek.com> mainline inclusion from mainline-v6.11-rc1 commit 021d53a3d87eeb9dbba524ac515651242a2a7e3b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAMMA0 CVE: CVE-2024-43911 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink. Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz Code starting with the faulting instruction =========================================== 0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator 3)) [ 9890.526353] ? ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 Signed-off-by: Zong-Zhe Yang <kevin_yang(a)realtek.com> Link: https://patch.msgid.link/20240617115217.22344-1-kevin_yang@realtek.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Conflicts: net/mac80211/agg-tx.c [commit a1de64078bf7 add eht_cap to response with EHT, and commit 046d2e7c50e3 add struct ieee80211_link_sta, which lead to context conflicts.] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/mac80211/agg-tx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c index 92e5812daf89..433009b3e8ab 100644 --- a/net/mac80211/agg-tx.c +++ b/net/mac80211/agg-tx.c @@ -599,7 +599,8 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid, return -EINVAL; if (!pubsta->ht_cap.ht_supported && - sta->sdata->vif.bss_conf.chandef.chan->band != NL80211_BAND_6GHZ) + !pubsta->vht_cap.vht_supported && + !pubsta->he_cap.has_he) return -EINVAL; if (WARN_ON_ONCE(!local->ops->ampdu_action)) -- 2.25.1

2 3

[PATCH OLK-5.10 0/1] fix CVE-2024-49954
by Liao Chen 24 Oct '24

24 Oct '24

fix CVE-2024-49954 Thomas Gleixner (1): [Backport] static_call: Replace pointless WARN_ON() in static_call_module_notify() kernel/static_call_inline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 4

[PATCH openEuler-22.03-LTS-SP1 0/1] fix CVE-2024-49954
by Liao Chen 24 Oct '24

24 Oct '24

fix CVE-2024-49954 Thomas Gleixner (1): [Backport] static_call: Replace pointless WARN_ON() in static_call_module_notify() kernel/static_call_inline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-6.6 0/1] fix CVE-2024-49954
by Liao Chen 24 Oct '24

24 Oct '24

fix CVE-2024-49954 Thomas Gleixner (1): [Backport] static_call: Replace pointless WARN_ON() in static_call_module_notify() kernel/static_call_inline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-5.10] x86/ioapic: Handle allocation failures gracefully
by Jinjie Ruan 24 Oct '24

24 Oct '24

From: Thomas Gleixner <tglx(a)linutronix.de> stable inclusion from stable-v5.15.168 commit e479cb835feeb2abff97f25766e23b96a6eabe28 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCY CVE: CVE-2024-49927 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f ] Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully. Reported-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Breno Leitao <leitao(a)debian.org> Tested-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Link: https://lore.kernel.org/all/ZqfJmUF8sXIyuSHN@gmail.com Link: https://lore.kernel.org/all/20240802155440.275200843@linutronix.de Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/x86/kernel/apic/io_apic.c [adjust context conflicts] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/x86/kernel/apic/io_apic.c | 46 ++++++++++++++++------------------ 1 file changed, 22 insertions(+), 24 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index cce1f31e7187..e650fd82a5d0 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -358,27 +358,26 @@ static void ioapic_mask_entry(int apic, int pin) * shared ISA-space IRQs, so we have to support them. We are super * fast in the common case, and fast for shared ISA-space IRQs. */ -static int __add_pin_to_irq_node(struct mp_chip_data *data, - int node, int apic, int pin) +static bool add_pin_to_irq_node(struct mp_chip_data *data, int node, int apic, int pin) { struct irq_pin_list *entry; - /* don't allow duplicates */ - for_each_irq_pin(entry, data->irq_2_pin) + /* Don't allow duplicates */ + for_each_irq_pin(entry, data->irq_2_pin) { if (entry->apic == apic && entry->pin == pin) - return 0; + return true; + } entry = kzalloc_node(sizeof(struct irq_pin_list), GFP_ATOMIC, node); if (!entry) { - pr_err("can not alloc irq_pin_list (%d,%d,%d)\n", - node, apic, pin); - return -ENOMEM; + pr_err("Cannot allocate irq_pin_list (%d,%d,%d)\n", node, apic, pin); + return false; } + entry->apic = apic; entry->pin = pin; list_add_tail(&entry->list, &data->irq_2_pin); - - return 0; + return true; } static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin) @@ -393,13 +392,6 @@ static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin) } } -static void add_pin_to_irq_node(struct mp_chip_data *data, - int node, int apic, int pin) -{ - if (__add_pin_to_irq_node(data, node, apic, pin)) - panic("IO-APIC: failed to add irq-pin. Can not proceed\n"); -} - /* * Reroute an IRQ to a different pin. */ @@ -1001,8 +993,7 @@ static int alloc_isa_irq_from_domain(struct irq_domain *domain, if (irq_data && irq_data->parent_data) { if (!mp_check_pin_attr(irq, info)) return -EBUSY; - if (__add_pin_to_irq_node(irq_data->chip_data, node, ioapic, - info->ioapic.pin)) + if (!add_pin_to_irq_node(irq_data->chip_data, node, ioapic, info->ioapic.pin)) return -ENOMEM; } else { info->flags |= X86_IRQ_ALLOC_LEGACY; @@ -3032,10 +3023,8 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, info->ioapic.entry = &data->entry; ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, info); - if (ret < 0) { - kfree(data); - return ret; - } + if (ret < 0) + goto free_data; INIT_LIST_HEAD(&data->irq_2_pin); irq_data->hwirq = info->ioapic.pin; @@ -3045,7 +3034,10 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, mp_irqdomain_get_attr(mp_pin_to_gsi(ioapic, pin), data, info); cfg = irqd_cfg(irq_data); - add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin); + if (!add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin)) { + ret = -ENOMEM; + goto free_irqs; + } local_irq_save(flags); if (info->ioapic.entry) @@ -3061,6 +3053,12 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, virq, data->trigger, data->polarity, cfg->dest_apicid); return 0; + +free_irqs: + irq_domain_free_irqs_parent(domain, virq, nr_irqs); +free_data: + kfree(data); + return ret; } void mp_irqdomain_free(struct irq_domain *domain, unsigned int virq, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] x86/ioapic: Handle allocation failures gracefully
by Jinjie Ruan 24 Oct '24

24 Oct '24

From: Thomas Gleixner <tglx(a)linutronix.de> stable inclusion from stable-v5.15.168 commit e479cb835feeb2abff97f25766e23b96a6eabe28 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCY CVE: CVE-2024-49927 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f ] Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully. Reported-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Breno Leitao <leitao(a)debian.org> Tested-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Link: https://lore.kernel.org/all/ZqfJmUF8sXIyuSHN@gmail.com Link: https://lore.kernel.org/all/20240802155440.275200843@linutronix.de Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: arch/x86/kernel/apic/io_apic.c [adjust context conflicts] Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/x86/kernel/apic/io_apic.c | 46 ++++++++++++++++------------------ 1 file changed, 22 insertions(+), 24 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index a63366344fcf..b183a49525d2 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -371,27 +371,26 @@ static void ioapic_mask_entry(int apic, int pin) * shared ISA-space IRQs, so we have to support them. We are super * fast in the common case, and fast for shared ISA-space IRQs. */ -static int __add_pin_to_irq_node(struct mp_chip_data *data, - int node, int apic, int pin) +static bool add_pin_to_irq_node(struct mp_chip_data *data, int node, int apic, int pin) { struct irq_pin_list *entry; - /* don't allow duplicates */ - for_each_irq_pin(entry, data->irq_2_pin) + /* Don't allow duplicates */ + for_each_irq_pin(entry, data->irq_2_pin) { if (entry->apic == apic && entry->pin == pin) - return 0; + return true; + } entry = kzalloc_node(sizeof(struct irq_pin_list), GFP_ATOMIC, node); if (!entry) { - pr_err("can not alloc irq_pin_list (%d,%d,%d)\n", - node, apic, pin); - return -ENOMEM; + pr_err("Cannot allocate irq_pin_list (%d,%d,%d)\n", node, apic, pin); + return false; } + entry->apic = apic; entry->pin = pin; list_add_tail(&entry->list, &data->irq_2_pin); - - return 0; + return true; } static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin) @@ -406,13 +405,6 @@ static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin) } } -static void add_pin_to_irq_node(struct mp_chip_data *data, - int node, int apic, int pin) -{ - if (__add_pin_to_irq_node(data, node, apic, pin)) - panic("IO-APIC: failed to add irq-pin. Can not proceed\n"); -} - /* * Reroute an IRQ to a different pin. */ @@ -1012,8 +1004,7 @@ static int alloc_isa_irq_from_domain(struct irq_domain *domain, if (irq_data && irq_data->parent_data) { if (!mp_check_pin_attr(irq, info)) return -EBUSY; - if (__add_pin_to_irq_node(irq_data->chip_data, node, ioapic, - info->ioapic_pin)) + if (!add_pin_to_irq_node(irq_data->chip_data, node, ioapic, info->ioapic.pin)) return -ENOMEM; } else { info->flags |= X86_IRQ_ALLOC_LEGACY; @@ -2993,10 +2984,8 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, info->ioapic_entry = &data->entry; ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, info); - if (ret < 0) { - kfree(data); - return ret; - } + if (ret < 0) + goto free_data; INIT_LIST_HEAD(&data->irq_2_pin); irq_data->hwirq = info->ioapic_pin; @@ -3006,7 +2995,10 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, mp_irqdomain_get_attr(mp_pin_to_gsi(ioapic, pin), data, info); cfg = irqd_cfg(irq_data); - add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin); + if (!add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin)) { + ret = -ENOMEM; + goto free_irqs; + } local_irq_save(flags); if (info->ioapic_entry) @@ -3022,6 +3014,12 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, virq, data->trigger, data->polarity, cfg->dest_apicid); return 0; + +free_irqs: + irq_domain_free_irqs_parent(domain, virq, nr_irqs); +free_data: + kfree(data); + return ret; } void mp_irqdomain_free(struct irq_domain *domain, unsigned int virq, -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/1] fix CVE-2022-49011
by Liao Chen 24 Oct '24

24 Oct '24

fix CVE-2022-49011 Yang Yingliang (1): hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() drivers/hwmon/coretemp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS 0/1] fix CVE-2022-49011
by Liao Chen 24 Oct '24

24 Oct '24

fix CVE-2022-49011 Yang Yingliang (1): hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() drivers/hwmon/coretemp.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-6.6] x86/ioapic: Handle allocation failures gracefully
by Jinjie Ruan 24 Oct '24

24 Oct '24

From: Thomas Gleixner <tglx(a)linutronix.de> stable inclusion from stable-v6.6.55 commit 077e1b7cd521163ded545987bbbd389519aeed71 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCY CVE: CVE-2024-49927 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f ] Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully. Reported-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Tested-by: Breno Leitao <leitao(a)debian.org> Tested-by: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com> Link: https://lore.kernel.org/all/ZqfJmUF8sXIyuSHN@gmail.com Link: https://lore.kernel.org/all/20240802155440.275200843@linutronix.de Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/x86/kernel/apic/io_apic.c | 46 ++++++++++++++++------------------ 1 file changed, 22 insertions(+), 24 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 00da6cf6b07d..d0c5325d1751 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -352,27 +352,26 @@ static void ioapic_mask_entry(int apic, int pin) * shared ISA-space IRQs, so we have to support them. We are super * fast in the common case, and fast for shared ISA-space IRQs. */ -static int __add_pin_to_irq_node(struct mp_chip_data *data, - int node, int apic, int pin) +static bool add_pin_to_irq_node(struct mp_chip_data *data, int node, int apic, int pin) { struct irq_pin_list *entry; - /* don't allow duplicates */ - for_each_irq_pin(entry, data->irq_2_pin) + /* Don't allow duplicates */ + for_each_irq_pin(entry, data->irq_2_pin) { if (entry->apic == apic && entry->pin == pin) - return 0; + return true; + } entry = kzalloc_node(sizeof(struct irq_pin_list), GFP_ATOMIC, node); if (!entry) { - pr_err("can not alloc irq_pin_list (%d,%d,%d)\n", - node, apic, pin); - return -ENOMEM; + pr_err("Cannot allocate irq_pin_list (%d,%d,%d)\n", node, apic, pin); + return false; } + entry->apic = apic; entry->pin = pin; list_add_tail(&entry->list, &data->irq_2_pin); - - return 0; + return true; } static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin) @@ -387,13 +386,6 @@ static void __remove_pin_from_irq(struct mp_chip_data *data, int apic, int pin) } } -static void add_pin_to_irq_node(struct mp_chip_data *data, - int node, int apic, int pin) -{ - if (__add_pin_to_irq_node(data, node, apic, pin)) - panic("IO-APIC: failed to add irq-pin. Can not proceed\n"); -} - /* * Reroute an IRQ to a different pin. */ @@ -1002,8 +994,7 @@ static int alloc_isa_irq_from_domain(struct irq_domain *domain, if (irq_data && irq_data->parent_data) { if (!mp_check_pin_attr(irq, info)) return -EBUSY; - if (__add_pin_to_irq_node(irq_data->chip_data, node, ioapic, - info->ioapic.pin)) + if (!add_pin_to_irq_node(irq_data->chip_data, node, ioapic, info->ioapic.pin)) return -ENOMEM; } else { info->flags |= X86_IRQ_ALLOC_LEGACY; @@ -3037,10 +3028,8 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, return -ENOMEM; ret = irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, info); - if (ret < 0) { - kfree(data); - return ret; - } + if (ret < 0) + goto free_data; INIT_LIST_HEAD(&data->irq_2_pin); irq_data->hwirq = info->ioapic.pin; @@ -3049,7 +3038,10 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, irq_data->chip_data = data; mp_irqdomain_get_attr(mp_pin_to_gsi(ioapic, pin), data, info); - add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin); + if (!add_pin_to_irq_node(data, ioapic_alloc_attr_node(info), ioapic, pin)) { + ret = -ENOMEM; + goto free_irqs; + } mp_preconfigure_entry(data); mp_register_handler(virq, data->is_level); @@ -3064,6 +3056,12 @@ int mp_irqdomain_alloc(struct irq_domain *domain, unsigned int virq, ioapic, mpc_ioapic_id(ioapic), pin, virq, data->is_level, data->active_low); return 0; + +free_irqs: + irq_domain_free_irqs_parent(domain, virq, nr_irqs); +free_data: + kfree(data); + return ret; } void mp_irqdomain_free(struct irq_domain *domain, unsigned int virq, -- 2.34.1

2 4

[PATCH openEuler-22.03-LTS-SP1] hwmon: (nct6775-core) Fix underflows seen when writing limit attributes
by Lin Ruifeng 24 Oct '24

24 Oct '24

From: Guenter Roeck <linux(a)roeck-us.net> stable inclusion from stable-v5.10.226 commit 8a1e958e26640ce015abdbb75c8896301b9bf398 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IARWFE CVE: CVE-2024-46757 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 0403e10bf0824bf0ec2bb135d4cf1c0cc3bf4bf0 ] DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/hwmon/nct6775.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwmon/nct6775.c b/drivers/hwmon/nct6775.c index 5bd15622a85f..3645a19cdaf4 100644 --- a/drivers/hwmon/nct6775.c +++ b/drivers/hwmon/nct6775.c @@ -2374,7 +2374,7 @@ store_temp_offset(struct device *dev, struct device_attribute *attr, if (err < 0) return err; - val = clamp_val(DIV_ROUND_CLOSEST(val, 1000), -128, 127); + val = DIV_ROUND_CLOSEST(clamp_val(val, -128000, 127000), 1000); mutex_lock(&data->update_lock); data->temp_offset[nr] = val; -- 2.17.1

2 3