- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 v2] sched: smart_grid: fix potential NULL pointer dereference
by Yipeng Zou 19 Jun '24

19 Jun '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA6J1H CVE: NA ---------------------------------------- There is a low probability that kernel panic will occur when we test with smart_grid. The log show below: [65160.746953] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [65160.746990] Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 [65160.756974] Mem abort info: [65160.766849] Mem abort info: [65160.770660] ESR = 0x96000004 [65160.770663] EC = 0x25: DABT (current EL), IL = 32 bits [65160.774374] ESR = 0x96000004 [65160.774377] EC = 0x25: DABT (current EL), IL = 32 bits [65160.778428] SET = 0, FnV = 0 [65160.778430] EA = 0, S1PTW = 0 [65160.784728] SET = 0, FnV = 0 [65160.784731] EA = 0, S1PTW = 0 [65160.786018] Detected VIPT I-cache on CPU104 [65160.786070] GICv3: CPU104: found redistributor 3a0000 region 104: 0x00002000aa300000 [65160.786240] CPU104: Booted secondary processor 0x00003a0000 [0x481fd010] [65160.788696] Data abort info: [65160.788699] ISV = 0, ISS = 0x00000004 [65160.794911] Data abort info: [65160.794913] ISV = 0, ISS = 0x00000004 [65160.798965] CM = 0, WnR = 0 [65160.798967] user pgtable: 4k pages, 48-bit VAs, pgdp=00000030059b2000 [65160.803102] CM = 0, WnR = 0 [65160.803104] user pgtable: 4k pages, 48-bit VAs, pgdp=00000020ab07c000 [65160.807066] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000 [65160.811113] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000 [65160.816199] Internal error: Oops: 0000000096000004 [#1] SMP [65160.832723] Modules linked in: [65161.006841] CPU: 39 PID: 195931 Comm: (hrottler) Kdump: loaded Nottainted 5.10.0 #51 [65161.016660] Hardware name: Huawei TaiShan 200 (Model 5280)/BC82AMDD, BIOS 1.08 12/14/2019 [65161.026146] pstate: 80400089 (Nzcv daIf +PAN -UAO -TCO BTYPE=--) [65161.033199] pc : set_task_select_cpus+0x8c/0x3d0 [65161.038865] lr : select_task_rq_fair+0x1c8/0x5cc [65161.044528] sp : ffff800172673ba0 [65161.048888] x29: ffff800172673ba0 x28: ffff00303f22cd00 [65161.055237] x27: 0000000000000027 x26: 0000000000000027 [65161.061583] x25: 0000aaaafd32b180 x24: 0000000000000002 [65161.067925] x23: ffff00303f22cd00 x22: 0000000000000000 [65161.074264] x21: ffff800172673cc4 x20: ffff00303f22cd00 [65161.080603] x19: ffff00303f22d7f4 x18: 0000000000000000 [65161.086938] x17: 0000000000000000 x16: 0000000000000000 [65161.093266] x15: 0000aaaafd365130 x14: 0000000000000000 [65161.099584] x13: 0000000000000000 x12: 0000000000000000 [65161.105892] x11: 0000000000000000 x10: 0000000000000000 [65161.112194] x9 : ffff800010129e80 x8 : 0000000000000000 [65161.118489] x7 : ffff00303f22cd00 x6 : 0000000000000001 [65161.124776] x5 : 0000000000000000 x4 : ffff8000118f5008 [65161.131058] x3 : 0000000000000000 x2 : 0000000000000002 [65161.137331] x1 : ffff800172673cc4 x0 : 0000000000000000 [65161.143598] Call trace: [65161.147005] set_task_select_cpus+0x8c/0x3d0 [65161.152225] select_task_rq_fair+0x1c8/0x5cc [65161.157439] sched_exec+0x94/0x1bc [65161.161782] bprm_execve.part.0+0x60/0x164 [65161.166813] bprm_execve+0x78/0xc0 [65161.171143] do_execveat_common+0x1c4/0x250 [65161.176244] __arm64_sys_execve+0x48/0x70 [65161.181167] invoke_syscall+0x50/0x130 [65161.185824] el0_svc_common.constprop.0+0x158/0x180 [65161.191601] do_el0_svc+0x34/0xe0 [65161.195816] el0_svc+0x20/0x30 [65161.199773] el0_sync_handler+0xb8/0xc0 [65161.204502] el0_sync+0x1e8/0x200 [65161.208712] Code: d50323bf d65f03c0 f941ac00 f941c400 (f9400400) It's panic on task_group(current)->auto_affinity dereference. In the scenario like: CPU0 CPU1 rmdir cgroup free auto_affinity try to wake up select_task_rq_fair auto_affinity(NULL) dereference panic Because there is no protect when remove task from one cgroup with task wakeup, so we need to check auto_affinity is NULL in task_prefer_cpus. Fixes: 6eb07f9925a9 ("sched: Introduce smart grid scheduling strategy for cfs") Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 84af50f4285f..d2efd40fb784 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6833,7 +6833,8 @@ static void smart_grid_usage_dec(void) static inline struct cpumask *task_prefer_cpus(struct task_struct *p) { - if (!smart_grid_used()) + if (!smart_grid_used() || + !task_group(p)->auto_affinity) return p->prefer_cpus; if (task_group(p)->auto_affinity->mode == 0) -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 1/2] xhci: Fix command ring pointer corruption while aborting a command
by Yuan Can 19 Jun '24

