- Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1] sysctl: always initialize i_uid/i_gid
by Long Li 23 Aug '24

23 Aug '24

From: Thomas Weißschuh <linux(a)weissschuh.net> stable inclusion from stable-v5.10.223 commit b2591c89a6e2858796111138c38fcb6851aa1955 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ93 CVE: CVE-2024-42312 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 98ca62ba9e2be5863c7d069f84f7166b45a5b2f4 ] Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them. Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed. Fixes: 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> Signed-off-by: Joel Granados <j.granados(a)samsung.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/proc/proc_sysctl.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c index df435cd91a5b..91d15cdabb27 100644 --- a/fs/proc/proc_sysctl.c +++ b/fs/proc/proc_sysctl.c @@ -471,12 +471,10 @@ static struct inode *proc_sys_make_inode(struct super_block *sb, make_empty_dir_inode(inode); } + inode->i_uid = GLOBAL_ROOT_UID; + inode->i_gid = GLOBAL_ROOT_GID; if (root->set_ownership) root->set_ownership(head, table, &inode->i_uid, &inode->i_gid); - else { - inode->i_uid = GLOBAL_ROOT_UID; - inode->i_gid = GLOBAL_ROOT_GID; - } return inode; } -- 2.39.2

2 1

[PATCH OLK-5.10] sysctl: always initialize i_uid/i_gid
by Long Li 23 Aug '24

23 Aug '24

From: Thomas Weißschuh <linux(a)weissschuh.net> stable inclusion from stable-v5.10.223 commit b2591c89a6e2858796111138c38fcb6851aa1955 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ93 CVE: CVE-2024-42312 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=… -------------------------------- [ Upstream commit 98ca62ba9e2be5863c7d069f84f7166b45a5b2f4 ] Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them. Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed. Fixes: 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> Signed-off-by: Joel Granados <j.granados(a)samsung.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/proc/proc_sysctl.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c index 1b9bc52bac88..d018184a1719 100644 --- a/fs/proc/proc_sysctl.c +++ b/fs/proc/proc_sysctl.c @@ -471,12 +471,10 @@ static struct inode *proc_sys_make_inode(struct super_block *sb, make_empty_dir_inode(inode); } + inode->i_uid = GLOBAL_ROOT_UID; + inode->i_gid = GLOBAL_ROOT_GID; if (root->set_ownership) root->set_ownership(head, table, &inode->i_uid, &inode->i_gid); - else { - inode->i_uid = GLOBAL_ROOT_UID; - inode->i_gid = GLOBAL_ROOT_GID; - } return inode; } -- 2.39.2

2 1

[PATCH OLK-6.6] cpufreq: CPPC: Eliminate the impact of cpc_read() latency error
by Zeng Heng 23 Aug '24

23 Aug '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9COT9 Reference: https://gitee.com/openeuler/kernel/commit/7404f3db35e32493b64696a2ba1457226… ---------------------------------------- We have found significant differences in the latency of cpc_read() between regular scenarios and scenarios with high memory access pressure. Ignoring this error can result in getting rate interface occasionally returning absurd values. Here provides a high memory access sample test by stress-ng. My local testing platform includes 160 CPUs, the CPC registers is accessed by mmio method, and the cpuidle feature is disabled (the AMU always works online): ~~~ ./stress-ng --memrate 160 --timeout 180 ~~~ The following data is sourced from ftrace statistics towards cppc_get_perf_ctrs(): Regular scenarios || High memory access pressure scenarios 104) | cppc_get_perf_ctrs() { || 133) | cppc_get_perf_ctrs() { 104) 0.800 us | cpc_read.isra.0(); || 133) 4.580 us | cpc_read.isra.0(); 104) 0.640 us | cpc_read.isra.0(); || 133) 7.780 us | cpc_read.isra.0(); 104) 0.450 us | cpc_read.isra.0(); || 133) 2.550 us | cpc_read.isra.0(); 104) 0.430 us | cpc_read.isra.0(); || 133) 0.570 us | cpc_read.isra.0(); 104) 4.610 us | } || 133) ! 157.610 us | } 104) | cppc_get_perf_ctrs() { || 133) | cppc_get_perf_ctrs() { 104) 0.720 us | cpc_read.isra.0(); || 133) 0.760 us | cpc_read.isra.0(); 104) 0.720 us | cpc_read.isra.0(); || 133) 4.480 us | cpc_read.isra.0(); 104) 0.510 us | cpc_read.isra.0(); || 133) 0.520 us | cpc_read.isra.0(); 104) 0.500 us | cpc_read.isra.0(); || 133) + 10.100 us | cpc_read.isra.0(); 104) 3.460 us | } || 133) ! 120.850 us | } 108) | cppc_get_perf_ctrs() { || 87) | cppc_get_perf_ctrs() { 108) 0.820 us | cpc_read.isra.0(); || 87) ! 255.200 us | cpc_read.isra.0(); 108) 0.850 us | cpc_read.isra.0(); || 87) 2.910 us | cpc_read.isra.0(); 108) 0.590 us | cpc_read.isra.0(); || 87) 5.160 us | cpc_read.isra.0(); 108) 0.610 us | cpc_read.isra.0(); || 87) 4.340 us | cpc_read.isra.0(); 108) 5.080 us | } || 87) ! 315.790 us | } 108) | cppc_get_perf_ctrs() { || 87) | cppc_get_perf_ctrs() { 108) 0.630 us | cpc_read.isra.0(); || 87) 0.800 us | cpc_read.isra.0(); 108) 0.630 us | cpc_read.isra.0(); || 87) 6.310 us | cpc_read.isra.0(); 108) 0.420 us | cpc_read.isra.0(); || 87) 1.190 us | cpc_read.isra.0(); 108) 0.430 us | cpc_read.isra.0(); || 87) + 11.620 us | cpc_read.isra.0(); 108) 3.780 us | } || 87) ! 207.010 us | } My local testing platform works under 3000000hz, but the cpuinfo_cur_freq interface returns values that are not even close to the actual frequency: [root@localhost ~]# cd /sys/devices/system/cpu [root@localhost cpu]# for i in {0..159}; do cat cpu$i/cpufreq/cpuinfo_cur_freq; done 5127812 2952127 3069001 3496183 922989768 2419194 3427042 2331869 3594611 8238499 ... The reason is when under heavy memory access pressure, the execution of cpc_read() delay has increased from sub-microsecond to several hundred microseconds. Moving the cpc_read function into a critical section by irq disable/enable has minimal impact on the result. cppc_get_perf_ctrs()[0] cppc_get_perf_ctrs()[1] / \ / \ cpc_read cpc_read cpc_read cpc_read ref[0] delivered[0] ref[1] delivered[1] | | | | v v v v -----------------------------------------------------------------------> time <--delta[0]--> <------sample_period------> <-----delta[1]-----> Since that, freq = ref_freq * (delivered[1] - delivered[0]) / (ref[1] - ref[0]) and delivered[1] - delivered[0] = freq * (delta[1] + sample_period), ref[1] - ref[0] = ref_freq * (delta[0] + sample_period) To eliminate the impact of system memory access latency, setting a sampling period of 2us is far from sufficient. Consequently, we suggest cppc_cpufreq_get_rate() only can be called in the process context, and adopt a longer sampling period to neutralize the impact of random latency. Here we call the cond_resched() function instead of sleep-like functions to ensure that AMU remains in work state but not cstate during sample period. Fixes: 33477d84c26b ("cpufreq / CPPC: Add cpuinfo_cur_freq support for CPPC") Reported-by: Yang Shi <yang(a)os.amperecomputing.com> Link: https://lore.kernel.org/all/20230328193846.8757-1-yang@os.amperecomputing.c… Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/cpufreq/cppc_cpufreq.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index 321a9dc9484d..66e8c850e6f2 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -851,12 +851,25 @@ static int cppc_get_perf_ctrs_pair(void *val) struct fb_ctr_pair *fb_ctrs = val; int cpu = fb_ctrs->cpu; int ret; + unsigned long timeout; ret = cppc_get_perf_ctrs(cpu, &fb_ctrs->fb_ctrs_t0); if (ret) return ret; - udelay(2); /* 2usec delay between sampling */ + if (likely(!in_atomic() && !irqs_disabled())) { + /* + * Set 1ms as sampling interval, but never schedule + * to the idle task to prevent the AMU counters from + * stopping working. + */ + timeout = jiffies + msecs_to_jiffies(1); + while (!time_after(jiffies, timeout)) + cond_resched(); + } else { + pr_warn_once("CPU%d: Get rate in atomic context", cpu); + udelay(2); /* 2usec delay between sampling */ + } return cppc_get_perf_ctrs(cpu, &fb_ctrs->fb_ctrs_t1); } -- 2.25.1

2 1

[PATCH OLK-5.10] drm/amd/display: Check for NULL pointer
by Peng Zhang 23 Aug '24

23 Aug '24

From: Sung Joon Kim <sungjoon.kim(a)amd.com> mainline inclusion from mainline-v6.11-rc1 commit 4ab68e168ae1695f7c04fae98930740aaf7c50fa category: bugfix bugzilla: 190260 CVE: CVE-2024-42308 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [why & how] Need to make sure plane_state is initialized before accessing its members. Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Reviewed-by: Xi (Alex) Liu <xi.liu(a)amd.com> Signed-off-by: Sung Joon Kim <sungjoon.kim(a)amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 295d91cbc700651782a60572f83c24861607b648) Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/core/dc_surface.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c index 3d7d27435f15..98391ba103d6 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c @@ -154,7 +154,8 @@ const struct dc_plane_status *dc_plane_get_status( if (pipe_ctx->plane_state != plane_state) continue; - pipe_ctx->plane_state->status.is_flip_pending = false; + if (pipe_ctx->plane_state) + pipe_ctx->plane_state->status.is_flip_pending = false; break; } -- 2.25.1

2 1

[PATCH OLK-6.6] cpufreq: CPPC: Eliminate the impact of cpc_read() latency error
by Zeng Heng 23 Aug '24

23 Aug '24