19 Jun '24

From: Pavankumar Kondeti <pkondeti(a)codeaurora.org> stable inclusion from stable-v4.19.213 commit dec944bb7079b37968cf69c8a438f91f15c4cc61 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RB55 CVE: CVE-2021-47434 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream. The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. Since we split the 64 bit write into two 32 bit writes, there is a possibility of xHC command ring stopped before the upper dword (all zeros) is written. If that happens, xHC updates the upper dword of its internal command ring pointer with all zeros. Next time, when the command ring is restarted, we see xHC memory access failures. Fix this issue by only writing to the lower dword of CRCR where all control bits are located. Cc: stable(a)vger.kernel.org Signed-off-by: Pavankumar Kondeti <pkondeti(a)codeaurora.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://lore.kernel.org/r/20211008092547.3996295-5-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- drivers/usb/host/xhci-ring.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 98b67605d3cf..22655e0d257a 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -339,16 +339,22 @@ static void xhci_handle_stopped_cmd_ring(struct xhci_hcd *xhci, /* Must be called with xhci->lock held, releases and aquires lock back */ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci, unsigned long flags) { - u64 temp_64; + u32 temp_32; int ret; xhci_dbg(xhci, "Abort command ring\n"); reinit_completion(&xhci->cmd_ring_stop_completion); - temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring); - xhci_write_64(xhci, temp_64 | CMD_RING_ABORT, - &xhci->op_regs->cmd_ring); + /* + * The control bits like command stop, abort are located in lower + * dword of the command ring control register. Limit the write + * to the lower dword to avoid corrupting the command ring pointer + * in case if the command ring is stopped by the time upper dword + * is written. + */ + temp_32 = readl(&xhci->op_regs->cmd_ring); + writel(temp_32 | CMD_RING_ABORT, &xhci->op_regs->cmd_ring); /* Section 4.6.1.2 of xHCI 1.0 spec says software should also time the * completion of the Command Abort operation. If CRR is not negated in 5 -- 2.17.1

2 2

[PATCH openEuler-1.0-LTS 1/2] xhci: Fix command ring pointer corruption while aborting a command
by Yuan Can 19 Jun '24

19 Jun '24

From: Pavankumar Kondeti <pkondeti(a)codeaurora.org> stable inclusion from stable-v4.19.213 commit dec944bb7079b37968cf69c8a438f91f15c4cc61 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RB55 CVE: CVE-2021-47434 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream. The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. Since we split the 64 bit write into two 32 bit writes, there is a possibility of xHC command ring stopped before the upper dword (all zeros) is written. If that happens, xHC updates the upper dword of its internal command ring pointer with all zeros. Next time, when the command ring is restarted, we see xHC memory access failures. Fix this issue by only writing to the lower dword of CRCR where all control bits are located. Cc: stable(a)vger.kernel.org Signed-off-by: Pavankumar Kondeti <pkondeti(a)codeaurora.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://lore.kernel.org/r/20211008092547.3996295-5-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- drivers/usb/host/xhci-ring.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 98b67605d3cf..22655e0d257a 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -339,16 +339,22 @@ static void xhci_handle_stopped_cmd_ring(struct xhci_hcd *xhci, /* Must be called with xhci->lock held, releases and aquires lock back */ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci, unsigned long flags) { - u64 temp_64; + u32 temp_32; int ret; xhci_dbg(xhci, "Abort command ring\n"); reinit_completion(&xhci->cmd_ring_stop_completion); - temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring); - xhci_write_64(xhci, temp_64 | CMD_RING_ABORT, - &xhci->op_regs->cmd_ring); + /* + * The control bits like command stop, abort are located in lower + * dword of the command ring control register. Limit the write + * to the lower dword to avoid corrupting the command ring pointer + * in case if the command ring is stopped by the time upper dword + * is written. + */ + temp_32 = readl(&xhci->op_regs->cmd_ring); + writel(temp_32 | CMD_RING_ABORT, &xhci->op_regs->cmd_ring); /* Section 4.6.1.2 of xHCI 1.0 spec says software should also time the * completion of the Command Abort operation. If CRR is not negated in 5 -- 2.17.1

2 2

[PATCH openEuler-1.0-LTS] coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()
by Chen Zhongjin 19 Jun '24

19 Jun '24

From: Sai Prakash Ranjan <saiprakash.ranjan(a)codeaurora.org> stable inclusion from stable-v4.19.198 commit 04bd77ef4f4d9fc6102023b85f4590fc2130aac5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4FH CVE: CVE-2021-47346 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5fae8a946ac2df879caf3f79a193d4766d00239b upstream. commit 6f755e85c332 ("coresight: Add helper for inserting synchronization packets") removed trailing '\0' from barrier_pkt array and updated the call sites like etb_update_buffer() to have proper checks for barrier_pkt size before read but missed updating tmc_update_etf_buffer() which still reads barrier_pkt past the array size resulting in KASAN out-of-bounds bug. Fix this by adding a check for barrier_pkt size before accessing like it is done in etb_update_buffer(). BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698 Read of size 4 at addr ffffffd05b7d1030 by task perf/2629 Call trace: dump_backtrace+0x0/0x27c show_stack+0x20/0x2c dump_stack+0x11c/0x188 print_address_description+0x3c/0x4a4 __kasan_report+0x140/0x164 kasan_report+0x10/0x18 __asan_report_load4_noabort+0x1c/0x24 tmc_update_etf_buffer+0x4b8/0x698 etm_event_stop+0x248/0x2d8 etm_event_del+0x20/0x2c event_sched_out+0x214/0x6f0 group_sched_out+0xd0/0x270 ctx_sched_out+0x2ec/0x518 __perf_event_task_sched_out+0x4fc/0xe6c __schedule+0x1094/0x16a0 preempt_schedule_irq+0x88/0x170 arm64_preempt_schedule_irq+0xf0/0x18c el1_irq+0xe8/0x180 perf_event_exec+0x4d8/0x56c setup_new_exec+0x204/0x400 load_elf_binary+0x72c/0x18c0 search_binary_handler+0x13c/0x420 load_script+0x500/0x6c4 search_binary_handler+0x13c/0x420 exec_binprm+0x118/0x654 __do_execve_file+0x77c/0xba4 __arm64_compat_sys_execve+0x98/0xac el0_svc_common+0x1f8/0x5e0 el0_svc_compat_handler+0x84/0xb0 el0_svc_compat+0x10/0x50 The buggy address belongs to the variable: barrier_pkt+0x10/0x40 Memory state around the buggy address: ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03 ^ ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa ================================================================== Link: https://lore.kernel.org/r/20210505093430.18445-1-saiprakash.ranjan@codeauro… Fixes: 0c3fc4d5fa26 ("coresight: Add barrier packet for synchronisation") Cc: stable(a)vger.kernel.org Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan(a)codeaurora.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Link: https://lore.kernel.org/r/20210614175901.532683-6-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/hwtracing/coresight/coresight-tmc-etf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c index e31061308e19..988cbb5f3e0b 100644 --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c @@ -472,7 +472,7 @@ static void tmc_update_etf_buffer(struct coresight_device *csdev, buf_ptr = buf->data_pages[cur] + offset; *buf_ptr = readl_relaxed(drvdata->base + TMC_RRD); - if (lost && *barrier) { + if (lost && i < CORESIGHT_BARRIER_PKT_SIZE) { *buf_ptr = *barrier; barrier++; } -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] kprobes: Fix possible use-after-free issue on kprobe registration
by Chen Zhongjin 19 Jun '24