openEuler inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9COT9 Reference: https://gitee.com/openeuler/kernel/commit/7404f3db35e32493b64696a2ba1457226… ---------------------------------------- We have found significant differences in the latency of cpc_read() between regular scenarios and scenarios with high memory access pressure. Ignoring this error can result in getting rate interface occasionally returning absurd values. Here provides a high memory access sample test by stress-ng. My local testing platform includes 160 CPUs, the CPC registers is accessed by mmio method, and the cpuidle feature is disabled (the AMU always works online): ~~~ ./stress-ng --memrate 160 --timeout 180 ~~~ The following data is sourced from ftrace statistics towards cppc_get_perf_ctrs(): Regular scenarios || High memory access pressure scenarios 104) | cppc_get_perf_ctrs() { || 133) | cppc_get_perf_ctrs() { 104) 0.800 us | cpc_read.isra.0(); || 133) 4.580 us | cpc_read.isra.0(); 104) 0.640 us | cpc_read.isra.0(); || 133) 7.780 us | cpc_read.isra.0(); 104) 0.450 us | cpc_read.isra.0(); || 133) 2.550 us | cpc_read.isra.0(); 104) 0.430 us | cpc_read.isra.0(); || 133) 0.570 us | cpc_read.isra.0(); 104) 4.610 us | } || 133) ! 157.610 us | } 104) | cppc_get_perf_ctrs() { || 133) | cppc_get_perf_ctrs() { 104) 0.720 us | cpc_read.isra.0(); || 133) 0.760 us | cpc_read.isra.0(); 104) 0.720 us | cpc_read.isra.0(); || 133) 4.480 us | cpc_read.isra.0(); 104) 0.510 us | cpc_read.isra.0(); || 133) 0.520 us | cpc_read.isra.0(); 104) 0.500 us | cpc_read.isra.0(); || 133) + 10.100 us | cpc_read.isra.0(); 104) 3.460 us | } || 133) ! 120.850 us | } 108) | cppc_get_perf_ctrs() { || 87) | cppc_get_perf_ctrs() { 108) 0.820 us | cpc_read.isra.0(); || 87) ! 255.200 us | cpc_read.isra.0(); 108) 0.850 us | cpc_read.isra.0(); || 87) 2.910 us | cpc_read.isra.0(); 108) 0.590 us | cpc_read.isra.0(); || 87) 5.160 us | cpc_read.isra.0(); 108) 0.610 us | cpc_read.isra.0(); || 87) 4.340 us | cpc_read.isra.0(); 108) 5.080 us | } || 87) ! 315.790 us | } 108) | cppc_get_perf_ctrs() { || 87) | cppc_get_perf_ctrs() { 108) 0.630 us | cpc_read.isra.0(); || 87) 0.800 us | cpc_read.isra.0(); 108) 0.630 us | cpc_read.isra.0(); || 87) 6.310 us | cpc_read.isra.0(); 108) 0.420 us | cpc_read.isra.0(); || 87) 1.190 us | cpc_read.isra.0(); 108) 0.430 us | cpc_read.isra.0(); || 87) + 11.620 us | cpc_read.isra.0(); 108) 3.780 us | } || 87) ! 207.010 us | } My local testing platform works under 3000000hz, but the cpuinfo_cur_freq interface returns values that are not even close to the actual frequency: [root@localhost ~]# cd /sys/devices/system/cpu [root@localhost cpu]# for i in {0..159}; do cat cpu$i/cpufreq/cpuinfo_cur_freq; done 5127812 2952127 3069001 3496183 922989768 2419194 3427042 2331869 3594611 8238499 ... The reason is when under heavy memory access pressure, the execution of cpc_read() delay has increased from sub-microsecond to several hundred microseconds. Moving the cpc_read function into a critical section by irq disable/enable has minimal impact on the result. cppc_get_perf_ctrs()[0] cppc_get_perf_ctrs()[1] / \ / \ cpc_read cpc_read cpc_read cpc_read ref[0] delivered[0] ref[1] delivered[1] | | | | v v v v -----------------------------------------------------------------------> time <--delta[0]--> <------sample_period------> <-----delta[1]-----> Since that, freq = ref_freq * (delivered[1] - delivered[0]) / (ref[1] - ref[0]) and delivered[1] - delivered[0] = freq * (delta[1] + sample_period), ref[1] - ref[0] = ref_freq * (delta[0] + sample_period) To eliminate the impact of system memory access latency, setting a sampling period of 2us is far from sufficient. Consequently, we suggest cppc_cpufreq_get_rate() only can be called in the process context, and adopt a longer sampling period to neutralize the impact of random latency. Here we call the cond_resched() function instead of sleep-like functions to ensure that AMU remains in work state but not cstate during sample period. Fixes: 33477d84c26b ("cpufreq / CPPC: Add cpuinfo_cur_freq support for CPPC") Reported-by: Yang Shi <yang(a)os.amperecomputing.com> Link: https://lore.kernel.org/all/20230328193846.8757-1-yang@os.amperecomputing.c… Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/cpufreq/cppc_cpufreq.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c index 321a9dc9484d..66e8c850e6f2 100644 --- a/drivers/cpufreq/cppc_cpufreq.c +++ b/drivers/cpufreq/cppc_cpufreq.c @@ -851,12 +851,25 @@ static int cppc_get_perf_ctrs_pair(void *val) struct fb_ctr_pair *fb_ctrs = val; int cpu = fb_ctrs->cpu; int ret; + unsigned long timeout; ret = cppc_get_perf_ctrs(cpu, &fb_ctrs->fb_ctrs_t0); if (ret) return ret; - udelay(2); /* 2usec delay between sampling */ + if (likely(!in_atomic() && !irqs_disabled())) { + /* + * Set 1ms as sampling interval, but never schedule + * to the idle task to prevent the AMU counters from + * stopping working. + */ + timeout = jiffies + msecs_to_jiffies(1); + while (!time_after(jiffies, timeout)) + cond_resched(); + } else { + pr_warn_once("CPU%d: Get rate in atomic context", cpu); + udelay(2); /* 2usec delay between sampling */ + } return cppc_get_perf_ctrs(cpu, &fb_ctrs->fb_ctrs_t1); } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/amd/display: Check for NULL pointer
by Peng Zhang 23 Aug '24

23 Aug '24

From: Sung Joon Kim <sungjoon.kim(a)amd.com> mainline inclusion from mainline-v6.11-rc1 commit 4ab68e168ae1695f7c04fae98930740aaf7c50fa category: bugfix bugzilla: 190260 CVE: CVE-2024-42308 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [why & how] Need to make sure plane_state is initialized before accessing its members. Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org Reviewed-by: Xi (Alex) Liu <xi.liu(a)amd.com> Signed-off-by: Sung Joon Kim <sungjoon.kim(a)amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 295d91cbc700651782a60572f83c24861607b648) Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/core/dc_surface.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c index 3d7d27435f15..98391ba103d6 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c @@ -154,7 +154,8 @@ const struct dc_plane_status *dc_plane_get_status( if (pipe_ctx->plane_state != plane_state) continue; - pipe_ctx->plane_state->status.is_flip_pending = false; + if (pipe_ctx->plane_state) + pipe_ctx->plane_state->status.is_flip_pending = false; break; } -- 2.25.1

2 1

[PATCH OLK-6.6 0/2] CVE-2024-43868
by Yuntao Liu 23 Aug '24

23 Aug '24

CVE-2024-43868 Clément Léger (1): riscv: Use SYM_*() assembly macros instead of deprecated ones Daniel Maslowski (1): riscv/purgatory: align riscv_kernel_entry arch/riscv/kernel/copy-unaligned.S | 8 ++++---- arch/riscv/kernel/fpu.S | 8 ++++---- arch/riscv/kernel/head.S | 12 +++++------ arch/riscv/kernel/hibernate-asm.S | 12 +++++------ arch/riscv/kernel/mcount-dyn.S | 20 ++++++++----------- arch/riscv/kernel/mcount.S | 8 ++++---- arch/riscv/kernel/probes/rethook_trampoline.S | 4 ++-- arch/riscv/kernel/suspend_entry.S | 4 ++-- arch/riscv/kernel/vdso/flush_icache.S | 4 ++-- arch/riscv/kernel/vdso/getcpu.S | 4 ++-- arch/riscv/kernel/vdso/rt_sigreturn.S | 4 ++-- arch/riscv/kernel/vdso/sys_hwprobe.S | 4 ++-- arch/riscv/lib/memcpy.S | 6 +++--- arch/riscv/lib/memmove.S | 3 +-- arch/riscv/lib/memset.S | 6 +++--- arch/riscv/lib/uaccess.S | 11 +++++----- arch/riscv/purgatory/entry.S | 18 ++++++----------- 17 files changed, 62 insertions(+), 74 deletions(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS 0/2] fix hardlockup when cat /proc/slabinfo
by Jinjiang Tu 23 Aug '24

23 Aug '24

Jianfeng Wang (2): slub: introduce count_partial_free_approx() slub: use count_partial_free_approx() in slab_out_of_memory() mm/slub.c | 41 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 39 insertions(+), 2 deletions(-) -- 2.25.1

2 3

[openEuler-1.0-LTS 0/2] fix hardlockup when cat /proc/slabinfo
by Jinjiang Tu 23 Aug '24

23 Aug '24

Jianfeng Wang (2): slub: introduce count_partial_free_approx() slub: use count_partial_free_approx() in slab_out_of_memory() mm/slub.c | 41 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 39 insertions(+), 2 deletions(-) -- 2.25.1

1 2

[PATCH OLK-5.10] soc: qcom: pdr: protect locator_addr with the main mutex
by Li Nan 23 Aug '24

23 Aug '24

From: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> stable inclusion from stable-v5.10.224 commit eab05737ee22216250fe20d27f5a596da5ea6eb7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ5M CVE: CVE-2024-43849 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 107924c14e3ddd85119ca43c26a4ee1056fa9b84 ] If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock. Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Tested-by: Neil Armstrong <neil.armstrong(a)linaro.org> # on SM8550-QRD Tested-by: Steev Klimaszewski <steev(a)kali.org> Tested-by: Alexey Minnekhanov <alexeymin(a)postmarketos.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Link: https://lore.kernel.org/r/20240622-qcom-pd-mapper-v9-1-a84ee3591c8e@linaro.… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Nan <linan122(a)huawei.com> --- drivers/soc/qcom/pdr_interface.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c index 205cc96823b7..373725b6d544 100644 --- a/drivers/soc/qcom/pdr_interface.c +++ b/drivers/soc/qcom/pdr_interface.c @@ -76,12 +76,12 @@ static int pdr_locator_new_server(struct qmi_handle *qmi, locator_hdl); struct pdr_service *pds; + mutex_lock(&pdr->lock); /* Create a local client port for QMI communication */ pdr->locator_addr.sq_family = AF_QIPCRTR; pdr->locator_addr.sq_node = svc->node; pdr->locator_addr.sq_port = svc->port; - mutex_lock(&pdr->lock); pdr->locator_init_complete = true; mutex_unlock(&pdr->lock); @@ -104,10 +104,10 @@ static void pdr_locator_del_server(struct qmi_handle *qmi, mutex_lock(&pdr->lock); pdr->locator_init_complete = false; - mutex_unlock(&pdr->lock); pdr->locator_addr.sq_node = 0; pdr->locator_addr.sq_port = 0; + mutex_unlock(&pdr->lock); } static struct qmi_ops pdr_locator_ops = { @@ -366,12 +366,14 @@ static int pdr_get_domain_list(struct servreg_get_domain_list_req *req, if (ret < 0) return ret; + mutex_lock(&pdr->lock); ret = qmi_send_request(&pdr->locator_hdl, &pdr->locator_addr, &txn, SERVREG_GET_DOMAIN_LIST_REQ, SERVREG_GET_DOMAIN_LIST_REQ_MAX_LEN, servreg_get_domain_list_req_ei, req); + mutex_unlock(&pdr->lock); if (ret < 0) { qmi_txn_cancel(&txn); return ret; -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] soc: qcom: pdr: protect locator_addr with the main mutex
by Li Nan 23 Aug '24

23 Aug '24

From: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> stable inclusion from stable-v5.10.224 commit eab05737ee22216250fe20d27f5a596da5ea6eb7 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ5M CVE: CVE-2024-43849 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 107924c14e3ddd85119ca43c26a4ee1056fa9b84 ] If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock. Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") Tested-by: Neil Armstrong <neil.armstrong(a)linaro.org> # on SM8550-QRD Tested-by: Steev Klimaszewski <steev(a)kali.org> Tested-by: Alexey Minnekhanov <alexeymin(a)postmarketos.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Link: https://lore.kernel.org/r/20240622-qcom-pd-mapper-v9-1-a84ee3591c8e@linaro.… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Nan <linan122(a)huawei.com> --- drivers/soc/qcom/pdr_interface.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c index 205cc96823b7..373725b6d544 100644 --- a/drivers/soc/qcom/pdr_interface.c +++ b/drivers/soc/qcom/pdr_interface.c @@ -76,12 +76,12 @@ static int pdr_locator_new_server(struct qmi_handle *qmi, locator_hdl); struct pdr_service *pds; + mutex_lock(&pdr->lock); /* Create a local client port for QMI communication */ pdr->locator_addr.sq_family = AF_QIPCRTR; pdr->locator_addr.sq_node = svc->node; pdr->locator_addr.sq_port = svc->port; - mutex_lock(&pdr->lock); pdr->locator_init_complete = true; mutex_unlock(&pdr->lock); @@ -104,10 +104,10 @@ static void pdr_locator_del_server(struct qmi_handle *qmi, mutex_lock(&pdr->lock); pdr->locator_init_complete = false; - mutex_unlock(&pdr->lock); pdr->locator_addr.sq_node = 0; pdr->locator_addr.sq_port = 0; + mutex_unlock(&pdr->lock); } static struct qmi_ops pdr_locator_ops = { @@ -366,12 +366,14 @@ static int pdr_get_domain_list(struct servreg_get_domain_list_req *req, if (ret < 0) return ret; + mutex_lock(&pdr->lock); ret = qmi_send_request(&pdr->locator_hdl, &pdr->locator_addr, &txn, SERVREG_GET_DOMAIN_LIST_REQ, SERVREG_GET_DOMAIN_LIST_REQ_MAX_LEN, servreg_get_domain_list_req_ei, req); + mutex_unlock(&pdr->lock); if (ret < 0) { qmi_txn_cancel(&txn); return ret; -- 2.39.2

2 1

[PATCH OLK-6.6] perf: Fix event leak upon exec and file release
by Li Huafei 23 Aug '24

23 Aug '24