19 Jun '24

stable inclusion from stable-v4.19.313 commit b5808d40093403334d939e2c3c417144d12a6f33 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QRI5 CVE: CVE-2024-35955 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 325f3fb551f8cd672dbbfc4cf58b14f9ee3fc9e8 upstream. When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE. Link: https://lore.kernel.org/all/20240410015802.265220-1-zhengyejian1@huawei.com/ Fixes: 28f6c37a2910 ("kprobes: Forbid probing on trampoline and BPF code areas") Cc: stable(a)vger.kernel.org Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> [Fix conflict due to lack dependency commit 223a76b268c9 ("kprobes: Fix coding style issues")] Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: kernel/kprobes.c [This conflict because dependency commit 1efda38d6f9b ("kprobes: Prohibit probes in gate area") not merged] Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- kernel/kprobes.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index f4871c2b69b6..81ea5a3bd05f 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1564,9 +1564,17 @@ static int check_kprobe_address_safe(struct kprobe *p, jump_label_lock(); preempt_disable(); - /* Ensure it is not in reserved area nor out of text */ - if (!(core_kernel_text((unsigned long) p->addr) || - is_module_text_address((unsigned long) p->addr)) || + /* Ensure the address is in a text area, and find a module if exists. */ + *probed_mod = NULL; + if (!core_kernel_text((unsigned long) p->addr)) { + *probed_mod = __module_text_address((unsigned long) p->addr); + if (!(*probed_mod)) { + ret = -EINVAL; + goto out; + } + } + /* Ensure it is not in reserved area. */ + if (in_gate_area_no_mm((unsigned long) p->addr) || within_kprobe_blacklist((unsigned long) p->addr) || jump_label_text_reserved(p->addr, p->addr) || find_bug((unsigned long)p->addr)) { @@ -1574,8 +1582,7 @@ static int check_kprobe_address_safe(struct kprobe *p, goto out; } - /* Check if are we probing a module */ - *probed_mod = __module_text_address((unsigned long) p->addr); + /* Get module refcount and reject __init functions for loaded modules. */ if (*probed_mod) { /* * We must hold a refcount of the probed module while updating -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] can: sja1000: fix use after free in ems_pcmcia_add_card()
by Chen Zhongjin 19 Jun '24

19 Jun '24

From: Dan Carpenter <dan.carpenter(a)oracle.com> stable inclusion from stable-v4.19.221 commit ccf070183e4655824936c0f96c4a2bcca93419aa category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9S254 CVE: CVE-2021-47521 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 3ec6ca6b1a8e64389f0212b5a1b0f6fed1909e45 upstream. If the last channel is not available then "dev" is freed. Fortunately, we can just use "pdev->irq" instead. Also we should check if at least one channel was set up. Fixes: fd734c6f25ae ("can/sja1000: add driver for EMS PCMCIA card") Link: https://lore.kernel.org/all/20211124145041.GB13656@kili Cc: stable(a)vger.kernel.org Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net> Tested-by: Oliver Hartkopp <socketcan(a)hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Chen Zhongjin <chenzhongjin(a)huawei.com> --- drivers/net/can/sja1000/ems_pcmcia.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/can/sja1000/ems_pcmcia.c b/drivers/net/can/sja1000/ems_pcmcia.c index 381de998d2f1..fef5c59c0f4c 100644 --- a/drivers/net/can/sja1000/ems_pcmcia.c +++ b/drivers/net/can/sja1000/ems_pcmcia.c @@ -243,7 +243,12 @@ static int ems_pcmcia_add_card(struct pcmcia_device *pdev, unsigned long base) free_sja1000dev(dev); } - err = request_irq(dev->irq, &ems_pcmcia_interrupt, IRQF_SHARED, + if (!card->channels) { + err = -ENODEV; + goto failure_cleanup; + } + + err = request_irq(pdev->irq, &ems_pcmcia_interrupt, IRQF_SHARED, DRV_NAME, card); if (!err) return 0; -- 2.25.1