From: Frederic Weisbecker <frederic(a)kernel.org> stable inclusion from stable-v6.6.44 commit 104e258a004037bc7dba9f6085c71dad6af57ad4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALEPL CVE: CVE-2024-43869 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 3a5465418f5fd970e86a86c7f4075be262682840 upstream. The perf pending task work is never waited upon the matching event release. In the case of a child event, released via free_event() directly, this can potentially result in a leaked event, such as in the following scenario that doesn't even require a weak IRQ work implementation to trigger: schedule() prepare_task_switch() =======> <NMI> perf_event_overflow() event->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= </NMI> perf_event_task_sched_out() event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) finish_lock_switch() =======> <IRQ> perf_pending_irq() //do nothing, rely on pending task work <======= </IRQ> begin_new_exec() perf_event_exit_task() perf_event_exit_event() // If is child event free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // event is leaked Similar scenarios can also happen with perf_event_remove_on_exec() or simply against concurrent perf_event_release(). Fix this with synchonizing against the possibly remaining pending task work while freeing the event, just like is done with remaining pending IRQ work. This means that the pending task callback neither need nor should hold a reference to the event, preventing it from ever beeing freed. Fixes: 517e6a301f34 ("perf: Fix perf_pending_task() UaF") Signed-off-by: Frederic Weisbecker <frederic(a)kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240621091601.18227-5-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> --- include/linux/perf_event.h | 1 + kernel/events/core.c | 38 ++++++++++++++++++++++++++++++++++---- 2 files changed, 35 insertions(+), 4 deletions(-) diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index 1601aa405669..618a729c9f9c 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -797,6 +797,7 @@ struct perf_event { struct irq_work pending_irq; struct callback_head pending_task; unsigned int pending_work; + struct rcuwait pending_work_wait; atomic_t event_limit; diff --git a/kernel/events/core.c b/kernel/events/core.c index e373f901ac20..b7c4b49411be 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -2288,7 +2288,6 @@ event_sched_out(struct perf_event *event, struct perf_event_context *ctx) if (state != PERF_EVENT_STATE_OFF && !event->pending_work && !task_work_add(current, &event->pending_task, TWA_RESUME)) { - WARN_ON_ONCE(!atomic_long_inc_not_zero(&event->refcount)); event->pending_work = 1; } else { local_dec(&event->ctx->nr_pending); @@ -5172,9 +5171,35 @@ static bool exclusive_event_installable(struct perf_event *event, static void perf_addr_filters_splice(struct perf_event *event, struct list_head *head); +static void perf_pending_task_sync(struct perf_event *event) +{ + struct callback_head *head = &event->pending_task; + + if (!event->pending_work) + return; + /* + * If the task is queued to the current task's queue, we + * obviously can't wait for it to complete. Simply cancel it. + */ + if (task_work_cancel(current, head)) { + event->pending_work = 0; + local_dec(&event->ctx->nr_pending); + return; + } + + /* + * All accesses related to the event are within the same + * non-preemptible section in perf_pending_task(). The RCU + * grace period before the event is freed will make sure all + * those accesses are complete by then. + */ + rcuwait_wait_event(&event->pending_work_wait, !event->pending_work, TASK_UNINTERRUPTIBLE); +} + static void _free_event(struct perf_event *event) { irq_work_sync(&event->pending_irq); + perf_pending_task_sync(event); unaccount_event(event); @@ -6807,24 +6832,28 @@ static void perf_pending_task(struct callback_head *head) struct perf_event *event = container_of(head, struct perf_event, pending_task); int rctx; + /* + * All accesses to the event must belong to the same implicit RCU read-side + * critical section as the ->pending_work reset. See comment in + * perf_pending_task_sync(). + */ + preempt_disable_notrace(); /* * If we 'fail' here, that's OK, it means recursion is already disabled * and we won't recurse 'further'. */ - preempt_disable_notrace(); rctx = perf_swevent_get_recursion_context(); if (event->pending_work) { event->pending_work = 0; perf_sigtrap(event); local_dec(&event->ctx->nr_pending); + rcuwait_wake_up(&event->pending_work_wait); } if (rctx >= 0) perf_swevent_put_recursion_context(rctx); preempt_enable_notrace(); - - put_event(event); } #ifdef CONFIG_GUEST_PERF_EVENTS @@ -11934,6 +11963,7 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu, init_waitqueue_head(&event->waitq); init_irq_work(&event->pending_irq, perf_pending_irq); init_task_work(&event->pending_task, perf_pending_task); + rcuwait_init(&event->pending_work_wait); mutex_init(&event->mmap_mutex); raw_spin_lock_init(&event->addr_filters.lock); -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] wifi: mac80211: sdata can be NULL during AMPDU start
by Yue Haibing 23 Aug '24

23 Aug '24

From: Alexander Wetzel <alexander(a)wetzel-home.de> stable inclusion from stable-v5.10.165 commit 187523fa7c2d4c780f775cb869216865c4a909ef category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6IXN2 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 69403bad97aa0162e3d7911b27e25abe774093df upstream. ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a deauthentication is ongoing. Here a trace triggering the race with the hostapd test multi_ap_fronthaul_on_ap: (gdb) list *drv_ampdu_action+0x46 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396). 391 int ret = -EOPNOTSUPP; 392 393 might_sleep(); 394 395 sdata = get_bss_sdata(sdata); 396 if (!check_sdata_in_driver(sdata)) 397 return -EIO; 398 399 trace_drv_ampdu_action(local, sdata, params); 400 wlan0: moving STA 02:00:00:00:03:00 to state 3 wlan0: associated wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING) wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0 wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port) wlan0: moving STA 02:00:00:00:03:00 to state 2 wlan0: moving STA 02:00:00:00:03:00 to state 1 wlan0: Removed STA 02:00:00:00:03:00 wlan0: Destroyed STA 02:00:00:00:03:00 BUG: unable to handle page fault for address: fffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Workqueue: phy3 ieee80211_ba_session_work [mac80211] RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211] Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Call Trace: <TASK> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> Signed-off-by: Alexander Wetzel <alexander(a)wetzel-home.de> Link: https://lore.kernel.org/r/20221230121850.218810-2-alexander@wetzel-home.de Cc: stable(a)vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> --- net/mac80211/agg-tx.c | 6 +++++- net/mac80211/driver-ops.c | 3 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c index 4b4ab1961068..92e5812daf89 100644 --- a/net/mac80211/agg-tx.c +++ b/net/mac80211/agg-tx.c @@ -491,7 +491,7 @@ void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid) { struct tid_ampdu_tx *tid_tx; struct ieee80211_local *local = sta->local; - struct ieee80211_sub_if_data *sdata = sta->sdata; + struct ieee80211_sub_if_data *sdata; struct ieee80211_ampdu_params params = { .sta = &sta->sta, .action = IEEE80211_AMPDU_TX_START, @@ -521,6 +521,7 @@ void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid) */ synchronize_net(); + sdata = sta->sdata; params.ssn = sta->tid_seq[tid] >> 4; ret = drv_ampdu_action(local, sdata, &params); tid_tx->ssn = params.ssn; @@ -534,6 +535,9 @@ void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid) */ set_bit(HT_AGG_STATE_DRV_READY, &tid_tx->state); } else if (ret) { + if (!sdata) + return; + ht_dbg(sdata, "BA request denied - HW unavailable for %pM tid %d\n", sta->sta.addr, tid); diff --git a/net/mac80211/driver-ops.c b/net/mac80211/driver-ops.c index 48322e45e7dd..120bd9cdf7df 100644 --- a/net/mac80211/driver-ops.c +++ b/net/mac80211/driver-ops.c @@ -331,6 +331,9 @@ int drv_ampdu_action(struct ieee80211_local *local, might_sleep(); + if (!sdata) + return -EIO; + sdata = get_bss_sdata(sdata); if (!check_sdata_in_driver(sdata)) return -EIO; -- 2.34.1

2 1

[PATCH OLK-6.6] exec: Fix ToCToU between perm check and set-uid/gid usage
by Zizhi Wo 23 Aug '24

23 Aug '24

From: Kees Cook <kees(a)kernel.org> stable inclusion from stable-v6.6.47 commit d2a2a4714d80d09b0f8eb6438ab4224690b7121e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALED4 CVE: CVE-2024-43882 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit f50733b45d865f91db90919f8311e2127ce5a0cb upstream. When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal. Reported-by: Marco Vanotti <mvanotti(a)google.com> Tested-by: Marco Vanotti <mvanotti(a)google.com> Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/exec.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index 04fb89656cc3..a4725461a443 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1589,6 +1589,7 @@ static void bprm_fill_uid(struct linux_binprm *bprm, struct file *file) unsigned int mode; vfsuid_t vfsuid; vfsgid_t vfsgid; + int err; if (!mnt_may_suid(file->f_path.mnt)) return; @@ -1605,12 +1606,17 @@ static void bprm_fill_uid(struct linux_binprm *bprm, struct file *file) /* Be careful if suid/sgid is set */ inode_lock(inode); - /* reload atomically mode/uid/gid now that lock held */ + /* Atomically reload and check mode/uid/gid now that lock held. */ mode = inode->i_mode; vfsuid = i_uid_into_vfsuid(idmap, inode); vfsgid = i_gid_into_vfsgid(idmap, inode); + err = inode_permission(idmap, inode, MAY_EXEC); inode_unlock(inode); + /* Did the exec bit vanish out from under us? Give up. */ + if (err) + return; + /* We ignore suid/sgid if there are no mappings for them in the ns */ if (!vfsuid_has_mapping(bprm->cred->user_ns, vfsuid) || !vfsgid_has_mapping(bprm->cred->user_ns, vfsgid)) -- 2.39.2

2 1

[PATCH OLK-5.10] exec: Fix ToCToU between perm check and set-uid/gid usage
by Zizhi Wo 23 Aug '24

23 Aug '24

From: Kees Cook <kees(a)kernel.org> stable inclusion from stable-v5.10.224 commit 15469d46ba34559bfe7e3de6659115778c624759 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALED4 CVE: CVE-2024-43882 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit f50733b45d865f91db90919f8311e2127ce5a0cb upstream. When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal. Reported-by: Marco Vanotti <mvanotti(a)google.com> Tested-by: Marco Vanotti <mvanotti(a)google.com> Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/exec.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index c8c5818ece9e..802566d81db7 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1584,6 +1584,7 @@ static void bprm_fill_uid(struct linux_binprm *bprm, struct file *file) unsigned int mode; kuid_t uid; kgid_t gid; + int err; if (!mnt_may_suid(file->f_path.mnt)) return; @@ -1599,12 +1600,17 @@ static void bprm_fill_uid(struct linux_binprm *bprm, struct file *file) /* Be careful if suid/sgid is set */ inode_lock(inode); - /* reload atomically mode/uid/gid now that lock held */ + /* Atomically reload and check mode/uid/gid now that lock held. */ mode = inode->i_mode; uid = inode->i_uid; gid = inode->i_gid; + err = inode_permission(inode, MAY_EXEC); inode_unlock(inode); + /* Did the exec bit vanish out from under us? Give up. */ + if (err) + return; + /* We ignore suid/sgid if there are no mappings for them in the ns */ if (!kuid_has_mapping(bprm->cred->user_ns, uid) || !kgid_has_mapping(bprm->cred->user_ns, gid)) -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] exec: Fix ToCToU between perm check and set-uid/gid usage
by Zizhi Wo 23 Aug '24

23 Aug '24

From: Kees Cook <kees(a)kernel.org> stable inclusion from stable-v5.10.224 commit 15469d46ba34559bfe7e3de6659115778c624759 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALED4 CVE: CVE-2024-43882 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit f50733b45d865f91db90919f8311e2127ce5a0cb upstream. When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal. Reported-by: Marco Vanotti <mvanotti(a)google.com> Tested-by: Marco Vanotti <mvanotti(a)google.com> Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/exec.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index add4a298a49a..81f8df151d6a 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1567,6 +1567,7 @@ static void bprm_fill_uid(struct linux_binprm *bprm, struct file *file) unsigned int mode; kuid_t uid; kgid_t gid; + int err; if (!mnt_may_suid(file->f_path.mnt)) return; @@ -1582,12 +1583,17 @@ static void bprm_fill_uid(struct linux_binprm *bprm, struct file *file) /* Be careful if suid/sgid is set */ inode_lock(inode); - /* reload atomically mode/uid/gid now that lock held */ + /* Atomically reload and check mode/uid/gid now that lock held. */ mode = inode->i_mode; uid = inode->i_uid; gid = inode->i_gid; + err = inode_permission(inode, MAY_EXEC); inode_unlock(inode); + /* Did the exec bit vanish out from under us? Give up. */ + if (err) + return; + /* We ignore suid/sgid if there are no mappings for them in the ns */ if (!kuid_has_mapping(bprm->cred->user_ns, uid) || !kgid_has_mapping(bprm->cred->user_ns, gid)) -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] io_uring: lock overflowing for IOPOLL
by Zizhi Wo 23 Aug '24

23 Aug '24

From: Pavel Begunkov <asml.silence(a)gmail.com> stable inclusion from stable-v5.10.165 commit de77faee280163ff03b7ab64af6c9d779a43d4c4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALIEY CVE: CVE-2023-52903 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit 544d163d659d45a206d8929370d5a2984e546cb7 upstream. syzbot reports an issue with overflow filling for IOPOLL: WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: events_unbound io_ring_exit_work Call trace: io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773 io_fill_cqe_req io_uring/io_uring.h:168 [inline] io_do_iopoll+0x474/0x62c io_uring/rw.c:1065 io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513 io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056 io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869 process_one_work+0x2d8/0x504 kernel/workqueue.c:2289 worker_thread+0x340/0x610 kernel/workqueue.c:2436 kthread+0x12c/0x158 kernel/kthread.c:376 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863 There is no real problem for normal IOPOLL as flush is also called with uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which __io_cqring_overflow_flush() happens from the CQ waiting path. Reported-and-tested-by: syzbot+6805087452d72929404e(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org # 5.10+ Signed-off-by: Pavel Begunkov <asml.silence(a)gmail.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- io_uring/io_uring.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index f33926715f57..b3ba5adc3ca7 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -2472,12 +2472,26 @@ static void io_iopoll_complete(struct io_ring_ctx *ctx, unsigned int *nr_events, io_init_req_batch(&rb); while (!list_empty(done)) { + struct io_uring_cqe *cqe; + unsigned cflags; + req = list_first_entry(done, struct io_kiocb, inflight_entry); list_del(&req->inflight_entry); - - io_fill_cqe_req(req, req->result, io_put_rw_kbuf(req)); + cflags = io_put_rw_kbuf(req); (*nr_events)++; + cqe = io_get_cqe(ctx); + if (cqe) { + WRITE_ONCE(cqe->user_data, req->user_data); + WRITE_ONCE(cqe->res, req->result); + WRITE_ONCE(cqe->flags, cflags); + } else { + spin_lock(&ctx->completion_lock); + io_cqring_event_overflow(ctx, req->user_data, + req->result, cflags); + spin_unlock(&ctx->completion_lock); + } + if (req_ref_put_and_test(req)) io_req_free_batch(&rb, req, &ctx->submit_state); } -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1 0/1] usb: xhci: Check endpoint is valid before dereferencing it
by Liao Chen 23 Aug '24

23 Aug '24

usb: xhci: Check endpoint is valid before dereferencing it Jimmy Hu (1): usb: xhci: Check endpoint is valid before dereferencing it drivers/usb/host/xhci-ring.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] exec: Fix ToCToU between perm check and set-uid/gid usage
by Zizhi Wo 23 Aug '24

23 Aug '24

From: Kees Cook <kees(a)kernel.org> stable inclusion from stable-v4.19.320 commit d5c3c7e26275a2d83b894d30f7582a42853a958f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALED4 CVE: CVE-2024-43882 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit f50733b45d865f91db90919f8311e2127ce5a0cb upstream. When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal. Reported-by: Marco Vanotti <mvanotti(a)google.com> Tested-by: Marco Vanotti <mvanotti(a)google.com> Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/exec.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index da6cca9bd1ba..1d66dd0c759e 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1529,6 +1529,7 @@ static void bprm_fill_uid(struct linux_binprm *bprm) unsigned int mode; kuid_t uid; kgid_t gid; + int err; /* * Since this can be called multiple times (via prepare_binprm), @@ -1553,12 +1554,17 @@ static void bprm_fill_uid(struct linux_binprm *bprm) /* Be careful if suid/sgid is set */ inode_lock(inode); - /* reload atomically mode/uid/gid now that lock held */ + /* Atomically reload and check mode/uid/gid now that lock held. */ mode = inode->i_mode; uid = inode->i_uid; gid = inode->i_gid; + err = inode_permission(inode, MAY_EXEC); inode_unlock(inode); + /* Did the exec bit vanish out from under us? Give up. */ + if (err) + return; + /* We ignore suid/sgid if there are no mappings for them in the ns */ if (!kuid_has_mapping(bprm->cred->user_ns, uid) || !kgid_has_mapping(bprm->cred->user_ns, gid)) -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS-SP1 0/1] usb: xhci: Check endpoint is valid before dereferencing it
by Liao Chen 23 Aug '24

23 Aug '24

usb: xhci: Check endpoint is valid before dereferencing it Jimmy Hu (1): usb: xhci: Check endpoint is valid before dereferencing it drivers/usb/host/xhci-ring.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.34.1

1 1

[PATCH openEuler-1.0-LTS-SP1 0/1] usb: xhci: Check endpoint is valid before dereferencing it
by Liao Chen 23 Aug '24

23 Aug '24

usb: xhci: Check endpoint is valid before dereferencing it Jimmy Hu (1): usb: xhci: Check endpoint is valid before dereferencing it drivers/usb/host/xhci-ring.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS-SP1 0/1] usb: xhci: Check endpoint is valid before dereferencing it
by Liao Chen 23 Aug '24

23 Aug '24

usb: xhci: Check endpoint is valid before dereferencing it Jimmy Hu (1): usb: xhci: Check endpoint is valid before dereferencing it drivers/usb/host/xhci-ring.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.34.1

1 0

[openeuler:OLK-6.6 7228/13476] ld.lld: error: undefined symbol: msi_domain_first_desc
by kernel test robot 23 Aug '24

23 Aug '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: eccf28eefc9db7799534bd84bb958f3ecf978e2d commit: 165b3cc224374728856b5584455d7ae7f054fbe5 [7228/13476] SCSI: SSSRAID: Support 3SNIC 3S5XX serial RAID/HBA controllers config: x86_64-randconfig-001-20240823 (https://download.01.org/0day-ci/archive/20240823/202408231150.d9tyFM1M-lkp@…) compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240823/202408231150.d9tyFM1M-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/202408231150.d9tyFM1M-lkp@intel.com/ All errors (new ones prefixed by >>): >> ld.lld: error: undefined symbol: msi_domain_first_desc >>> referenced by sssraid_os.c:1553 (drivers/scsi/sssraid/sssraid_os.c:1553) >>> vmlinux.o:(sssraid_map_queues) -- >> ld.lld: error: undefined symbol: msi_next_desc >>> referenced by sssraid_os.c:1553 (drivers/scsi/sssraid/sssraid_os.c:1553) >>> vmlinux.o:(sssraid_map_queues) -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 v4 00/19] Backport bugfix of folio from v6.11
by Liu Shixin 23 Aug '24

23 Aug '24

v3->v4: Fix the fixtag of ("ext4: Fix WARNON in generic write begin path for iomap mode") v2->v3: Add new bugfix ("ext4: Fix WARNON in generic write begin path for iomap mode") v1->v2: Move patch ("shmem: set a_ops earlier in shmem_symlink") into patch series "mm/shmem: mTHP support for anon shmem" Baolin Wang (1): mm: page_alloc: allowing mTHP compaction to capture the freed page directly Gao Xiang (1): mm/migrate: fix deadlock in migrate_pages_batch() on large folios Gavin Shan (2): mm/huge_memory: avoid PMD-size page cache if needed mm/readahead: limit page cache size in page_cache_ra_order() Hugh Dickins (2): mm: fix crashes from deferred split racing folio migration mm: simplify folio_migrate_mapping() Kefeng Wang (1): mm: refactor folio_undo_large_rmappable() Liu Shixin (1): mm/huge_memory: fix comment errors of thp_mapping_align Matthew Wilcox (Oracle) (1): filemap: Convert generic_perform_write() to support large folios Pankaj Raghav (1): readahead: use ilog2 instead of a while loop in page_cache_ra_order() Peter Xu (1): mm/migrate: putback split folios when numa hint migration fails Ran Xiaokai (1): mm/huge_memory: mark racy access onhuge_anon_orders_always Ryan Roberts (1): mm: fix khugepaged activation policy Yajun Deng (1): mm/mmap: simplify vma link and unlink Zhihao Cheng (1): ext4: Fix WARNON in generic write begin path for iomap mode Zi Yan (1): mm/migrate: make migrate_pages_batch() stats consistent linke li (3): mm/swapfile: mark racy access on si->highest_bit mm/slub: mark racy access on slab->freelist mm/slub: mark racy accesses on slab->slabs Documentation/admin-guide/mm/transhuge.rst | 15 ++++---- fs/ext4/inode.c | 9 +++-- include/linux/huge_mm.h | 24 +++++------- mm/filemap.c | 40 ++++++++++++-------- mm/huge_memory.c | 32 +++++++++------- mm/internal.h | 17 ++++++++- mm/khugepaged.c | 33 ++++++++++++---- mm/memcontrol.c | 11 ------ mm/migrate.c | 42 +++++++++++++++------ mm/mmap.c | 44 ++++++++++------------ mm/page_alloc.c | 9 +++-- mm/readahead.c | 10 ++--- mm/slub.c | 8 ++-- mm/swap.c | 8 +--- mm/swapfile.c | 2 +- mm/vmscan.c | 8 +--- 16 files changed, 173 insertions(+), 139 deletions(-) -- 2.25.1

2 20

[PATCH openEuler-22.03-LTS-SP1] mISDN: Fix a use after free in hfcmulti_tx()
by Zhang Changzhong 23 Aug '24

23 Aug '24

From: Dan Carpenter <dan.carpenter(a)linaro.org> stable inclusion from stable-v5.10.224 commit 9460ac3dd1ae033bc2b021a458fb535a0c36ddb2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKPV2 CVE: CVE-2024-42280 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 61ab751451f5ebd0b98e02276a44e23a10110402 ] Don't dereference *sp after calling dev_kfree_skb(*sp). Fixes: af69fb3a8ffa ("Add mISDN HFC multiport driver") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/8be65f5a-c2dd-4ba0-8a10-bfe5980b8cfb@stanley.mount… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/isdn/hardware/mISDN/hfcmulti.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/isdn/hardware/mISDN/hfcmulti.c b/drivers/isdn/hardware/mISDN/hfcmulti.c index 7013a3f..545d381 100644 --- a/drivers/isdn/hardware/mISDN/hfcmulti.c +++ b/drivers/isdn/hardware/mISDN/hfcmulti.c @@ -1931,7 +1931,7 @@ hfcmulti_dtmf(struct hfc_multi *hc) static void hfcmulti_tx(struct hfc_multi *hc, int ch) { - int i, ii, temp, len = 0; + int i, ii, temp, tmp_len, len = 0; int Zspace, z1, z2; /* must be int for calculation */ int Fspace, f1, f2; u_char *d; @@ -2152,14 +2152,15 @@ hfcmulti_tx(struct hfc_multi *hc, int ch) HFC_wait_nodebug(hc); } + tmp_len = (*sp)->len; dev_kfree_skb(*sp); /* check for next frame */ if (bch && get_next_bframe(bch)) { - len = (*sp)->len; + len = tmp_len; goto next_frame; } if (dch && get_next_dframe(dch)) { - len = (*sp)->len; + len = tmp_len; goto next_frame; } -- 2.9.5

2 1

[PATCH OLK-5.10] mISDN: Fix a use after free in hfcmulti_tx()
by Zhang Changzhong 23 Aug '24

23 Aug '24

From: Dan Carpenter <dan.carpenter(a)linaro.org> stable inclusion from stable-v5.10.224 commit 9460ac3dd1ae033bc2b021a458fb535a0c36ddb2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKPV2 CVE: CVE-2024-42280 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 61ab751451f5ebd0b98e02276a44e23a10110402 ] Don't dereference *sp after calling dev_kfree_skb(*sp). Fixes: af69fb3a8ffa ("Add mISDN HFC multiport driver") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/8be65f5a-c2dd-4ba0-8a10-bfe5980b8cfb@stanley.mount… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhang Changzhong <zhangchangzhong(a)huawei.com> --- drivers/isdn/hardware/mISDN/hfcmulti.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/isdn/hardware/mISDN/hfcmulti.c b/drivers/isdn/hardware/mISDN/hfcmulti.c index 4c5b677..a0697d6 100644 --- a/drivers/isdn/hardware/mISDN/hfcmulti.c +++ b/drivers/isdn/hardware/mISDN/hfcmulti.c @@ -1931,7 +1931,7 @@ hfcmulti_dtmf(struct hfc_multi *hc) static void hfcmulti_tx(struct hfc_multi *hc, int ch) { - int i, ii, temp, len = 0; + int i, ii, temp, tmp_len, len = 0; int Zspace, z1, z2; /* must be int for calculation */ int Fspace, f1, f2; u_char *d; @@ -2152,14 +2152,15 @@ hfcmulti_tx(struct hfc_multi *hc, int ch) HFC_wait_nodebug(hc); } + tmp_len = (*sp)->len; dev_kfree_skb(*sp); /* check for next frame */ if (bch && get_next_bframe(bch)) { - len = (*sp)->len; + len = tmp_len; goto next_frame; } if (dch && get_next_dframe(dch)) { - len = (*sp)->len; + len = tmp_len; goto next_frame; } -- 2.9.5