2 3

[PATCH openEuler-1.0-LTS 0/2] spi: Fix deadlock when adding SPI controllers on SPI buses
by Zeng Heng 19 Jun '24

19 Jun '24

Mark Brown (1): spi: Fix deadlock when adding SPI controllers on SPI buses Zeng Heng (1): spi: fix kabi breakage in struct spi_controller drivers/spi/spi.c | 43 ++++++++++++++++++++++++++---------------- include/linux/device.h | 8 ++++++++ 2 files changed, 35 insertions(+), 16 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6] memcg: attach memcg async reclaim worker to curcpu
by Lu Jialin 19 Jun '24

19 Jun '24

hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I9PXW6 -------------------------------- Attach memcg async relcaim worker to a curcpu, which will make sure memcg async reclaim worker will be scheduled among the cpumask belong to the current's cpuset. Signed-off-by: Lu Jialin <lujialin4(a)huawei.com> --- mm/memcontrol.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index c7958805ee66..d97410e3ec0e 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2926,7 +2926,13 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, #ifdef CONFIG_MEMCG_V1_RECLAIM if (is_high_async_reclaim(memcg) && !mem_high) { WRITE_ONCE(memcg->high_async_reclaim, true); - schedule_work(&memcg->high_work); +#ifdef CONFIG_MEMCG_SWAP_QOS + if (static_branch_likely(&memcg_swap_qos_key)) + schedule_work_on(smp_processor_id(), + &memcg->high_work); + else +#endif + schedule_work(&memcg->high_work); break; } #endif -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/amd/display: Fix division by zero in setup_dsc_config
by Jinjiang Tu 19 Jun '24

19 Jun '24

From: Jose Fernandez <josef(a)netflix.com> stable inclusion from stable-v5.15.160 commit a32c8f951c8a456c1c251e1dcdf21787f8066445 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA3UT7 CVE: CVE-2024-36969 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 130afc8a886183a94cf6eab7d24f300014ff87ba upstream. When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero. The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected. kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira(a)amd.com> Signed-off-by: Jose Fernandez <josef(a)netflix.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3113 Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: "Limonciello, Mario" <mario.limonciello(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c index 4c844cfaa956..cbbcc34ac58b 100644 --- a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c +++ b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c @@ -735,7 +735,12 @@ static bool setup_dsc_config( if (!is_dsc_possible) goto done; - dsc_cfg->num_slices_v = pic_height/slice_height; + if (slice_height > 0) { + dsc_cfg->num_slices_v = pic_height / slice_height; + } else { + is_dsc_possible = false; + goto done; + } // Final decission: can we do DSC or not? if (is_dsc_possible) { -- 2.25.1

2 1

[PATCH OLK-5.10] drm/amd/display: Fix division by zero in setup_dsc_config
by Jinjiang Tu 19 Jun '24

19 Jun '24

From: Jose Fernandez <josef(a)netflix.com> stable inclusion from stable-v5.15.160 commit a32c8f951c8a456c1c251e1dcdf21787f8066445 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IA3UT7 CVE: CVE-2024-36969 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 130afc8a886183a94cf6eab7d24f300014ff87ba upstream. When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero. The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected. kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113. Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira(a)amd.com> Signed-off-by: Jose Fernandez <josef(a)netflix.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3113 Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: "Limonciello, Mario" <mario.limonciello(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c index 4c844cfaa956..cbbcc34ac58b 100644 --- a/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c +++ b/drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c @@ -735,7 +735,12 @@ static bool setup_dsc_config( if (!is_dsc_possible) goto done; - dsc_cfg->num_slices_v = pic_height/slice_height; + if (slice_height > 0) { + dsc_cfg->num_slices_v = pic_height / slice_height; + } else { + is_dsc_possible = false; + goto done; + } // Final decission: can we do DSC or not? if (is_dsc_possible) { -- 2.25.1

2 1