2 1

[PATCH OLK-5.10] net/mlx5: Always drain health in shutdown callback
by Zhengchao Shao 23 Aug '24

23 Aug '24

From: Shay Drory <shayd(a)nvidia.com> mainline inclusion from mainline-v6.11-rc2 commit 1b75da22ed1e6171e261bc9265370162553d5393 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALCRV CVE: CVE-2024-43866 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback. Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver") Fixes: d2aa060d40fa ("net/mlx5: Cancel health poll before sending panic teardown command") Signed-off-by: Shay Drory <shayd(a)nvidia.com> Reviewed-by: Moshe Shemesh <moshe(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Reviewed-by: Wojciech Drewek <wojciech.drewek(a)intel.com> Link: https://patch.msgid.link/20240730061638.1831002-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlx5/core/main.c drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c [The conflict occurs because the commit 8324a02c342a("net/mlx5: Add exit route when waiting for FW") and 1958fc2f0712("net/mlx5: SF, Add auxiliary device driver") are not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c index 35e11cb883c9..d4712fbc7856 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c @@ -1524,7 +1524,6 @@ static int mlx5_try_fast_unload(struct mlx5_core_dev *dev) /* Panic tear down fw command will stop the PCI bus communication * with the HCA, so the health polll is no longer needed. */ - mlx5_drain_health_wq(dev); mlx5_stop_health_poll(dev, false); ret = mlx5_cmd_fast_teardown_hca(dev); @@ -1558,6 +1557,7 @@ static void shutdown(struct pci_dev *pdev) int err; mlx5_core_info(dev, "Shutdown was called\n"); + mlx5_drain_health_wq(dev); err = mlx5_try_fast_unload(dev); if (err) mlx5_unload_one(dev, false); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] net/mlx5: Always drain health in shutdown callback
by Zhengchao Shao 23 Aug '24

23 Aug '24

From: Shay Drory <shayd(a)nvidia.com> mainline inclusion from mainline-v6.11-rc2 commit 1b75da22ed1e6171e261bc9265370162553d5393 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALCRV CVE: CVE-2024-43866 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback. Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver") Fixes: d2aa060d40fa ("net/mlx5: Cancel health poll before sending panic teardown command") Signed-off-by: Shay Drory <shayd(a)nvidia.com> Reviewed-by: Moshe Shemesh <moshe(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Reviewed-by: Wojciech Drewek <wojciech.drewek(a)intel.com> Link: https://patch.msgid.link/20240730061638.1831002-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlx5/core/main.c drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c [The conflict occurs because the commit 8324a02c342a("net/mlx5: Add exit route when waiting for FW") and 1958fc2f0712("net/mlx5: SF, Add auxiliary device driver") are not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c index 8246b6285d5a..e0a605c1130f 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c @@ -1523,7 +1523,6 @@ static int mlx5_try_fast_unload(struct mlx5_core_dev *dev) /* Panic tear down fw command will stop the PCI bus communication * with the HCA, so the health polll is no longer needed. */ - mlx5_drain_health_wq(dev); mlx5_stop_health_poll(dev, false); ret = mlx5_cmd_fast_teardown_hca(dev); @@ -1557,6 +1556,7 @@ static void shutdown(struct pci_dev *pdev) int err; mlx5_core_info(dev, "Shutdown was called\n"); + mlx5_drain_health_wq(dev); err = mlx5_try_fast_unload(dev); if (err) mlx5_unload_one(dev, false); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] f2fs: fix to don't dirty inode for readonly filesystem
by Zizhi Wo 23 Aug '24

23 Aug '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.1.103 commit 9ce8135accf103f7333af472709125878704fdd4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ0F CVE: CVE-2024-42297 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit 192b8fb8d1c8ca3c87366ebbef599fa80bb626b8 upstream. syzbot reports f2fs bug as below: kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode(). Cc: stable(a)vger.kernel.org Reported-by: syzbot+31e4659a3fe953aec2f4(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/000000000000e890bc0609a55cff@googl… Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/f2fs/inode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index a01be7d8db86..a716150ae14e 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -25,6 +25,9 @@ void f2fs_mark_inode_dirty_sync(struct inode *inode, bool sync) if (is_inode_flag_set(inode, FI_NEW_INODE)) return; + if (f2fs_readonly(F2FS_I_SB(inode)->sb)) + return; + if (f2fs_inode_dirtied(inode, sync)) return; -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] net/mlx5: Always drain health in shutdown callback
by Zhengchao Shao 23 Aug '24

23 Aug '24

From: Shay Drory <shayd(a)nvidia.com> mainline inclusion from mainline-v6.11-rc2 commit 1b75da22ed1e6171e261bc9265370162553d5393 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALCRV CVE: CVE-2024-43866 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback. Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver") Fixes: d2aa060d40fa ("net/mlx5: Cancel health poll before sending panic teardown command") Signed-off-by: Shay Drory <shayd(a)nvidia.com> Reviewed-by: Moshe Shemesh <moshe(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Reviewed-by: Wojciech Drewek <wojciech.drewek(a)intel.com> Link: https://patch.msgid.link/20240730061638.1831002-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlx5/core/main.c [The conflict occurs because the commit 8324a02c342a("net/mlx5: Add exit route when waiting for FW") and 1958fc2f0712("net/mlx5: SF, Add auxiliary device driver") are not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c index 8246b6285d5a..e0a605c1130f 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c @@ -1523,7 +1523,6 @@ static int mlx5_try_fast_unload(struct mlx5_core_dev *dev) /* Panic tear down fw command will stop the PCI bus communication * with the HCA, so the health polll is no longer needed. */ - mlx5_drain_health_wq(dev); mlx5_stop_health_poll(dev, false); ret = mlx5_cmd_fast_teardown_hca(dev); @@ -1557,6 +1556,7 @@ static void shutdown(struct pci_dev *pdev) int err; mlx5_core_info(dev, "Shutdown was called\n"); + mlx5_drain_health_wq(dev); err = mlx5_try_fast_unload(dev); if (err) mlx5_unload_one(dev, false); -- 2.34.1

2 1

[PATCH OLK-5.10] net/mlx5: Always drain health in shutdown callback
by Zhengchao Shao 23 Aug '24

23 Aug '24

From: Shay Drory <shayd(a)nvidia.com> mainline inclusion from mainline-v6.11-rc2 commit 1b75da22ed1e6171e261bc9265370162553d5393 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALCRV CVE: CVE-2024-43866 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback. Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver") Fixes: d2aa060d40fa ("net/mlx5: Cancel health poll before sending panic teardown command") Signed-off-by: Shay Drory <shayd(a)nvidia.com> Reviewed-by: Moshe Shemesh <moshe(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Reviewed-by: Wojciech Drewek <wojciech.drewek(a)intel.com> Link: https://patch.msgid.link/20240730061638.1831002-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlx5/core/main.c [The conflict occurs because the commit 8324a02c342a("net/mlx5: Add exit route when waiting for FW") and 1958fc2f0712("net/mlx5: SF, Add auxiliary device driver") are not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c index 35e11cb883c9..d4712fbc7856 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c @@ -1524,7 +1524,6 @@ static int mlx5_try_fast_unload(struct mlx5_core_dev *dev) /* Panic tear down fw command will stop the PCI bus communication * with the HCA, so the health polll is no longer needed. */ - mlx5_drain_health_wq(dev); mlx5_stop_health_poll(dev, false); ret = mlx5_cmd_fast_teardown_hca(dev); @@ -1558,6 +1557,7 @@ static void shutdown(struct pci_dev *pdev) int err; mlx5_core_info(dev, "Shutdown was called\n"); + mlx5_drain_health_wq(dev); err = mlx5_try_fast_unload(dev); if (err) mlx5_unload_one(dev, false); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] thermal: int340x: fix memory leak in int3400_notify()
by Liu Chuang 23 Aug '24

23 Aug '24

From: Chuansheng Liu <chuansheng.liu(a)intel.com> stable inclusion from stable-v4.19.237 commit c3fa6d1937a8d0828131a04ae2cd2c30d0668693 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALOJQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit 3abea10e6a8f0e7804ed4c124bea2d15aca977c8 upstream. It is easy to hit the below memory leaks in my TigerLake platform: unreferenced object 0xffff927c8b91dbc0 (size 32): comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. backtrace: [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0 [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0 [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70 [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal] [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71 [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30 [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0 [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0 [<ffffffff9c2cb4dd>] kthread+0xfd/0x130 [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30 Fix it by calling kfree() accordingly. Fixes: 38e44da59130 ("thermal: int3400_thermal: process "thermal table changed" event") Signed-off-by: Chuansheng Liu <chuansheng.liu(a)intel.com> Cc: 4.14+ <stable(a)vger.kernel.org> # 4.14+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> [sudip: change in old path] Signed-off-by: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- drivers/thermal/int340x_thermal/int3400_thermal.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c b/drivers/thermal/int340x_thermal/int3400_thermal.c index e9d58de8b5da..77967da5d406 100644 --- a/drivers/thermal/int340x_thermal/int3400_thermal.c +++ b/drivers/thermal/int340x_thermal/int3400_thermal.c @@ -223,6 +223,10 @@ static void int3400_notify(acpi_handle handle, thermal_prop[4] = NULL; kobject_uevent_env(&priv->thermal->device.kobj, KOBJ_CHANGE, thermal_prop); + kfree(thermal_prop[0]); + kfree(thermal_prop[1]); + kfree(thermal_prop[2]); + kfree(thermal_prop[3]); break; default: /* Ignore unknown notification codes sent to INT3400 device */ -- 2.34.1

2 1

[PATCH OLK-5.10] f2fs: fix to don't dirty inode for readonly filesystem
by Zizhi Wo 23 Aug '24

23 Aug '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.1.103 commit 9ce8135accf103f7333af472709125878704fdd4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ0F CVE: CVE-2024-42297 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit 192b8fb8d1c8ca3c87366ebbef599fa80bb626b8 upstream. syzbot reports f2fs bug as below: kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode(). Cc: stable(a)vger.kernel.org Reported-by: syzbot+31e4659a3fe953aec2f4(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/000000000000e890bc0609a55cff@googl… Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/f2fs/inode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index aeafd8b73cbf..8f29eb07c296 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -23,6 +23,9 @@ void f2fs_mark_inode_dirty_sync(struct inode *inode, bool sync) if (is_inode_flag_set(inode, FI_NEW_INODE)) return; + if (f2fs_readonly(F2FS_I_SB(inode)->sb)) + return; + if (f2fs_inode_dirtied(inode, sync)) return; -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] f2fs: fix to don't dirty inode for readonly filesystem
by Zizhi Wo 23 Aug '24

23 Aug '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.1.103 commit 9ce8135accf103f7333af472709125878704fdd4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ0F CVE: CVE-2024-42297 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit 192b8fb8d1c8ca3c87366ebbef599fa80bb626b8 upstream. syzbot reports f2fs bug as below: kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode(). Cc: stable(a)vger.kernel.org Reported-by: syzbot+31e4659a3fe953aec2f4(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/000000000000e890bc0609a55cff@googl… Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/f2fs/inode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index aeafd8b73cbf..8f29eb07c296 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -23,6 +23,9 @@ void f2fs_mark_inode_dirty_sync(struct inode *inode, bool sync) if (is_inode_flag_set(inode, FI_NEW_INODE)) return; + if (f2fs_readonly(F2FS_I_SB(inode)->sb)) + return; + if (f2fs_inode_dirtied(inode, sync)) return; -- 2.39.2

2 1

[PATCH OLK-6.6 v3 00/19] Backport bugfix of folio from v6.11
by Liu Shixin 23 Aug '24

23 Aug '24

v2->v3: Add new bugfix ("ext4: Fix WARNON in generic write begin path for iomap mode") v1->v2: Move patch ("shmem: set a_ops earlier in shmem_symlink") into patch series "mm/shmem: mTHP support for anon shmem" Baolin Wang (1): mm: page_alloc: allowing mTHP compaction to capture the freed page directly Gao Xiang (1): mm/migrate: fix deadlock in migrate_pages_batch() on large folios Gavin Shan (2): mm/huge_memory: avoid PMD-size page cache if needed mm/readahead: limit page cache size in page_cache_ra_order() Hugh Dickins (2): mm: fix crashes from deferred split racing folio migration mm: simplify folio_migrate_mapping() Kefeng Wang (1): mm: refactor folio_undo_large_rmappable() Liu Shixin (1): mm/huge_memory: fix comment errors of thp_mapping_align Matthew Wilcox (Oracle) (1): filemap: Convert generic_perform_write() to support large folios Pankaj Raghav (1): readahead: use ilog2 instead of a while loop in page_cache_ra_order() Peter Xu (1): mm/migrate: putback split folios when numa hint migration fails Ran Xiaokai (1): mm/huge_memory: mark racy access onhuge_anon_orders_always Ryan Roberts (1): mm: fix khugepaged activation policy Yajun Deng (1): mm/mmap: simplify vma link and unlink Zhihao Cheng (1): ext4: Fix WARNON in generic write begin path for iomap mode Zi Yan (1): mm/migrate: make migrate_pages_batch() stats consistent linke li (3): mm/swapfile: mark racy access on si->highest_bit mm/slub: mark racy access on slab->freelist mm/slub: mark racy accesses on slab->slabs Documentation/admin-guide/mm/transhuge.rst | 15 ++++---- fs/ext4/inode.c | 9 +++-- include/linux/huge_mm.h | 24 +++++------- mm/filemap.c | 40 ++++++++++++-------- mm/huge_memory.c | 32 +++++++++------- mm/internal.h | 17 ++++++++- mm/khugepaged.c | 33 ++++++++++++---- mm/memcontrol.c | 11 ------ mm/migrate.c | 42 +++++++++++++++------ mm/mmap.c | 44 ++++++++++------------ mm/page_alloc.c | 9 +++-- mm/readahead.c | 10 ++--- mm/slub.c | 8 ++-- mm/swap.c | 8 +--- mm/swapfile.c | 2 +- mm/vmscan.c | 8 +--- 16 files changed, 173 insertions(+), 139 deletions(-) -- 2.25.1

2 20

[PATCH openEuler-22.03-LTS-SP1] f2fs: fix to don't dirty inode for readonly filesystem
by Zizhi Wo 23 Aug '24

23 Aug '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.1.103 commit 9ce8135accf103f7333af472709125878704fdd4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAKQ0F CVE: CVE-2024-42297 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit 192b8fb8d1c8ca3c87366ebbef599fa80bb626b8 upstream. syzbot reports f2fs bug as below: kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode(). Cc: stable(a)vger.kernel.org Reported-by: syzbot+31e4659a3fe953aec2f4(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/000000000000e890bc0609a55cff@googl… Signed-off-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/f2fs/inode.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c index aeafd8b73cbf..8f29eb07c296 100644 --- a/fs/f2fs/inode.c +++ b/fs/f2fs/inode.c @@ -23,6 +23,9 @@ void f2fs_mark_inode_dirty_sync(struct inode *inode, bool sync) if (is_inode_flag_set(inode, FI_NEW_INODE)) return; + if (f2fs_readonly(F2FS_I_SB(inode)->sb)) + return; + if (f2fs_inode_dirtied(inode, sync)) return; -- 2.39.2

2 1

[PATCH OLK-6.6 0/8] Backport LTS conflicting patches
by Peng Zhang 23 Aug '24

23 Aug '24

From: ZhangPeng <zhangpeng362(a)huawei.com> Backport v6.6.34-40 LTS conflicting patches for OLK-6.6. Ajrat Makhmutov (1): ALSA: hda/realtek: Enable headset mic on IdeaPad 330-17IKB 81DM Alex Williamson (2): vfio/pci: Collect hot-reset devices to local buffer vfio/pci: Restore zero affected bus reset devices warning Ilpo Järvinen (1): EDAC/amd64: Convert PCIBIOS_* return codes to errnos Karthikeyan Ramasubramanian (1): platform/chrome: cros_ec: Handle events during suspend after resume completion Takashi Iwai (1): ALSA: hda/realtek: Fix conflicting quirk for PCI SSID 17aa:3820 Yao Xingtao (1): cxl/region: check interleave capability Yi Liu (1): vfio/pci: Init the count variable in collecting hot-reset devices drivers/cxl/core/hdm.c | 13 +++++ drivers/cxl/core/region.c | 82 +++++++++++++++++++++++++++++++ drivers/cxl/cxl.h | 2 + drivers/cxl/cxlmem.h | 10 ++++ drivers/edac/amd64_edac.c | 8 +-- drivers/platform/chrome/cros_ec.c | 16 +++--- drivers/vfio/pci/vfio_pci_core.c | 81 +++++++++++++++++++----------- sound/pci/hda/patch_realtek.c | 21 +++++++- tools/testing/cxl/test/cxl.c | 4 ++ 9 files changed, 196 insertions(+), 41 deletions(-) -- 2.25.1

2 9

[PATCH openEuler-22.03-LTS-SP1] ixgbe: fix pci device refcount leak
by Liu Jian 23 Aug '24

23 Aug '24

From: Yang Yingliang <yangyingliang(a)huawei.com> stable inclusion from stable-v5.10.164 commit 112df4cd2b09acd64bcd18f5ef83ba5d07b34bf0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALLC8 CVE: CVE-2022-48896 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- commit b93fb4405fcb5112c5739c5349afb52ec7f15c07 upstream. As the comment of pci_get_domain_bus_and_slot() says, it returns a PCI device with refcount incremented, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(), pci_dev_put() is called to avoid leak. Fixes: 8fa10ef01260 ("ixgbe: register a mdiobus") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Tested-by: Gurucharan G <gurucharanx.g(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c index fc389eecdd2b..b0413904b798 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c @@ -851,9 +851,11 @@ static struct pci_dev *ixgbe_get_first_secondary_devfn(unsigned int devfn) rp_pdev = pci_get_domain_bus_and_slot(0, 0, devfn); if (rp_pdev && rp_pdev->subordinate) { bus = rp_pdev->subordinate->number; + pci_dev_put(rp_pdev); return pci_get_domain_bus_and_slot(0, bus, 0); } + pci_dev_put(rp_pdev); return NULL; } @@ -870,6 +872,7 @@ static bool ixgbe_x550em_a_has_mii(struct ixgbe_hw *hw) struct ixgbe_adapter *adapter = hw->back; struct pci_dev *pdev = adapter->pdev; struct pci_dev *func0_pdev; + bool has_mii = false; /* For the C3000 family of SoCs (x550em_a) the internal ixgbe devices * are always downstream of root ports @ 0000:00:16.0 & 0000:00:17.0 @@ -880,15 +883,16 @@ static bool ixgbe_x550em_a_has_mii(struct ixgbe_hw *hw) func0_pdev = ixgbe_get_first_secondary_devfn(PCI_DEVFN(0x16, 0)); if (func0_pdev) { if (func0_pdev == pdev) - return true; - else - return false; + has_mii = true; + goto out; } func0_pdev = ixgbe_get_first_secondary_devfn(PCI_DEVFN(0x17, 0)); if (func0_pdev == pdev) - return true; + has_mii = true; - return false; +out: + pci_dev_put(func0_pdev); + return has_mii; } /** -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 90f4d81f4d19ad3d6d23b8775f4aa07771a1dac5
by kernel test robot 23 Aug '24

23 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 90f4d81f4d19ad3d6d23b8775f4aa07771a1dac5 !11068 Fix CVE-2024-39501 elapsed time: 735m configs tested: 21 configs skipped: 139 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 defconfig gcc-14.1.0 arm64 randconfig-001-20240823 gcc-14.1.0 arm64 randconfig-002-20240823 gcc-14.1.0 arm64 randconfig-003-20240823 gcc-14.1.0 arm64 randconfig-004-20240823 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240823 gcc-12 x86_64 buildonly-randconfig-002-20240823 gcc-12 x86_64 buildonly-randconfig-003-20240823 gcc-12 x86_64 buildonly-randconfig-004-20240823 clang-18 x86_64 buildonly-randconfig-005-20240823 gcc-12 x86_64 buildonly-randconfig-006-20240823 gcc-12 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240823 clang-18 x86_64 randconfig-002-20240823 clang-18 x86_64 randconfig-003-20240823 clang-18 x86_64 randconfig-004-20240823 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6 13455/13476] arch/arm64/kernel/virtcca_cvm_tsi.c:57:30: warning: variable 'ver' is uninitialized when used here
by kernel test robot 23 Aug '24

23 Aug '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: eccf28eefc9db7799534bd84bb958f3ecf978e2d commit: 721f4ea899ff2ab4e3283767cf125dc5952c1d15 [13455/13476] cvm_tsi: add support virtcca attestation config: arm64-allmodconfig (https://download.01.org/0day-ci/archive/20240823/202408230839.S2haccDx-lkp@…) compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project 26670e7fa4f032a019d23d56c6a02926e854e8af) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240823/202408230839.S2haccDx-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/202408230839.S2haccDx-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from arch/arm64/kernel/virtcca_cvm_tsi.c:3: In file included from include/linux/memblock.h:12: In file included from include/linux/mm.h:2242: include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 508 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 509 | item]; | ~~~~ include/linux/vmstat.h:515:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 515 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 516 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ include/linux/vmstat.h:527:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 527 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 528 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ include/linux/vmstat.h:536:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion] 536 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~ ^ 537 | NR_VM_NUMA_EVENT_ITEMS + | ~~~~~~~~~~~~~~~~~~~~~~ >> arch/arm64/kernel/virtcca_cvm_tsi.c:57:30: warning: variable 'ver' is uninitialized when used here [-Wuninitialized] 57 | TSI_ABI_VERSION_GET_MAJOR(ver), | ^~~ include/linux/printk.h:508:37: note: expanded from macro 'pr_warn' 508 | printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__) | ^~~~~~~~~~~ include/linux/printk.h:455:60: note: expanded from macro 'printk' 455 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__) | ^~~~~~~~~~~ include/linux/printk.h:427:19: note: expanded from macro 'printk_index_wrap' 427 | _p_func(_fmt, ##__VA_ARGS__); \ | ^~~~~~~~~~~ arch/arm64/include/asm/virtcca_cvm_smc.h:16:47: note: expanded from macro 'TSI_ABI_VERSION_GET_MAJOR' 16 | #define TSI_ABI_VERSION_GET_MAJOR(_version) ((_version) >> 16) | ^~~~~~~~ arch/arm64/kernel/virtcca_cvm_tsi.c:39:19: note: initialize the variable 'ver' to silence this warning 39 | unsigned long ver; | ^ | = 0 6 warnings generated. vim +/ver +57 arch/arm64/kernel/virtcca_cvm_tsi.c 36 37 static int __init tmm_tsi_init(void) 38 { 39 unsigned long ver; 40 int ret; 41 42 if (!is_virtcca_cvm_world()) 43 return -EIO; 44 45 ret = misc_register(&ioctl_dev); 46 if (ret) { 47 pr_err("tmm_tsi: misc device register failed (%d)!\n", ret); 48 return ret; 49 } 50 51 /* Allocate a large memory */ 52 token.buf = kzalloc(GRANULE_SIZE * MAX_TOKEN_GRANULE_COUNT, GFP_KERNEL); 53 if (!token.buf) 54 return -ENOMEM; 55 56 pr_warn("tmm_tsi: module loaded (version %lu.%lu).\n", > 57 TSI_ABI_VERSION_GET_MAJOR(ver), 58 TSI_ABI_VERSION_GET_MINOR(ver)); 59 60 return 0; 61 } 62 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6] BUILD REGRESSION eccf28eefc9db7799534bd84bb958f3ecf978e2d
by kernel test robot 23 Aug '24

23 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: eccf28eefc9db7799534bd84bb958f3ecf978e2d !10942 add support for arm virtcca attestation Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | |-- arch-arm64-kvm-arm.c:warning:variable-r-is-used-uninitialized-whenever-if-condition-is-false | |-- arch-arm64-kvm-tmi.c:warning:no-previous-prototype-for-function-tmi_tmm_inf_test | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_create_ttt_levels | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_get_num_brps | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_get_num_wrps | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_ipa_limit | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_populate_par_region | |-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_supports_pmu | `-- arch-arm64-kvm-virtcca_cvm.c:warning:no-previous-prototype-for-function-kvm_cvm_supports_sve |-- x86_64-buildonly-randconfig-005-20240823 | `-- kernel-sched-isolation.c:error:setup_max_cpus-undeclared-(first-use-in-this-function) `-- x86_64-buildonly-randconfig-006-20240823 `-- kernel-sched-isolation.c:error:setup_max_cpus-undeclared-(first-use-in-this-function) elapsed time: 732m configs tested: 36 configs skipped: 124 tested configs: arm64 allmodconfig clang-20 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240823 clang-20 arm64 randconfig-002-20240823 gcc-14.1.0 arm64 randconfig-003-20240823 gcc-14.1.0 arm64 randconfig-004-20240823 clang-20 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch randconfig-001-20240823 gcc-14.1.0 loongarch randconfig-002-20240823 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240823 gcc-12 x86_64 buildonly-randconfig-002-20240823 gcc-12 x86_64 buildonly-randconfig-003-20240823 gcc-12 x86_64 buildonly-randconfig-004-20240823 clang-18 x86_64 buildonly-randconfig-005-20240823 gcc-12 x86_64 buildonly-randconfig-006-20240823 gcc-12 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240823 clang-18 x86_64 randconfig-002-20240823 clang-18 x86_64 randconfig-003-20240823 clang-18 x86_64 randconfig-004-20240823 clang-18 x86_64 randconfig-005-20240823 clang-18 x86_64 randconfig-006-20240823 clang-18 x86_64 randconfig-011-20240823 gcc-12 x86_64 randconfig-012-20240823 clang-18 x86_64 randconfig-013-20240823 clang-18 x86_64 randconfig-014-20240823 gcc-11 x86_64 randconfig-015-20240823 clang-18 x86_64 randconfig-016-20240823 gcc-12 x86_64 randconfig-071-20240823 gcc-12 x86_64 randconfig-072-20240823 gcc-12 x86_64 randconfig-073-20240823 gcc-12 x86_64 randconfig-074-20240823 clang-18 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10] BUILD SUCCESS e9437292d288968fc2cb9f58fa81e21ab9471f7f
by kernel test robot 23 Aug '24

23 Aug '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: e9437292d288968fc2cb9f58fa81e21ab9471f7f !11045 bpf: Fix a segment issue when downgrading gso_size elapsed time: 746m configs tested: 34 configs skipped: 128 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-20 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240823 clang-20 arm64 randconfig-002-20240823 gcc-14.1.0 arm64 randconfig-003-20240823 gcc-14.1.0 arm64 randconfig-004-20240823 clang-20 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240823 gcc-12 x86_64 buildonly-randconfig-002-20240823 gcc-12 x86_64 buildonly-randconfig-003-20240823 gcc-12 x86_64 buildonly-randconfig-004-20240823 clang-18 x86_64 buildonly-randconfig-005-20240823 gcc-12 x86_64 buildonly-randconfig-006-20240823 gcc-12 x86_64 defconfig gcc-11 x86_64 randconfig-001-20240823 clang-18 x86_64 randconfig-002-20240823 clang-18 x86_64 randconfig-003-20240823 clang-18 x86_64 randconfig-004-20240823 clang-18 x86_64 randconfig-005-20240823 clang-18 x86_64 randconfig-006-20240823 clang-18 x86_64 randconfig-011-20240823 gcc-12 x86_64 randconfig-012-20240823 clang-18 x86_64 randconfig-013-20240823 clang-18 x86_64 randconfig-014-20240823 gcc-11 x86_64 randconfig-015-20240823 clang-18 x86_64 randconfig-016-20240823 gcc-12 x86_64 randconfig-071-20240823 gcc-12 x86_64 randconfig-072-20240823 gcc-12 x86_64 randconfig-073-20240823 gcc-12 x86_64 randconfig-074-20240823 clang-18 x86_64 randconfig-075-20240823 gcc-12 x86_64 randconfig-076-20240823 gcc-12 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] nilfs2: fix general protection fault in nilfs_btree_insert()
by Yang Yingliang 22 Aug '24

22 Aug '24

From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> stable inclusion from stable-v4.19.271 commit d9fde9eab1766170ff2ade67d09178d2cfd78749 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALLDY CVE: CVE-2023-52900 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit 7633355e5c7f29c049a9048e461427d1d8ed3051 upstream. If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling __nilfs_btree_get_block() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave. When nilfs_btree_insert() receives this spurious 'not found' code from nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: <TASK> nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [inline] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK> This patch fixes the root cause of this problem by replacing the error code that __nilfs_btree_get_block() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted. By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfs_bmap_convert_error(), and code -EIO will be eventually returned as it should be. Link: https://lkml.kernel.org/r/000000000000bd89e205f0e38355@google.com Link: https://lkml.kernel.org/r/20230105055356.8811-1-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: syzbot+ede796cecd5296353515(a)syzkaller.appspotmail.com Tested-by: Ryusuke Konishi <konishi.ryusuke(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: Yang Yingliang <yangyingliang(a)huawei.com> --- fs/nilfs2/btree.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/fs/nilfs2/btree.c b/fs/nilfs2/btree.c index e94b18eb5385..7959d3c34d20 100644 --- a/fs/nilfs2/btree.c +++ b/fs/nilfs2/btree.c @@ -478,9 +478,18 @@ static int __nilfs_btree_get_block(const struct nilfs_bmap *btree, __u64 ptr, ret = nilfs_btnode_submit_block(btnc, ptr, 0, REQ_OP_READ, 0, &bh, &submit_ptr); if (ret) { - if (ret != -EEXIST) - return ret; - goto out_check; + if (likely(ret == -EEXIST)) + goto out_check; + if (ret == -ENOENT) { + /* + * Block address translation failed due to invalid + * value of 'ptr'. In this case, return internal code + * -EINVAL (broken bmap) to notify bmap layer of fatal + * metadata corruption. + */ + ret = -EINVAL; + } + return ret; } if (ra) { -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
by Liu Jian 22 Aug '24

22 Aug '24

From: Baochen Qiang <quic_bqiang(a)quicinc.com> stable inclusion from stable-v5.10.224 commit 2e201b3d162c6c49417c438ffb30b58c9f85769f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALEA1 CVE: CVE-2024-43879 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- [ Upstream commit bcbd771cd5d68c0c52567556097d75f9fc4e7cd6 ] Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. Fixes: c4cbaf7973a7 ("cfg80211: Add support for HE") Signed-off-by: Baochen Qiang <quic_bqiang(a)quicinc.com> Link: https://msgid.link/20240606020653.33205-3-quic_bqiang@quicinc.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/wireless/util.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/wireless/util.c b/net/wireless/util.c index 5177fd63b1b8..15773db362a1 100644 --- a/net/wireless/util.c +++ b/net/wireless/util.c @@ -1357,7 +1357,9 @@ static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate) if (WARN_ON_ONCE(rate->nss < 1 || rate->nss > 8)) return 0; - if (rate->bw == RATE_INFO_BW_160) + if (rate->bw == RATE_INFO_BW_160 || + (rate->bw == RATE_INFO_BW_HE_RU && + rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_2x996)) result = rates_160M[rate->he_gi]; else if (rate->bw == RATE_INFO_BW_80 || (rate->bw == RATE_INFO_BW_HE_RU && -- 2.34.1

2 1

[PATCH OLK-5.10] wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
by Liu Jian 22 Aug '24

22 Aug '24

From: Baochen Qiang <quic_bqiang(a)quicinc.com> stable inclusion from stable-v5.10.224 commit 2e201b3d162c6c49417c438ffb30b58c9f85769f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALEA1 CVE: CVE-2024-43879 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- [ Upstream commit bcbd771cd5d68c0c52567556097d75f9fc4e7cd6 ] Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. Fixes: c4cbaf7973a7 ("cfg80211: Add support for HE") Signed-off-by: Baochen Qiang <quic_bqiang(a)quicinc.com> Link: https://msgid.link/20240606020653.33205-3-quic_bqiang@quicinc.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/wireless/util.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/wireless/util.c b/net/wireless/util.c index 5177fd63b1b8..15773db362a1 100644 --- a/net/wireless/util.c +++ b/net/wireless/util.c @@ -1357,7 +1357,9 @@ static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate) if (WARN_ON_ONCE(rate->nss < 1 || rate->nss > 8)) return 0; - if (rate->bw == RATE_INFO_BW_160) + if (rate->bw == RATE_INFO_BW_160 || + (rate->bw == RATE_INFO_BW_HE_RU && + rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_2x996)) result = rates_160M[rate->he_gi]; else if (rate->bw == RATE_INFO_BW_80 || (rate->bw == RATE_INFO_BW_HE_RU && -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
by Liu Jian 22 Aug '24

22 Aug '24

From: Baochen Qiang <quic_bqiang(a)quicinc.com> stable inclusion from stable-v4.19.320 commit 45d20a1c54be4f3173862c7b950d4468447814c9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALEA1 CVE: CVE-2024-43879 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------------------------------------- [ Upstream commit bcbd771cd5d68c0c52567556097d75f9fc4e7cd6 ] Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth. Fixes: c4cbaf7973a7 ("cfg80211: Add support for HE") Signed-off-by: Baochen Qiang <quic_bqiang(a)quicinc.com> Link: https://msgid.link/20240606020653.33205-3-quic_bqiang@quicinc.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/wireless/util.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/wireless/util.c b/net/wireless/util.c index b39ee17dbead..4e81210e5b24 100644 --- a/net/wireless/util.c +++ b/net/wireless/util.c @@ -1189,7 +1189,9 @@ static u32 cfg80211_calculate_bitrate_he(struct rate_info *rate) if (WARN_ON_ONCE(rate->nss < 1 || rate->nss > 8)) return 0; - if (rate->bw == RATE_INFO_BW_160) + if (rate->bw == RATE_INFO_BW_160 || + (rate->bw == RATE_INFO_BW_HE_RU && + rate->he_ru_alloc == NL80211_RATE_INFO_HE_RU_ALLOC_2x996)) result = rates_160M[rate->he_gi]; else if (rate->bw == RATE_INFO_BW_80 || (rate->bw == RATE_INFO_BW_HE_RU && -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/virtio: Fix GEM handle creation UAF
by Zeng Heng 22 Aug '24

22 Aug '24

From: Rob Clark <robdclark(a)chromium.org> stable inclusion from stable-v5.10.164 commit 68bcd063857075d2f9edfed6024387ac377923e2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALIA1 CVE: CVE-2022-48899 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 52531258318ed59a2dc5a43df2eaf0eb1d65438e ] Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Reviewed-by: Chia-I Wu <olvaffe(a)gmail.com> Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support") Cc: stable(a)vger.kernel.org Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221216233355.542197-2-robdc… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c index 33b8ebab178a..36efa273155d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c @@ -279,10 +279,18 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, drm_gem_object_release(obj); return ret; } - drm_gem_object_put(obj); rc->res_handle = qobj->hw_res_handle; /* similiar to a VM address */ rc->bo_handle = handle; + + /* + * The handle owns the reference now. But we must drop our + * remaining reference *after* we no longer need to dereference + * the obj. Otherwise userspace could guess the handle and + * race closing it from another thread. + */ + drm_gem_object_put(obj); + return 0; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] drm/virtio: Fix GEM handle creation UAF
by Zeng Heng 22 Aug '24

22 Aug '24

From: Rob Clark <robdclark(a)chromium.org> stable inclusion from stable-v4.19.270 commit 19ec87d06acfab2313ee82b2a689bf0c154e57ea category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IALIA1 CVE: CVE-2022-48899 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 52531258318ed59a2dc5a43df2eaf0eb1d65438e ] Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. Signed-off-by: Rob Clark <robdclark(a)chromium.org> Reviewed-by: Chia-I Wu <olvaffe(a)gmail.com> Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support") Cc: stable(a)vger.kernel.org Signed-off-by: Dmitry Osipenko <dmitry.osipenko(a)collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221216233355.542197-2-robdc… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c index 8d2f5ded86d6..a539843a03ba 100644 --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c @@ -309,7 +309,6 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, } return ret; } - drm_gem_object_put_unlocked(obj); rc->res_handle = res_id; /* similiar to a VM address */ rc->bo_handle = handle; @@ -318,6 +317,15 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data, virtio_gpu_unref_list(&validate_list); dma_fence_put(&fence->f); } + + /* + * The handle owns the reference now. But we must drop our + * remaining reference *after* we no longer need to dereference + * the obj. Otherwise userspace could guess the handle and + * race closing it from another thread. + */ + drm_gem_object_put_unlocked(obj); + return 0; fail_unref: if (vgdev->has_virgl_3d) { -- 2.25.1

2 1

[PATCH 1/1] libhns:Fixes several bugs for hns
by Chengchang Tang 22 Aug '24

22 Aug '24

From: Xinghai Cen <cenxinghai(a)h-partners.com> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IALOAP ---------------------------------------------------------------------- Fixes several bugs for hns: libhns: Fix overwritten SL in DSCP mode libhns: Support returning the final value of SL configuration libhns: Fix memory leakage when DCA is enabled libhns: Fix the exception branch of wr_start() is not locked Signed-off-by: Xinghai Cen <cenxinghai(a)h-partners.com> --- ...bhns-Fix-overwritten-SL-in-DSCP-mode.patch | 44 +++++++++++++++++++ ...eturning-the-final-value-of-SL-confi.patch | 34 ++++++++++++++ ...x-memory-leakage-when-DCA-is-enabled.patch | 34 ++++++++++++++ ...xception-branch-of-wr_start-is-not-l.patch | 35 +++++++++++++++ rdma-core.spec | 12 ++++- 5 files changed, 158 insertions(+), 1 deletion(-) create mode 100644 0083-libhns-Fix-overwritten-SL-in-DSCP-mode.patch create mode 100644 0084-libhns-Support-returning-the-final-value-of-SL-confi.patch create mode 100644 0085-libhns-Fix-memory-leakage-when-DCA-is-enabled.patch create mode 100644 0086-libhns-Fix-the-exception-branch-of-wr_start-is-not-l.patch diff --git a/0083-libhns-Fix-overwritten-SL-in-DSCP-mode.patch b/0083-libhns-Fix-overwritten-SL-in-DSCP-mode.patch new file mode 100644 index 0000000..c600d2b --- /dev/null +++ b/0083-libhns-Fix-overwritten-SL-in-DSCP-mode.patch @@ -0,0 +1,44 @@ +From 40e7e1643cd67bbdd0865372c4ff64d42d1aaf0b Mon Sep 17 00:00:00 2001 +From: Luoyouming <luoyouming(a)huawei.com> +Date: Mon, 29 Jan 2024 15:38:18 +0800 +Subject: [PATCH 1/4] libhns: Fix overwritten SL in DSCP mode + +After configuring the DSCP mode, the driver needs to use the +priority as the SL instead of the user-configured SL. +Adjusting the assignment order ensures that the priority is +used as the SL in DSCP mode. + +Fixes: 6ec5d1f3f04c ("libhns: Support DSCP") +Signed-off-by: Luoyouming <luoyouming(a)huawei.com> +--- + providers/hns/hns_roce_u_hw_v2.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +diff --git a/providers/hns/hns_roce_u_hw_v2.c b/providers/hns/hns_roce_u_hw_v2.c +index 8f071e1..42b4f32 100644 +--- a/providers/hns/hns_roce_u_hw_v2.c ++++ b/providers/hns/hns_roce_u_hw_v2.c +@@ -1896,7 +1896,9 @@ static void record_qp_attr(struct ibv_qp *qp, struct ibv_qp_attr *attr, + if (attr_mask & IBV_QP_PORT) + hr_qp->port_num = attr->port_num; + +- if (attr_mask & IBV_QP_AV) ++ if (hr_qp->tc_mode == HNS_ROCE_TC_MAP_MODE_DSCP) ++ hr_qp->sl = hr_qp->priority; ++ else if (attr_mask & IBV_QP_AV) + hr_qp->sl = attr->ah_attr.sl; + + if (attr_mask & IBV_QP_QKEY) +@@ -1959,9 +1961,6 @@ static int hns_roce_u_v2_modify_qp(struct ibv_qp *qp, struct ibv_qp_attr *attr, + hns_roce_init_qp_indices(to_hr_qp(qp)); + } + +- if (hr_qp->tc_mode == HNS_ROCE_TC_MAP_MODE_DSCP) +- hr_qp->sl = hr_qp->priority; +- + /* Try to shrink the DCA mem */ + if (ctx->dca_ctx.mem_cnt > 0) + hns_roce_shrink_dca_mem(ctx); +-- +2.33.0 + diff --git a/0084-libhns-Support-returning-the-final-value-of-SL-confi.patch b/0084-libhns-Support-returning-the-final-value-of-SL-confi.patch new file mode 100644 index 0000000..2b01cd6 --- /dev/null +++ b/0084-libhns-Support-returning-the-final-value-of-SL-confi.patch @@ -0,0 +1,34 @@ +From fc50769b446a5418767058cd2a5b5e7a9724a391 Mon Sep 17 00:00:00 2001 +From: Luoyouming <luoyouming(a)huawei.com> +Date: Mon, 29 Jan 2024 16:12:55 +0800 +Subject: [PATCH 2/4] libhns: Support returning the final value of SL + configuration +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Returns the real SL used in HW to user��which can be used in variety of scenarios. +E.g. The STARS mode. + +Signed-off-by: Luoyouming <luoyouming(a)huawei.com> +--- + providers/hns/hns_roce_u_hw_v2.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/providers/hns/hns_roce_u_hw_v2.c b/providers/hns/hns_roce_u_hw_v2.c +index 42b4f32..af25e6e 100644 +--- a/providers/hns/hns_roce_u_hw_v2.c ++++ b/providers/hns/hns_roce_u_hw_v2.c +@@ -1967,6 +1967,9 @@ static int hns_roce_u_v2_modify_qp(struct ibv_qp *qp, struct ibv_qp_attr *attr, + + record_qp_attr(qp, attr, attr_mask); + ++ // Update the SL value and return it to the user. ++ attr->ah_attr.sl = hr_qp->sl; ++ + return ret; + } + +-- +2.33.0 + diff --git a/0085-libhns-Fix-memory-leakage-when-DCA-is-enabled.patch b/0085-libhns-Fix-memory-leakage-when-DCA-is-enabled.patch new file mode 100644 index 0000000..aa4aa63 --- /dev/null +++ b/0085-libhns-Fix-memory-leakage-when-DCA-is-enabled.patch @@ -0,0 +1,34 @@ +From 485a60f8850630c37856f68be3fbf37bfa9ac019 Mon Sep 17 00:00:00 2001 +From: wenglianfa <wenglianfa(a)huawei.com> +Date: Thu, 25 Jul 2024 11:06:01 +0800 +Subject: [PATCH 3/4] libhns: Fix memory leakage when DCA is enabled + +After DCA is enabled and a QP is created, the memory block +applied for DCA is not free when the QP is destroyed. Here +fix it. + +Fixes: 3aa4683ef700 ("libhns: Add support for attaching QP's WQE buffer") +Signed-off-by: wenglianfa <wenglianfa(a)huawei.com> +--- + providers/hns/hns_roce_u_verbs.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/providers/hns/hns_roce_u_verbs.c b/providers/hns/hns_roce_u_verbs.c +index 090efbf..dae8298 100644 +--- a/providers/hns/hns_roce_u_verbs.c ++++ b/providers/hns/hns_roce_u_verbs.c +@@ -1617,7 +1617,10 @@ static void qp_free_wqe(struct hns_roce_qp *qp) + + if (qp->rq.wqe_cnt) + free(qp->rq.wrid); +- hns_roce_free_buf(&qp->buf); ++ if (qp->dca_wqe.bufs) ++ free(qp->dca_wqe.bufs); ++ else ++ hns_roce_free_buf(&qp->buf); + } + + static int qp_alloc_wqe(struct ibv_qp_init_attr_ex *attr, +-- +2.33.0 + diff --git a/0086-libhns-Fix-the-exception-branch-of-wr_start-is-not-l.patch b/0086-libhns-Fix-the-exception-branch-of-wr_start-is-not-l.patch new file mode 100644 index 0000000..e3e4d29 --- /dev/null +++ b/0086-libhns-Fix-the-exception-branch-of-wr_start-is-not-l.patch @@ -0,0 +1,35 @@ +From 41592115435779d7c41e7f1677520b9c641289d9 Mon Sep 17 00:00:00 2001 +From: wenglianfa <wenglianfa(a)huawei.com> +Date: Wed, 12 Jun 2024 17:11:13 +0800 +Subject: [PATCH 4/4] libhns: Fix the exception branch of wr_start() is not + locked + +The provider should provide locking to ensure that ibv_wr_start() +and ibv_wr_complete()/abort() form a per-QP critical section +where no other threads can enter. + +The exception branch of wr_start() is not locked, fix it here. +Because check_qp_send () does not require lock protection, +hns_roce_spin_lock () is placed after check_qp_send (). + +Fixes: 36446a56eea5 ("libhns: Extended QP supports the new post send mechanism") +Signed-off-by: wenglianfa <wenglianfa(a)huawei.com> +--- + providers/hns/hns_roce_u_hw_v2.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/providers/hns/hns_roce_u_hw_v2.c b/providers/hns/hns_roce_u_hw_v2.c +index af25e6e..79f225c 100644 +--- a/providers/hns/hns_roce_u_hw_v2.c ++++ b/providers/hns/hns_roce_u_hw_v2.c +@@ -2975,6 +2975,7 @@ static void wr_start(struct ibv_qp_ex *ibv_qp) + + ret = check_qp_send(qp, ctx); + if (ret) { ++ hns_roce_spin_lock(&qp->sq.hr_lock); + qp->err = ret; + return; + } +-- +2.33.0 + diff --git a/rdma-core.spec b/rdma-core.spec index f0de576..8caac46 100644 --- a/rdma-core.spec +++ b/rdma-core.spec @@ -1,6 +1,6 @@ Name: rdma-core Version: 41.0 -Release: 26 +Release: 27 Summary: RDMA core userspace libraries and daemons License: GPLv2 or BSD Url: https://github.com/linux-rdma/rdma-core @@ -88,6 +88,10 @@ patch79: 0079-libhns-Removes-a-repeated-initialization-of-a-spinlo.patch patch80: 0080-libhns-Fix-owner-bit-when-SQ-wraps-around-in-new-IO.patch patch81: 0081-libhns-Fix-missing-DB-when-compiler-does-not-support.patch patch82: 0082-ibnetdisc-Fix-leak-in-add_to_portlid_hash.patch +patch83: 0083-libhns-Fix-overwritten-SL-in-DSCP-mode.patch +patch84: 0084-libhns-Support-returning-the-final-value-of-SL-confi.patch +patch85: 0085-libhns-Fix-memory-leakage-when-DCA-is-enabled.patch +patch86: 0086-libhns-Fix-the-exception-branch-of-wr_start-is-not-l.patch BuildRequires: binutils cmake >= 2.8.11 gcc libudev-devel pkgconfig pkgconfig(libnl-3.0) BuildRequires: pkgconfig(libnl-route-3.0) valgrind-devel systemd systemd-devel @@ -335,6 +339,12 @@ fi %{_mandir}/* %changelog +* Thu Aug 22 2024 Xinghai Cen <cenxinghai(a)h-partners.com> - 41.0-27 +- Type: bugfix +- ID: NA +- SUG: NA +- DESC: Fixes several bugs for hns + * Thu Aug 8 2024 yanshuai <yanshuai01(a)kylinos.cn> - 41.0-26 - Type: bugfix - ID: NA -- 2.33.0

1 0

[PATCH openEuler-1.0-LTS 0/3] Fix CVE-2024-39501
by Chen Jun 22 Aug '24

22 Aug '24

*** BLURB HERE *** Amit Cohen (1): selftests: forwarding: devlink_lib: Wait for udev events after reloading Dan Williams (1): driver core: Fix uevent_show() vs driver detach race Dirk Behme (1): drivers: core: synchronize really_probe() and dev_uevent() drivers/base/core.c | 10 ++++++++-- drivers/base/module.c | 4 ++++ tools/testing/selftests/net/forwarding/devlink_lib.sh | 2 ++ 3 files changed, 14 insertions(+), 2 deletions(-) -- 2.17.1

2 4