- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
by Zeng Heng 15 Jul '24

15 Jul '24

From: Anand K Mistry <amistry(a)google.com> mainline inclusion from mainline-v5.16-rc1 commit 8244a3bc27b3efd057da154b8d7e414670d5044f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEV CVE: CVE-2021-47200 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry(a)google.com> Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.5+ Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc23… Conflicts: drivers/gpu/drm/drm_prime.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/drm_prime.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 825499ea3ff5..c806cf4c9a48 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -724,11 +724,14 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) vma->vm_pgoff += drm_vma_node_start(&obj->vma_node); if (obj->funcs && obj->funcs->mmap) { + + drm_gem_object_get(obj); ret = obj->funcs->mmap(obj, vma); - if (ret) + if (ret) { + drm_gem_object_put(obj); return ret; + } vma->vm_private_data = obj; - drm_gem_object_get(obj); return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
by Zeng Heng 15 Jul '24

15 Jul '24

From: Anand K Mistry <amistry(a)google.com> mainline inclusion from mainline-v5.16-rc1 commit 8244a3bc27b3efd057da154b8d7e414670d5044f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9FNEV CVE: CVE-2021-47200 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry(a)google.com> Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v5.5+ Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc23… Conflicts: drivers/gpu/drm/drm_prime.c [Resolve conflicts due to several refactor patches not merged.] Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/gpu/drm/drm_prime.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 825499ea3ff5..c806cf4c9a48 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -724,11 +724,14 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) vma->vm_pgoff += drm_vma_node_start(&obj->vma_node); if (obj->funcs && obj->funcs->mmap) { + + drm_gem_object_get(obj); ret = obj->funcs->mmap(obj, vma); - if (ret) + if (ret) { + drm_gem_object_put(obj); return ret; + } vma->vm_private_data = obj; - drm_gem_object_get(obj); return 0; } -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

From: Nathan Lynch <nathanl(a)linux.ibm.com> stable inclusion from stable-v4.19.317 commit acf2b80c31c37acab040baa3cf5f19fbd5140b18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACRHB CVE: CVE-2024-40974 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ff2e185cf73df480ec69675936c4ee75a445c3e4 ] plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes. Signed-off-by: Nathan Lynch <nathanl(a)linux.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://msgid.link/20240408-pseries-hvcall-retbuf-v1-1-ebc73d7253cf@linux.i… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Huang Xiaojia <huangxiaojia2(a)huawei.com> --- arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h index 00c8cda1c9c3..a8035af4fc50 100644 --- a/arch/powerpc/include/asm/hvcall.h +++ b/arch/powerpc/include/asm/hvcall.h @@ -453,7 +453,7 @@ long plpar_hcall_norets_notrace(unsigned long opcode, ...); * Used for all but the craziest of phyp interfaces (see plpar_hcall9) */ #define PLPAR_HCALL_BUFSIZE 4 -long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL_BUFSIZE], ...); /** * plpar_hcall_raw: - Make a hypervisor call without calculating hcall stats @@ -467,7 +467,7 @@ long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...); * plpar_hcall, but plpar_hcall_raw works in real mode and does not * calculate hypervisor call statistics. */ -long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall_raw(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL_BUFSIZE], ...); /** * plpar_hcall9: - Make a pseries hypervisor call with up to 9 return arguments @@ -478,8 +478,8 @@ long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...); * PLPAR_HCALL9_BUFSIZE to size the return argument buffer. */ #define PLPAR_HCALL9_BUFSIZE 9 -long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...); -long plpar_hcall9_raw(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall9(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL9_BUFSIZE], ...); +long plpar_hcall9_raw(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL9_BUFSIZE], ...); struct hvcall_mpp_data { unsigned long entitled_mem; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

From: Nathan Lynch <nathanl(a)linux.ibm.com> stable inclusion from stable-v4.19.317 commit acf2b80c31c37acab040baa3cf5f19fbd5140b18 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACRHB CVE: CVE-2024-40974 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ff2e185cf73df480ec69675936c4ee75a445c3e4 ] plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes. Signed-off-by: Nathan Lynch <nathanl(a)linux.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://msgid.link/20240408-pseries-hvcall-retbuf-v1-1-ebc73d7253cf@linux.i… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Huang Xiaojia <huangxiaojia2(a)huawei.com> --- arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h index a0b17f9f1ea4..8347f57e1c6a 100644 --- a/arch/powerpc/include/asm/hvcall.h +++ b/arch/powerpc/include/asm/hvcall.h @@ -383,7 +383,7 @@ long plpar_hcall_norets(unsigned long opcode, ...); * Used for all but the craziest of phyp interfaces (see plpar_hcall9) */ #define PLPAR_HCALL_BUFSIZE 4 -long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL_BUFSIZE], ...); /** * plpar_hcall_raw: - Make a hypervisor call without calculating hcall stats @@ -397,7 +397,7 @@ long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...); * plpar_hcall, but plpar_hcall_raw works in real mode and does not * calculate hypervisor call statistics. */ -long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall_raw(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL_BUFSIZE], ...); /** * plpar_hcall9: - Make a pseries hypervisor call with up to 9 return arguments @@ -408,8 +408,8 @@ long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...); * PLPAR_HCALL9_BUFSIZE to size the return argument buffer. */ #define PLPAR_HCALL9_BUFSIZE 9 -long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...); -long plpar_hcall9_raw(unsigned long opcode, unsigned long *retbuf, ...); +long plpar_hcall9(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL9_BUFSIZE], ...); +long plpar_hcall9_raw(unsigned long opcode, unsigned long retbuf[static PLPAR_HCALL9_BUFSIZE], ...); struct hvcall_mpp_data { unsigned long entitled_mem; -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1 0/1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

*** BLURB HERE *** Nathan Lynch (1): powerpc/pseries: Enforce hcall result buffer validity and size arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6 0/1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

*** BLURB HERE *** Nathan Lynch (1): powerpc/pseries: Enforce hcall result buffer validity and size arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 2

[PATCH OLK-6.6] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
by Li Zetao 15 Jul '24

15 Jul '24

From: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> stable inclusion from stable-v6.6.33 commit 9f2ad88f9b349554f64e4037ec185c84d7dd9c7d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAC3N3 CVE: CVE-2024-39488 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f ] When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: d0ffffe0 910003fd 91000000 9400000b (d4210000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: BRK handler: Fatal exception Fix this by always aligning the end of a bug_entry to 4 bytes, which is correct regardless of CONFIG_DEBUG_BUGVERBOSE. Fixes: 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic BUG traps") Signed-off-by: Yuanbin Xie <xieyuanbin1(a)huawei.com> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Link: https://lore.kernel.org/r/1716212077-43826-1-git-send-email-xiaojiangfeng@h… Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Zetao <lizetao1(a)huawei.com> --- arch/arm64/include/asm/asm-bug.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/asm-bug.h b/arch/arm64/include/asm/asm-bug.h index c762038ba4009..6e73809f6492a 100644 --- a/arch/arm64/include/asm/asm-bug.h +++ b/arch/arm64/include/asm/asm-bug.h @@ -28,6 +28,7 @@ 14470: .long 14471f - .; \ _BUGVERBOSE_LOCATION(__FILE__, __LINE__) \ .short flags; \ + .align 2; \ .popsection; \ 14471: #else -- 2.34.1

2 1

[PATCH OLK-5.10 0/1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

*** BLURB HERE *** Nathan Lynch (1): powerpc/pseries: Enforce hcall result buffer validity and size arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
by Li Zetao 15 Jul '24

15 Jul '24

From: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> stable inclusion from stable-v5.10.219 commit 461a760d578b2b2c2faac3040b6b7c77baf128f8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAC3N3 CVE: CVE-2024-39488 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f ] When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: d0ffffe0 910003fd 91000000 9400000b (d4210000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: BRK handler: Fatal exception Fix this by always aligning the end of a bug_entry to 4 bytes, which is correct regardless of CONFIG_DEBUG_BUGVERBOSE. Fixes: 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic BUG traps") Signed-off-by: Yuanbin Xie <xieyuanbin1(a)huawei.com> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Link: https://lore.kernel.org/r/1716212077-43826-1-git-send-email-xiaojiangfeng@h… Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Zetao <lizetao1(a)huawei.com> --- arch/arm64/include/asm/asm-bug.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/asm-bug.h b/arch/arm64/include/asm/asm-bug.h index 03f52f84a4f3f..bc2dcc8a00009 100644 --- a/arch/arm64/include/asm/asm-bug.h +++ b/arch/arm64/include/asm/asm-bug.h @@ -28,6 +28,7 @@ 14470: .long 14471f - 14470b; \ _BUGVERBOSE_LOCATION(__FILE__, __LINE__) \ .short flags; \ + .align 2; \ .popsection; \ 14471: #else -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/1] powerpc/pseries: Enforce hcall result buffer validity and size
by Huang Xiaojia 15 Jul '24

15 Jul '24

*** BLURB HERE *** Nathan Lynch (1): powerpc/pseries: Enforce hcall result buffer validity and size arch/powerpc/include/asm/hvcall.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.34.1

2 2

[PATCH OLK-5.10] arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
by Li Zetao 15 Jul '24

15 Jul '24

From: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> stable inclusion from stable-v5.10.219 commit 461a760d578b2b2c2faac3040b6b7c77baf128f8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAC3N3 CVE: CVE-2024-39488 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f ] When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: d0ffffe0 910003fd 91000000 9400000b (d4210000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: BRK handler: Fatal exception Fix this by always aligning the end of a bug_entry to 4 bytes, which is correct regardless of CONFIG_DEBUG_BUGVERBOSE. Fixes: 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic BUG traps") Signed-off-by: Yuanbin Xie <xieyuanbin1(a)huawei.com> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng(a)huawei.com> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Link: https://lore.kernel.org/r/1716212077-43826-1-git-send-email-xiaojiangfeng@h… Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm64/include/asm/asm-bug.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/asm-bug.h b/arch/arm64/include/asm/asm-bug.h index 03f52f84a4f3f..bc2dcc8a00009 100644 --- a/arch/arm64/include/asm/asm-bug.h +++ b/arch/arm64/include/asm/asm-bug.h @@ -28,6 +28,7 @@ 14470: .long 14471f - 14470b; \ _BUGVERBOSE_LOCATION(__FILE__, __LINE__) \ .short flags; \ + .align 2; \ .popsection; \ 14471: #else -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS a4c425277bd22c3124be10b92316ce4a7106b5b5
by kernel test robot 14 Jul '24

14 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: a4c425277bd22c3124be10b92316ce4a7106b5b5 !9891 ipv6: sr: fix memleak in seg6_hmac_init_algo Warning ids grouped by kconfigs: recent_errors `-- x86_64-randconfig-006-20240713 `-- kernel-livepatch-core.c:warning:no-previous-prototype-for-function-klp_check_patch_kprobed elapsed time: 724m 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 gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240713 gcc-14.1.0 arm64 randconfig-002-20240713 gcc-14.1.0 arm64 randconfig-003-20240713 gcc-14.1.0 arm64 randconfig-004-20240713 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240713 clang-18 x86_64 buildonly-randconfig-002-20240713 clang-18 x86_64 buildonly-randconfig-003-20240713 gcc-13 x86_64 buildonly-randconfig-004-20240713 clang-18 x86_64 buildonly-randconfig-005-20240713 gcc-8 x86_64 buildonly-randconfig-006-20240713 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240713 clang-18 x86_64 randconfig-002-20240713 clang-18 x86_64 randconfig-003-20240713 clang-18 x86_64 randconfig-004-20240713 gcc-13 x86_64 randconfig-005-20240713 clang-18 x86_64 randconfig-006-20240713 clang-18 x86_64 randconfig-011-20240713 clang-18 x86_64 randconfig-012-20240713 clang-18 x86_64 randconfig-013-20240713 gcc-13 x86_64 randconfig-014-20240713 clang-18 x86_64 randconfig-015-20240713 gcc-13 x86_64 randconfig-016-20240713 gcc-13 x86_64 randconfig-071-20240713 gcc-8 x86_64 randconfig-072-20240713 gcc-8 x86_64 randconfig-073-20240713 clang-18 x86_64 randconfig-074-20240713 clang-18 x86_64 randconfig-075-20240713 gcc-13 x86_64 randconfig-076-20240713 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] BUILD REGRESSION 9cf1dcdc633d81337449d1de07395f43c6156124
by kernel test robot 14 Jul '24

14 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: 9cf1dcdc633d81337449d1de07395f43c6156124 !9888 ipv6: sr: fix memleak in seg6_hmac_init_algo Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag |-- loongarch-allmodconfig | `-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument |-- loongarch-randconfig-001-20240713 | |-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- loongarch-randconfig-002-20240713 | `-- include-linux-mmzone.h:error:error-Allocator-MAX_ORDER-exceeds-SECTION_SIZE `-- x86_64-allyesconfig `-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_topology.c:warning:stack-frame-size-()-exceeds-limit-()-in-kfd_topology_add_device elapsed time: 734m configs tested: 37 configs skipped: 124 tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240713 gcc-14.1.0 arm64 randconfig-002-20240713 gcc-14.1.0 arm64 randconfig-003-20240713 clang-19 arm64 randconfig-004-20240713 gcc-14.1.0 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch randconfig-001-20240713 gcc-14.1.0 loongarch randconfig-002-20240713 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240713 clang-18 x86_64 buildonly-randconfig-002-20240713 clang-18 x86_64 buildonly-randconfig-003-20240713 gcc-13 x86_64 buildonly-randconfig-004-20240713 clang-18 x86_64 buildonly-randconfig-005-20240713 gcc-8 x86_64 buildonly-randconfig-006-20240713 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240713 clang-18 x86_64 randconfig-002-20240713 clang-18 x86_64 randconfig-003-20240713 clang-18 x86_64 randconfig-004-20240713 gcc-13 x86_64 randconfig-005-20240713 clang-18 x86_64 randconfig-006-20240713 clang-18 x86_64 randconfig-011-20240713 clang-18 x86_64 randconfig-012-20240713 clang-18 x86_64 randconfig-013-20240713 gcc-13 x86_64 randconfig-014-20240713 clang-18 x86_64 randconfig-015-20240713 gcc-13 x86_64 randconfig-016-20240713 gcc-13 x86_64 randconfig-071-20240713 gcc-8 x86_64 randconfig-072-20240713 gcc-8 x86_64 randconfig-073-20240713 clang-18 x86_64 randconfig-074-20240713 clang-18 x86_64 randconfig-075-20240713 gcc-13 x86_64 rhel-8.3-rust clang-18 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] sock_map: avoid race between sock_map_close and sk_psock_put
by Liu Jian 13 Jul '24

13 Jul '24

From: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> stable inclusion from stable-v6.6.35 commit e946428439a0d2079959f5603256ac51b6047017 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQJF CVE: CVE-2024-39500 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit 4b4647add7d3c8530493f7247d11e257ee425bf0 upstream. sk_psock_get will return NULL if the refcount of psock has gone to 0, which will happen when the last call of sk_psock_put is done. However, sk_psock_drop may not have finished yet, so the close callback will still point to sock_map_close despite psock being NULL. This can be reproduced with a thread deleting an element from the sock map, while the second one creates a socket, adds it to the map and closes it. That will trigger the WARN_ON_ONCE: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Modules linked in: CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02 RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293 RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000 RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0 RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3 R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840 R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870 FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0 Call Trace: <TASK> unix_release+0x87/0xc0 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c:1556 [inline] __se_sys_close fs/open.c:1541 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb37d618070 Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070 RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Use sk_psock, which will only check that the pointer is not been set to NULL yet, which should only happen after the callbacks are restored. If, then, a reference can still be gotten, we may call sk_psock_stop and cancel psock->work. As suggested by Paolo Abeni, reorder the condition so the control flow is less convoluted. After that change, the reproducer does not trigger the WARN_ON_ONCE anymore. Suggested-by: Paolo Abeni <pabeni(a)redhat.com> Reported-by: syzbot+07a2e4a1a57118ef7355(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=07a2e4a1a57118ef7355 Fixes: aadb2bb83ff7 ("sock_map: Fix a potential use-after-free in sock_map_close()") Fixes: 5b4a79ba65a1 ("bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself") Cc: stable(a)vger.kernel.org Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> Acked-by: Jakub Sitnicki <jakub(a)cloudflare.com> Link: https://lore.kernel.org/r/20240524144702.1178377-1-cascardo@igalia.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/core/sock_map.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/net/core/sock_map.c b/net/core/sock_map.c index 27d733c0f65e..a37143d181f9 100644 --- a/net/core/sock_map.c +++ b/net/core/sock_map.c @@ -1633,19 +1633,23 @@ void sock_map_close(struct sock *sk, long timeout) lock_sock(sk); rcu_read_lock(); - psock = sk_psock_get(sk); - if (unlikely(!psock)) { - rcu_read_unlock(); - release_sock(sk); - saved_close = READ_ONCE(sk->sk_prot)->close; - } else { + psock = sk_psock(sk); + if (likely(psock)) { saved_close = psock->saved_close; sock_map_remove_links(sk, psock); + psock = sk_psock_get(sk); + if (unlikely(!psock)) + goto no_psock; rcu_read_unlock(); sk_psock_stop(psock); release_sock(sk); cancel_delayed_work_sync(&psock->work); sk_psock_put(sk, psock); + } else { + saved_close = READ_ONCE(sk->sk_prot)->close; +no_psock: + rcu_read_unlock(); + release_sock(sk); } /* Make sure we do not recurse. This is a bug. -- 2.34.1

2 1

[PATCH OLK-5.10] sock_map: avoid race between sock_map_close and sk_psock_put
by Liu Jian 13 Jul '24

13 Jul '24

From: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> mainline inclusion from mainline-v6.10-rc2 commit 4b4647add7d3c8530493f7247d11e257ee425bf0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQJF CVE: CVE-2024-39500 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- sk_psock_get will return NULL if the refcount of psock has gone to 0, which will happen when the last call of sk_psock_put is done. However, sk_psock_drop may not have finished yet, so the close callback will still point to sock_map_close despite psock being NULL. This can be reproduced with a thread deleting an element from the sock map, while the second one creates a socket, adds it to the map and closes it. That will trigger the WARN_ON_ONCE: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Modules linked in: CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02 RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293 RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000 RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0 RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3 R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840 R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870 FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0 Call Trace: <TASK> unix_release+0x87/0xc0 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c:1556 [inline] __se_sys_close fs/open.c:1541 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb37d618070 Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070 RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Use sk_psock, which will only check that the pointer is not been set to NULL yet, which should only happen after the callbacks are restored. If, then, a reference can still be gotten, we may call sk_psock_stop and cancel psock->work. As suggested by Paolo Abeni, reorder the condition so the control flow is less convoluted. After that change, the reproducer does not trigger the WARN_ON_ONCE anymore. Suggested-by: Paolo Abeni <pabeni(a)redhat.com> Reported-by: syzbot+07a2e4a1a57118ef7355(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=07a2e4a1a57118ef7355 Fixes: aadb2bb83ff7 ("sock_map: Fix a potential use-after-free in sock_map_close()") Fixes: 5b4a79ba65a1 ("bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself") Cc: stable(a)vger.kernel.org Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> Acked-by: Jakub Sitnicki <jakub(a)cloudflare.com> Link: https://lore.kernel.org/r/20240524144702.1178377-1-cascardo@igalia.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/core/sock_map.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/net/core/sock_map.c b/net/core/sock_map.c index c7900283eebb..a4d1d41883b0 100644 --- a/net/core/sock_map.c +++ b/net/core/sock_map.c @@ -1666,19 +1666,23 @@ void sock_map_close(struct sock *sk, long timeout) lock_sock(sk); rcu_read_lock(); - psock = sk_psock_get(sk); - if (unlikely(!psock)) { - rcu_read_unlock(); - release_sock(sk); - saved_close = READ_ONCE(sk->sk_prot)->close; - } else { + psock = sk_psock(sk); + if (likely(psock)) { saved_close = psock->saved_close; sock_map_remove_links(sk, psock); + psock = sk_psock_get(sk); + if (unlikely(!psock)) + goto no_psock; rcu_read_unlock(); sk_psock_stop(psock); release_sock(sk); cancel_work_sync(&psock->work); sk_psock_put(sk, psock); + } else { + saved_close = READ_ONCE(sk->sk_prot)->close; +no_psock: + rcu_read_unlock(); + release_sock(sk); } /* Make sure we do not recurse. This is a bug. * Leak the socket instead of crashing on a stack overflow. -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] sock_map: avoid race between sock_map_close and sk_psock_put
by Liu Jian 13 Jul '24

13 Jul '24

From: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> mainline inclusion from mainline-v6.10-rc2 commit 4b4647add7d3c8530493f7247d11e257ee425bf0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQJF CVE: CVE-2024-39500 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- sk_psock_get will return NULL if the refcount of psock has gone to 0, which will happen when the last call of sk_psock_put is done. However, sk_psock_drop may not have finished yet, so the close callback will still point to sock_map_close despite psock being NULL. This can be reproduced with a thread deleting an element from the sock map, while the second one creates a socket, adds it to the map and closes it. That will trigger the WARN_ON_ONCE: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Modules linked in: CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02 RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293 RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000 RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0 RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3 R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840 R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870 FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0 Call Trace: <TASK> unix_release+0x87/0xc0 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c:1556 [inline] __se_sys_close fs/open.c:1541 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb37d618070 Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070 RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Use sk_psock, which will only check that the pointer is not been set to NULL yet, which should only happen after the callbacks are restored. If, then, a reference can still be gotten, we may call sk_psock_stop and cancel psock->work. As suggested by Paolo Abeni, reorder the condition so the control flow is less convoluted. After that change, the reproducer does not trigger the WARN_ON_ONCE anymore. Suggested-by: Paolo Abeni <pabeni(a)redhat.com> Reported-by: syzbot+07a2e4a1a57118ef7355(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=07a2e4a1a57118ef7355 Fixes: aadb2bb83ff7 ("sock_map: Fix a potential use-after-free in sock_map_close()") Fixes: 5b4a79ba65a1 ("bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself") Cc: stable(a)vger.kernel.org Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> Acked-by: Jakub Sitnicki <jakub(a)cloudflare.com> Link: https://lore.kernel.org/r/20240524144702.1178377-1-cascardo@igalia.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Conflicts: net/core/sock_map.c [Did not backport 8bbabb3fddcd, 29173d07f798.] Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/core/sock_map.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/net/core/sock_map.c b/net/core/sock_map.c index 83e3ef655684..96b8b8d1dac9 100644 --- a/net/core/sock_map.c +++ b/net/core/sock_map.c @@ -1604,18 +1604,22 @@ void sock_map_close(struct sock *sk, long timeout) lock_sock(sk); rcu_read_lock(); - psock = sk_psock_get(sk); - if (unlikely(!psock)) { - rcu_read_unlock(); - release_sock(sk); - saved_close = READ_ONCE(sk->sk_prot)->close; - } else { + psock = sk_psock(sk); + if (likely(psock)) { saved_close = psock->saved_close; sock_map_remove_links(sk, psock); + psock = sk_psock_get(sk); + if (unlikely(!psock)) + goto no_psock; rcu_read_unlock(); sk_psock_stop(psock, true); sk_psock_put(sk, psock); release_sock(sk); + } else { + saved_close = READ_ONCE(sk->sk_prot)->close; +no_psock: + rcu_read_unlock(); + release_sock(sk); } /* Make sure we do not recurse. This is a bug. * Leak the socket instead of crashing on a stack overflow. -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] mptcp: ensure snd_una is properly initialized on connect
by Zhengchao Shao 13 Jul '24

13 Jul '24

From: Paolo Abeni <pabeni(a)redhat.com> mainline inclusion from mainline-v6.10-rc4 commit 8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQHR CVE: CVE-2024-40931 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snd_una is still left uninitialized. Address the issue explicitly initializing snd_una together with snd_nxt and write_seq. Suggested-by: Mat Martineau <martineau(a)kernel.org> Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect") Cc: stable(a)vger.kernel.org Reported-by: Christoph Paasch <cpaasch(a)apple.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485 Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-1-1a… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/mptcp/protocol.c [The conflict occurs because the commit 54f1944ed6d2("mptcp: factor out mptcp_connect()") and 7439d687b79c("mptcp: avoid a few atomic ops in the rx path") are not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/mptcp/protocol.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 22ed394295a7..e0fc72ab97c3 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2649,6 +2649,7 @@ static int mptcp_stream_connect(struct socket *sock, struct sockaddr *uaddr, mptcp_subflow_early_fallback(msk, subflow); WRITE_ONCE(msk->write_seq, subflow->idsn); + atomic64_set(&msk->snd_una, subflow->idsn); do_connect: err = ssock->ops->connect(ssock, uaddr, addr_len, flags); -- 2.34.1

2 1

[PATCH OLK-5.10] mptcp: ensure snd_una is properly initialized on connect
by Zhengchao Shao 13 Jul '24

13 Jul '24

From: Paolo Abeni <pabeni(a)redhat.com> mainline inclusion from mainline-v6.10-rc4 commit 8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQHR CVE: CVE-2024-40931 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snd_una is still left uninitialized. Address the issue explicitly initializing snd_una together with snd_nxt and write_seq. Suggested-by: Mat Martineau <martineau(a)kernel.org> Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect") Cc: stable(a)vger.kernel.org Reported-by: Christoph Paasch <cpaasch(a)apple.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485 Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-1-1a… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: net/mptcp/protocol.c [The conflict occurs because the commit 54f1944ed6d2("mptcp: factor out mptcp_connect()") and 7439d687b79c("mptcp: avoid a few atomic ops in the rx path") are not merged] Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/mptcp/protocol.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 613442057a04..c876f93f5b17 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -2649,6 +2649,7 @@ static int mptcp_stream_connect(struct socket *sock, struct sockaddr *uaddr, mptcp_subflow_early_fallback(msk, subflow); WRITE_ONCE(msk->write_seq, subflow->idsn); + atomic64_set(&msk->snd_una, subflow->idsn); do_connect: err = ssock->ops->connect(ssock, uaddr, addr_len, flags); -- 2.34.1

2 1

[PATCH OLK-6.6] mptcp: ensure snd_una is properly initialized on connect
by Zhengchao Shao 13 Jul '24

13 Jul '24

From: Paolo Abeni <pabeni(a)redhat.com> stable inclusion from stable-v6.6.35 commit f1f0a46f8bb8890b90ab7194f0a0c8fe2a3fb57f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQHR CVE: CVE-2024-40931 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- commit 8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 upstream. This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snd_una is still left uninitialized. Address the issue explicitly initializing snd_una together with snd_nxt and write_seq. Suggested-by: Mat Martineau <martineau(a)kernel.org> Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect") Cc: stable(a)vger.kernel.org Reported-by: Christoph Paasch <cpaasch(a)apple.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485 Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-1-1a… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/mptcp/protocol.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index cfe316ee8789..4f42bd439228 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -3708,6 +3708,7 @@ static int mptcp_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len) WRITE_ONCE(msk->write_seq, subflow->idsn); WRITE_ONCE(msk->snd_nxt, subflow->idsn); + WRITE_ONCE(msk->snd_una, subflow->idsn); if (likely(!__mptcp_check_fallback(msk))) MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPCAPABLEACTIVE); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ipv6: fix possible race in __fib6_drop_pcpu_from()
by Liu Jian 13 Jul '24

13 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.221 commit c693698787660c97950bc1f93a8dd19d8307153d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQJD CVE: CVE-2024-40905 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit b01e1c030770ff3b4fe37fc7cc6bca03f594133f ] syzbot found a race in __fib6_drop_pcpu_from() [1] If compiler reads more than once (*ppcpu_rt), second read could read NULL, if another cpu clears the value in rt6_get_pcpu_route(). Add a READ_ONCE() to prevent this race. Also add rcu_read_lock()/rcu_read_unlock() because we rely on RCU protection while dereferencing pcpu_rt. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Fixes: d52d3997f843 ("ipv6: Create percpu rt6_info") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Martin KaFai Lau <kafai(a)fb.com> Link: https://lore.kernel.org/r/20240604193549.981839-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv6/ip6_fib.c | 6 +++++- net/ipv6/route.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c index cac2de1d1d5c..ba4087fb0368 100644 --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -960,6 +960,7 @@ static void __fib6_drop_pcpu_from(struct fib6_nh *fib6_nh, if (!fib6_nh->rt6i_pcpu) return; + rcu_read_lock(); /* release the reference to this fib entry from * all of its cached pcpu routes */ @@ -968,7 +969,9 @@ static void __fib6_drop_pcpu_from(struct fib6_nh *fib6_nh, struct rt6_info *pcpu_rt; ppcpu_rt = per_cpu_ptr(fib6_nh->rt6i_pcpu, cpu); - pcpu_rt = *ppcpu_rt; + + /* Paired with xchg() in rt6_get_pcpu_route() */ + pcpu_rt = READ_ONCE(*ppcpu_rt); /* only dropping the 'from' reference if the cached route * is using 'match'. The cached pcpu_rt->from only changes @@ -982,6 +985,7 @@ static void __fib6_drop_pcpu_from(struct fib6_nh *fib6_nh, fib6_info_release(from); } } + rcu_read_unlock(); } struct fib6_nh_pcpu_arg { diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 59bd6f57357f..ab270e2a3708 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -1391,6 +1391,7 @@ static struct rt6_info *rt6_get_pcpu_route(const struct fib6_result *res) struct rt6_info *prev, **p; p = this_cpu_ptr(res->nh->rt6i_pcpu); + /* Paired with READ_ONCE() in __fib6_drop_pcpu_from() */ prev = xchg(p, NULL); if (prev) { dst_dev_put(&prev->dst); -- 2.34.1

2 1

[PATCH OLK-5.10] ipv6: fix possible race in __fib6_drop_pcpu_from()
by Liu Jian 13 Jul '24

13 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.221 commit c693698787660c97950bc1f93a8dd19d8307153d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQJD CVE: CVE-2024-40905 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit b01e1c030770ff3b4fe37fc7cc6bca03f594133f ] syzbot found a race in __fib6_drop_pcpu_from() [1] If compiler reads more than once (*ppcpu_rt), second read could read NULL, if another cpu clears the value in rt6_get_pcpu_route(). Add a READ_ONCE() to prevent this race. Also add rcu_read_lock()/rcu_read_unlock() because we rely on RCU protection while dereferencing pcpu_rt. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Fixes: d52d3997f843 ("ipv6: Create percpu rt6_info") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Martin KaFai Lau <kafai(a)fb.com> Link: https://lore.kernel.org/r/20240604193549.981839-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv6/ip6_fib.c | 6 +++++- net/ipv6/route.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c index 23881e5ebb3d..7883bdb5171f 100644 --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -960,6 +960,7 @@ static void __fib6_drop_pcpu_from(struct fib6_nh *fib6_nh, if (!fib6_nh->rt6i_pcpu) return; + rcu_read_lock(); /* release the reference to this fib entry from * all of its cached pcpu routes */ @@ -968,7 +969,9 @@ static void __fib6_drop_pcpu_from(struct fib6_nh *fib6_nh, struct rt6_info *pcpu_rt; ppcpu_rt = per_cpu_ptr(fib6_nh->rt6i_pcpu, cpu); - pcpu_rt = *ppcpu_rt; + + /* Paired with xchg() in rt6_get_pcpu_route() */ + pcpu_rt = READ_ONCE(*ppcpu_rt); /* only dropping the 'from' reference if the cached route * is using 'match'. The cached pcpu_rt->from only changes @@ -982,6 +985,7 @@ static void __fib6_drop_pcpu_from(struct fib6_nh *fib6_nh, fib6_info_release(from); } } + rcu_read_unlock(); } struct fib6_nh_pcpu_arg { diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 96b3ddafb8d1..ff2b9f763b10 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -1391,6 +1391,7 @@ static struct rt6_info *rt6_get_pcpu_route(const struct fib6_result *res) struct rt6_info *prev, **p; p = this_cpu_ptr(res->nh->rt6i_pcpu); + /* Paired with READ_ONCE() in __fib6_drop_pcpu_from() */ prev = xchg(p, NULL); if (prev) { dst_dev_put(&prev->dst); -- 2.34.1

2 1

[PATCH OLK-6.6] ipv6: fix possible race in __fib6_drop_pcpu_from()
by Liu Jian 13 Jul '24

13 Jul '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v6.6.35 commit 7e796c3fefa8b17b30e7252886ae8cffacd2b9ef category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQJD CVE: CVE-2024-40905 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit b01e1c030770ff3b4fe37fc7cc6bca03f594133f ] syzbot found a race in __fib6_drop_pcpu_from() [1] If compiler reads more than once (*ppcpu_rt), second read could read NULL, if another cpu clears the value in rt6_get_pcpu_route(). Add a READ_ONCE() to prevent this race. Also add rcu_read_lock()/rcu_read_unlock() because we rely on RCU protection while dereferencing pcpu_rt. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Fixes: d52d3997f843 ("ipv6: Create percpu rt6_info") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Martin KaFai Lau <kafai(a)fb.com> Link: https://lore.kernel.org/r/20240604193549.981839-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- net/ipv6/ip6_fib.c | 6 +++++- net/ipv6/route.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c index 8184076a3924..4356806b52bd 100644 --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -961,6 +961,7 @@ static void __fib6_drop_pcpu_from(struct fib6_nh *fib6_nh, if (!fib6_nh->rt6i_pcpu) return; + rcu_read_lock(); /* release the reference to this fib entry from * all of its cached pcpu routes */ @@ -969,7 +970,9 @@ static void __fib6_drop_pcpu_from(struct fib6_nh *fib6_nh, struct rt6_info *pcpu_rt; ppcpu_rt = per_cpu_ptr(fib6_nh->rt6i_pcpu, cpu); - pcpu_rt = *ppcpu_rt; + + /* Paired with xchg() in rt6_get_pcpu_route() */ + pcpu_rt = READ_ONCE(*ppcpu_rt); /* only dropping the 'from' reference if the cached route * is using 'match'. The cached pcpu_rt->from only changes @@ -983,6 +986,7 @@ static void __fib6_drop_pcpu_from(struct fib6_nh *fib6_nh, fib6_info_release(from); } } + rcu_read_unlock(); } struct fib6_nh_pcpu_arg { diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 236a45557ba1..8cccc6a2b404 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -1398,6 +1398,7 @@ static struct rt6_info *rt6_get_pcpu_route(const struct fib6_result *res) struct rt6_info *prev, **p; p = this_cpu_ptr(res->nh->rt6i_pcpu); + /* Paired with READ_ONCE() in __fib6_drop_pcpu_from() */ prev = xchg(p, NULL); if (prev) { dst_dev_put(&prev->dst); -- 2.34.1

2 1

[PATCH OLK-6.6] ionic: fix use after netif_napi_del()
by Zhengchao Shao 13 Jul '24

13 Jul '24

From: Taehee Yoo <ap420073(a)gmail.com> stable inclusion from stable-v6.6.35 commit 183ebc167a8a19e916b885d4bb61a3491991bfa5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQHS CVE: CVE-2024-39502 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit 79f18a41dd056115d685f3b0a419c7cd40055e13 ] When queues are started, netif_napi_add() and napi_enable() are called. If there are 4 queues and only 3 queues are used for the current configuration, only 3 queues' napi should be registered and enabled. The ionic_qcq_enable() checks whether the .poll pointer is not NULL for enabling only the using queue' napi. Unused queues' napi will not be registered by netif_napi_add(), so the .poll pointer indicates NULL. But it couldn't distinguish whether the napi was unregistered or not because netif_napi_del() doesn't reset the .poll pointer to NULL. So, ionic_qcq_enable() calls napi_enable() for the queue, which was unregistered by netif_napi_del(). Reproducer: ethtool -L <interface name> rx 1 tx 1 combined 0 ethtool -L <interface name> rx 0 tx 0 combined 1 ethtool -L <interface name> rx 0 tx 0 combined 4 Splat looks like: kernel BUG at net/core/dev.c:6666! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16 Workqueue: events ionic_lif_deferred_work [ionic] RIP: 0010:napi_enable+0x3b/0x40 Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? die+0x33/0x90 ? do_trap+0xd9/0x100 ? napi_enable+0x3b/0x40 ? do_error_trap+0x83/0xb0 ? napi_enable+0x3b/0x40 ? napi_enable+0x3b/0x40 ? exc_invalid_op+0x4e/0x70 ? napi_enable+0x3b/0x40 ? asm_exc_invalid_op+0x16/0x20 ? napi_enable+0x3b/0x40 ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] process_one_work+0x145/0x360 worker_thread+0x2bb/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Reviewed-by: Brett Creeley <brett.creeley(a)amd.com> Reviewed-by: Shannon Nelson <shannon.nelson(a)amd.com> Link: https://lore.kernel.org/r/20240612060446.1754392-1-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/pensando/ionic/ionic_lif.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.c b/drivers/net/ethernet/pensando/ionic/ionic_lif.c index 4f05cddc65cb..7e6e1bed525a 100644 --- a/drivers/net/ethernet/pensando/ionic/ionic_lif.c +++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.c @@ -296,10 +296,8 @@ static int ionic_qcq_enable(struct ionic_qcq *qcq) if (ret) return ret; - if (qcq->napi.poll) - napi_enable(&qcq->napi); - if (qcq->flags & IONIC_QCQ_F_INTR) { + napi_enable(&qcq->napi); irq_set_affinity_hint(qcq->intr.vector, &qcq->intr.affinity_mask); ionic_intr_mask(idev->intr_ctrl, qcq->intr.index, -- 2.34.1

2 1

[PATCH OLK-6.6] cpufreq: amd-pstate: fix memory leak on CPU EPP exit
by Jinjie Ruan 13 Jul '24

13 Jul '24

From: Peng Ma <andypma(a)tencent.com> stable inclusion from stable-v6.6.36 commit 448efb7ea0bfa2c4e27c5a2eb5684fd225cd12cd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQP5 CVE: CVE-2024-40997 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit cea04f3d9aeebda9d9c063c0dfa71e739c322c81 ] The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is not freed in the analogous exit function, so fix that. Signed-off-by: Peng Ma <andypma(a)tencent.com> Acked-by: Mario Limonciello <mario.limonciello(a)amd.com> Reviewed-by: Perry Yuan <Perry.Yuan(a)amd.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- drivers/cpufreq/amd-pstate.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c index 07f341995439..3efc2aef31ce 100644 --- a/drivers/cpufreq/amd-pstate.c +++ b/drivers/cpufreq/amd-pstate.c @@ -1216,6 +1216,13 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy) static int amd_pstate_epp_cpu_exit(struct cpufreq_policy *policy) { + struct amd_cpudata *cpudata = policy->driver_data; + + if (cpudata) { + kfree(cpudata); + policy->driver_data = NULL; + } + pr_debug("CPU %d exiting\n", policy->cpu); return 0; } -- 2.34.1

2 1

[PATCH OLK-5.10] ionic: fix use after netif_napi_del()
by Zhengchao Shao 13 Jul '24

13 Jul '24

From: Taehee Yoo <ap420073(a)gmail.com> mainline inclusion from mainline-v6.10-rc4 commit 79f18a41dd056115d685f3b0a419c7cd40055e13 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACQHS CVE: CVE-2024-39502 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When queues are started, netif_napi_add() and napi_enable() are called. If there are 4 queues and only 3 queues are used for the current configuration, only 3 queues' napi should be registered and enabled. The ionic_qcq_enable() checks whether the .poll pointer is not NULL for enabling only the using queue' napi. Unused queues' napi will not be registered by netif_napi_add(), so the .poll pointer indicates NULL. But it couldn't distinguish whether the napi was unregistered or not because netif_napi_del() doesn't reset the .poll pointer to NULL. So, ionic_qcq_enable() calls napi_enable() for the queue, which was unregistered by netif_napi_del(). Reproducer: ethtool -L <interface name> rx 1 tx 1 combined 0 ethtool -L <interface name> rx 0 tx 0 combined 1 ethtool -L <interface name> rx 0 tx 0 combined 4 Splat looks like: kernel BUG at net/core/dev.c:6666! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16 Workqueue: events ionic_lif_deferred_work [ionic] RIP: 0010:napi_enable+0x3b/0x40 Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? die+0x33/0x90 ? do_trap+0xd9/0x100 ? napi_enable+0x3b/0x40 ? do_error_trap+0x83/0xb0 ? napi_enable+0x3b/0x40 ? napi_enable+0x3b/0x40 ? exc_invalid_op+0x4e/0x70 ? napi_enable+0x3b/0x40 ? asm_exc_invalid_op+0x16/0x20 ? napi_enable+0x3b/0x40 ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] process_one_work+0x145/0x360 worker_thread+0x2bb/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Reviewed-by: Brett Creeley <brett.creeley(a)amd.com> Reviewed-by: Shannon Nelson <shannon.nelson(a)amd.com> Link: https://lore.kernel.org/r/20240612060446.1754392-1-ap420073@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/pensando/ionic/ionic_lif.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.c b/drivers/net/ethernet/pensando/ionic/ionic_lif.c index 49c28134ac2c..d507b4448a51 100644 --- a/drivers/net/ethernet/pensando/ionic/ionic_lif.c +++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.c @@ -272,10 +272,8 @@ static int ionic_qcq_enable(struct ionic_qcq *qcq) if (ret) return ret; - if (qcq->napi.poll) - napi_enable(&qcq->napi); - if (qcq->flags & IONIC_QCQ_F_INTR) { + napi_enable(&qcq->napi); irq_set_affinity_hint(qcq->intr.vector, &qcq->intr.affinity_mask); ionic_intr_mask(idev->intr_ctrl, qcq->intr.index, -- 2.34.1

2 1

[PATCH OLK-6.6] bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
by Liu Jian 13 Jul '24

13 Jul '24

From: Sam Sun <samsun1006219(a)gmail.com> stable inclusion from stable-v6.6.39 commit b75e33eae8667084bd4a63e67657c6a5a0f8d1e8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IABSW1 CVE: CVE-2024-39487 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit e271ff53807e8f2c628758290f0e499dbe51cb3d ] In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it. Fixes: f9de11a16594 ("bonding: add ip checks when store ip target") Signed-off-by: Yue Sun <samsun1006219(a)gmail.com> Signed-off-by: Simon Horman <horms(a)kernel.org> Acked-by: Jay Vosburgh <jay.vosburgh(a)canonical.com> Reviewed-by: Hangbin Liu <liuhangbin(a)gmail.com> Link: https://patch.msgid.link/20240702-bond-oob-v6-1-2dfdba195c19@kernel.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/bonding/bond_options.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c index f3f27f0bd2a6..00a662f8edd6 100644 --- a/drivers/net/bonding/bond_options.c +++ b/drivers/net/bonding/bond_options.c @@ -1198,9 +1198,9 @@ static int bond_option_arp_ip_targets_set(struct bonding *bond, __be32 target; if (newval->string) { - if (!in4_pton(newval->string+1, -1, (u8 *)&target, -1, NULL)) { - netdev_err(bond->dev, "invalid ARP target %pI4 specified\n", - &target); + if (strlen(newval->string) < 1 || + !in4_pton(newval->string + 1, -1, (u8 *)&target, -1, NULL)) { + netdev_err(bond->dev, "invalid ARP target specified\n"); return ret; } if (newval->string[0] == '+') -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
by Liu Jian 13 Jul '24

13 Jul '24

From: Sam Sun <samsun1006219(a)gmail.com> mainline inclusion from mainline-v6.10-rc7 commit e271ff53807e8f2c628758290f0e499dbe51cb3d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IABSW1 CVE: CVE-2024-39487 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it. Fixes: f9de11a16594 ("bonding: add ip checks when store ip target") Signed-off-by: Yue Sun <samsun1006219(a)gmail.com> Signed-off-by: Simon Horman <horms(a)kernel.org> Acked-by: Jay Vosburgh <jay.vosburgh(a)canonical.com> Reviewed-by: Hangbin Liu <liuhangbin(a)gmail.com> Link: https://patch.msgid.link/20240702-bond-oob-v6-1-2dfdba195c19@kernel.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/bonding/bond_options.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c index 1745cba04c18..8f44f80a8781 100644 --- a/drivers/net/bonding/bond_options.c +++ b/drivers/net/bonding/bond_options.c @@ -1093,9 +1093,9 @@ static int bond_option_arp_ip_targets_set(struct bonding *bond, __be32 target; if (newval->string) { - if (!in4_pton(newval->string+1, -1, (u8 *)&target, -1, NULL)) { - netdev_err(bond->dev, "invalid ARP target %pI4 specified\n", - &target); + if (strlen(newval->string) < 1 || + !in4_pton(newval->string + 1, -1, (u8 *)&target, -1, NULL)) { + netdev_err(bond->dev, "invalid ARP target specified\n"); return ret; } if (newval->string[0] == '+') -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
by Liu Jian 13 Jul '24

13 Jul '24

From: Sam Sun <samsun1006219(a)gmail.com> mainline inclusion from mainline-v6.10-rc7 commit e271ff53807e8f2c628758290f0e499dbe51cb3d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IABSW1 CVE: CVE-2024-39487 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it. Fixes: f9de11a16594 ("bonding: add ip checks when store ip target") Signed-off-by: Yue Sun <samsun1006219(a)gmail.com> Signed-off-by: Simon Horman <horms(a)kernel.org> Acked-by: Jay Vosburgh <jay.vosburgh(a)canonical.com> Reviewed-by: Hangbin Liu <liuhangbin(a)gmail.com> Link: https://patch.msgid.link/20240702-bond-oob-v6-1-2dfdba195c19@kernel.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/bonding/bond_options.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c index fe55c81608da..fa0bf77870d4 100644 --- a/drivers/net/bonding/bond_options.c +++ b/drivers/net/bonding/bond_options.c @@ -1100,9 +1100,9 @@ static int bond_option_arp_ip_targets_set(struct bonding *bond, __be32 target; if (newval->string) { - if (!in4_pton(newval->string+1, -1, (u8 *)&target, -1, NULL)) { - netdev_err(bond->dev, "invalid ARP target %pI4 specified\n", - &target); + if (strlen(newval->string) < 1 || + !in4_pton(newval->string + 1, -1, (u8 *)&target, -1, NULL)) { + netdev_err(bond->dev, "invalid ARP target specified\n"); return ret; } if (newval->string[0] == '+') -- 2.34.1

2 1

[PATCH OLK-5.10] bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
by Liu Jian 13 Jul '24

13 Jul '24

From: Sam Sun <samsun1006219(a)gmail.com> mainline inclusion from mainline-v6.10-rc7 commit e271ff53807e8f2c628758290f0e499dbe51cb3d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IABSW1 CVE: CVE-2024-39487 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it. Fixes: f9de11a16594 ("bonding: add ip checks when store ip target") Signed-off-by: Yue Sun <samsun1006219(a)gmail.com> Signed-off-by: Simon Horman <horms(a)kernel.org> Acked-by: Jay Vosburgh <jay.vosburgh(a)canonical.com> Reviewed-by: Hangbin Liu <liuhangbin(a)gmail.com> Link: https://patch.msgid.link/20240702-bond-oob-v6-1-2dfdba195c19@kernel.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/bonding/bond_options.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c index fe55c81608da..fa0bf77870d4 100644 --- a/drivers/net/bonding/bond_options.c +++ b/drivers/net/bonding/bond_options.c @@ -1100,9 +1100,9 @@ static int bond_option_arp_ip_targets_set(struct bonding *bond, __be32 target; if (newval->string) { - if (!in4_pton(newval->string+1, -1, (u8 *)&target, -1, NULL)) { - netdev_err(bond->dev, "invalid ARP target %pI4 specified\n", - &target); + if (strlen(newval->string) < 1 || + !in4_pton(newval->string + 1, -1, (u8 *)&target, -1, NULL)) { + netdev_err(bond->dev, "invalid ARP target specified\n"); return ret; } if (newval->string[0] == '+') -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 16562/23271] mm/pin_mem.c:1075:12: sparse: sparse: symbol 'reserve_idr' was not declared. Should it be static?
by kernel test robot 13 Jul '24

13 Jul '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 07c988f00903b4f0fbf9c31cea24351fbf885b1c commit: 892de178c180d2924ad5f3dcf55baa3b8ab2272d [16562/23271] pid: add pid reserve method for checkpoint and restore config: arm64-randconfig-r112-20240713 (https://download.01.org/0day-ci/archive/20240713/202407131157.Vwc7D5kC-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce: (https://download.01.org/0day-ci/archive/20240713/202407131157.Vwc7D5kC-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/202407131157.Vwc7D5kC-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) mm/pin_mem.c:34:14: sparse: sparse: symbol 'max_pin_pid_num' was not declared. Should it be static? mm/pin_mem.c:35:15: sparse: sparse: symbol 'redirect_space_size' was not declared. Should it be static? mm/pin_mem.c:171:6: sparse: sparse: symbol 'reserve_page_from_buddy' was not declared. Should it be static? mm/pin_mem.c:254:6: sparse: sparse: symbol 'free_user_map_pages' was not declared. Should it be static? mm/pin_mem.c:311:6: sparse: sparse: symbol 'check_redirect_end_valid' was not declared. Should it be static? mm/pin_mem.c:392:5: sparse: sparse: symbol 'calculate_pin_mem_digest' was not declared. Should it be static? mm/pin_mem.c:481:5: sparse: sparse: symbol 'collect_pmd_huge_pages' was not declared. Should it be static? mm/pin_mem.c:544:5: sparse: sparse: symbol 'collect_normal_pages' was not declared. Should it be static? mm/pin_mem.c:610:6: sparse: sparse: symbol 'free_pin_pages' was not declared. Should it be static? mm/pin_mem.c:770:12: sparse: sparse: symbol 'remap_normal_pages' was not declared. Should it be static? mm/pin_mem.c:857:12: sparse: sparse: symbol 'remap_huge_pmd_pages' was not declared. Should it be static? >> mm/pin_mem.c:1075:12: sparse: sparse: symbol 'reserve_idr' was not declared. Should it be static? mm/pin_mem.c:844:63: sparse: sparse: not addressable mm/pin_mem.c:846:63: sparse: sparse: not addressable mm/pin_mem.c:848:71: sparse: sparse: not addressable mm/pin_mem.c:851:65: sparse: sparse: not addressable mm/pin_mem.c:171:6: warning: no previous prototype for 'reserve_page_from_buddy' [-Wmissing-prototypes] 171 | void reserve_page_from_buddy(unsigned long nr_pages, struct page *page) | ^~~~~~~~~~~~~~~~~~~~~~~ mm/pin_mem.c:254:6: warning: no previous prototype for 'free_user_map_pages' [-Wmissing-prototypes] 254 | void free_user_map_pages(unsigned int pid_index, unsigned int entry_index, unsigned int page_index) | ^~~~~~~~~~~~~~~~~~~ mm/pin_mem.c:311:6: warning: no previous prototype for 'check_redirect_end_valid' [-Wmissing-prototypes] 311 | bool check_redirect_end_valid(struct redirect_info *redirect_start, | ^~~~~~~~~~~~~~~~~~~~~~~~ mm/pin_mem.c:392:5: warning: no previous prototype for 'calculate_pin_mem_digest' [-Wmissing-prototypes] 392 | int calculate_pin_mem_digest(struct pin_mem_dump_info *pmdi, char *digest) | ^~~~~~~~~~~~~~~~~~~~~~~~ mm/pin_mem.c:481:5: warning: no previous prototype for 'collect_pmd_huge_pages' [-Wmissing-prototypes] 481 | int collect_pmd_huge_pages(struct task_struct *task, | ^~~~~~~~~~~~~~~~~~~~~~ mm/pin_mem.c:544:5: warning: no previous prototype for 'collect_normal_pages' [-Wmissing-prototypes] 544 | int collect_normal_pages(struct task_struct *task, | ^~~~~~~~~~~~~~~~~~~~ mm/pin_mem.c: In function 'collect_normal_pages': mm/pin_mem.c:549:26: warning: variable 'nr_pages' set but not used [-Wunused-but-set-variable] 549 | unsigned long i, nr_pages; | ^~~~~~~~ mm/pin_mem.c: At top level: mm/pin_mem.c:610:6: warning: no previous prototype for 'free_pin_pages' [-Wmissing-prototypes] 610 | void free_pin_pages(struct page_map_entry *pme) | ^~~~~~~~~~~~~~ mm/pin_mem.c:770:12: warning: no previous prototype for 'remap_normal_pages' [-Wmissing-prototypes] 770 | vm_fault_t remap_normal_pages(struct mm_struct *mm, struct vm_area_struct *vma, | ^~~~~~~~~~~~~~~~~~ mm/pin_mem.c: In function 'get_hugepage_gfpmask': mm/pin_mem.c:844:63: error: lvalue required as unary '&' operand 844 | if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG, &transparent_hugepage_flags)) | ^ mm/pin_mem.c:846:63: error: lvalue required as unary '&' operand 846 | if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_FLAG, &transparent_hugepage_flags)) | ^ mm/pin_mem.c:848:71: error: lvalue required as unary '&' operand 848 | if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG, &transparent_hugepage_flags)) | ^ mm/pin_mem.c:851:65: error: lvalue required as unary '&' operand 851 | if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG, &transparent_hugepage_flags)) | ^ mm/pin_mem.c: At top level: mm/pin_mem.c:857:12: warning: no previous prototype for 'remap_huge_pmd_pages' [-Wmissing-prototypes] 857 | vm_fault_t remap_huge_pmd_pages(struct mm_struct *mm, struct vm_area_struct *vma, | ^~~~~~~~~~~~~~~~~~~~ vim +/reserve_idr +1075 mm/pin_mem.c 1073 1074 #ifdef CONFIG_PID_RESERVE > 1075 struct idr *reserve_idr; 1076 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6 00/23] support for SMC-D loopback_lo feature
by Zhengchao Shao 13 Jul '24

13 Jul '24

Support for SMC-D loopback_lo feature. Wen Gu (22): net/smc: rename some 'fce' to 'fce_v2x' for clarity net/smc: introduce sub-functions for smc_clc_send_confirm_accept() net/smc: unify the structs of accept or confirm message for v1 and v2 net/smc: support SMCv2.x supplemental features negotiation net/smc: introduce virtual ISM device support feature net/smc: define a reserved CHID range for virtual ISM devices net/smc: compatible with 128-bits extended GID of virtual ISM device net/smc: support extended GID in SMC-D lgr netlink attribute net/smc: manage system EID in SMC stack instead of ISM driver net/smc: fix incorrect SMC-D link group matching logic net/smc: change the term virtual ISM to Emulated-ISM net/smc: decouple ism_client from SMC-D DMB registration net/smc: introduce loopback-ism for SMC intra-OS shortcut net/smc: implement ID-related operations of loopback-ism net/smc: implement DMB-related operations of loopback-ism net/smc: mark optional smcd_ops and check for support when called net/smc: ignore loopback-ism when dumping SMC-D devices net/smc: register loopback-ism into SMC-D device list net/smc: add operations to merge sndbuf with peer DMB net/smc: {at|de}tach sndbuf to peer DMB if supported net/smc: adapt cursor update when sndbuf and peer DMB are merged net/smc: implement DMB-merged operations of loopback-ism Zhengchao Shao (1): net/smc: enable the smc-lo on the x86 and arm64 platforms arch/arm64/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + drivers/s390/net/ism.h | 7 - drivers/s390/net/ism_drv.c | 59 ++-- include/linux/ism.h | 1 - include/net/smc.h | 33 +- include/uapi/linux/smc.h | 2 + include/uapi/linux/smc_diag.h | 2 + net/smc/Kconfig | 13 + net/smc/Makefile | 1 + net/smc/af_smc.c | 146 ++++++--- net/smc/smc.h | 10 +- net/smc/smc_cdc.c | 36 ++- net/smc/smc_clc.c | 304 ++++++++++-------- net/smc/smc_clc.h | 64 ++-- net/smc/smc_core.c | 104 +++++- net/smc/smc_core.h | 19 +- net/smc/smc_diag.c | 9 +- net/smc/smc_ism.c | 136 ++++++-- net/smc/smc_ism.h | 40 ++- net/smc/smc_loopback.c | 427 +++++++++++++++++++++++++ net/smc/smc_loopback.h | 61 ++++ net/smc/smc_pnet.c | 4 +- 23 files changed, 1160 insertions(+), 320 deletions(-) create mode 100644 net/smc/smc_loopback.c create mode 100644 net/smc/smc_loopback.h -- 2.34.1

2 24

[PATCH openEuler-1.0-LTS] ipv6: sr: fix memleak in seg6_hmac_init_algo
by Zhengchao Shao 13 Jul '24

13 Jul '24

From: Hangbin Liu <liuhangbin(a)gmail.com> stable inclusion from stable-v4.19.316 commit afd5730969aec960a2fee4e5ee839a6014643976 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAC3N0 CVE: CVE-2024-39489 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit efb9f4f19f8e37fde43dfecebc80292d179f56c6 ] seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms. Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly. Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Reported-by: Sabrina Dubroca <sd(a)queasysnail.net> Closes: https://lore.kernel.org/netdev/Zj3bh-gE7eT6V6aH@hog/ Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Link: https://lore.kernel.org/r/20240517005435.2600277-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/seg6_hmac.c | 42 ++++++++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 14 deletions(-) diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c index 8546f94f30d4..a8f0eac64a19 100644 --- a/net/ipv6/seg6_hmac.c +++ b/net/ipv6/seg6_hmac.c @@ -361,6 +361,7 @@ static int seg6_hmac_init_algo(void) struct crypto_shash *tfm; struct shash_desc *shash; int i, alg_count, cpu; + int ret = -ENOMEM; alg_count = ARRAY_SIZE(hmac_algos); @@ -371,12 +372,14 @@ static int seg6_hmac_init_algo(void) algo = &hmac_algos[i]; algo->tfms = alloc_percpu(struct crypto_shash *); if (!algo->tfms) - return -ENOMEM; + goto error_out; for_each_possible_cpu(cpu) { tfm = crypto_alloc_shash(algo->name, 0, 0); - if (IS_ERR(tfm)) - return PTR_ERR(tfm); + if (IS_ERR(tfm)) { + ret = PTR_ERR(tfm); + goto error_out; + } p_tfm = per_cpu_ptr(algo->tfms, cpu); *p_tfm = tfm; } @@ -388,18 +391,22 @@ static int seg6_hmac_init_algo(void) algo->shashs = alloc_percpu(struct shash_desc *); if (!algo->shashs) - return -ENOMEM; + goto error_out; for_each_possible_cpu(cpu) { shash = kzalloc_node(shsize, GFP_KERNEL, cpu_to_node(cpu)); if (!shash) - return -ENOMEM; + goto error_out; *per_cpu_ptr(algo->shashs, cpu) = shash; } } return 0; + +error_out: + seg6_hmac_exit(); + return ret; } int __init seg6_hmac_init(void) @@ -421,22 +428,29 @@ EXPORT_SYMBOL(seg6_hmac_net_init); void seg6_hmac_exit(void) { struct seg6_hmac_algo *algo = NULL; + struct crypto_shash *tfm; + struct shash_desc *shash; int i, alg_count, cpu; alg_count = ARRAY_SIZE(hmac_algos); for (i = 0; i < alg_count; i++) { algo = &hmac_algos[i]; - for_each_possible_cpu(cpu) { - struct crypto_shash *tfm; - struct shash_desc *shash; - shash = *per_cpu_ptr(algo->shashs, cpu); - kfree(shash); - tfm = *per_cpu_ptr(algo->tfms, cpu); - crypto_free_shash(tfm); + if (algo->shashs) { + for_each_possible_cpu(cpu) { + shash = *per_cpu_ptr(algo->shashs, cpu); + kfree(shash); + } + free_percpu(algo->shashs); + } + + if (algo->tfms) { + for_each_possible_cpu(cpu) { + tfm = *per_cpu_ptr(algo->tfms, cpu); + crypto_free_shash(tfm); + } + free_percpu(algo->tfms); } - free_percpu(algo->tfms); - free_percpu(algo->shashs); } } EXPORT_SYMBOL(seg6_hmac_exit); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ipv6: sr: fix memleak in seg6_hmac_init_algo
by Zhengchao Shao 13 Jul '24

13 Jul '24

From: Hangbin Liu <liuhangbin(a)gmail.com> stable inclusion from stable-v5.10.219 commit daf341e0a2318b813427d5a78788c86f4a7f02be category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAC3N0 CVE: CVE-2024-39489 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit efb9f4f19f8e37fde43dfecebc80292d179f56c6 ] seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms. Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly. Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Reported-by: Sabrina Dubroca <sd(a)queasysnail.net> Closes: https://lore.kernel.org/netdev/Zj3bh-gE7eT6V6aH@hog/ Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Link: https://lore.kernel.org/r/20240517005435.2600277-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/seg6_hmac.c | 42 ++++++++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 14 deletions(-) diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c index d43c50a7310d..3c3800223e0e 100644 --- a/net/ipv6/seg6_hmac.c +++ b/net/ipv6/seg6_hmac.c @@ -354,6 +354,7 @@ static int seg6_hmac_init_algo(void) struct crypto_shash *tfm; struct shash_desc *shash; int i, alg_count, cpu; + int ret = -ENOMEM; alg_count = ARRAY_SIZE(hmac_algos); @@ -364,12 +365,14 @@ static int seg6_hmac_init_algo(void) algo = &hmac_algos[i]; algo->tfms = alloc_percpu(struct crypto_shash *); if (!algo->tfms) - return -ENOMEM; + goto error_out; for_each_possible_cpu(cpu) { tfm = crypto_alloc_shash(algo->name, 0, 0); - if (IS_ERR(tfm)) - return PTR_ERR(tfm); + if (IS_ERR(tfm)) { + ret = PTR_ERR(tfm); + goto error_out; + } p_tfm = per_cpu_ptr(algo->tfms, cpu); *p_tfm = tfm; } @@ -381,18 +384,22 @@ static int seg6_hmac_init_algo(void) algo->shashs = alloc_percpu(struct shash_desc *); if (!algo->shashs) - return -ENOMEM; + goto error_out; for_each_possible_cpu(cpu) { shash = kzalloc_node(shsize, GFP_KERNEL, cpu_to_node(cpu)); if (!shash) - return -ENOMEM; + goto error_out; *per_cpu_ptr(algo->shashs, cpu) = shash; } } return 0; + +error_out: + seg6_hmac_exit(); + return ret; } int __init seg6_hmac_init(void) @@ -410,22 +417,29 @@ int __net_init seg6_hmac_net_init(struct net *net) void seg6_hmac_exit(void) { struct seg6_hmac_algo *algo = NULL; + struct crypto_shash *tfm; + struct shash_desc *shash; int i, alg_count, cpu; alg_count = ARRAY_SIZE(hmac_algos); for (i = 0; i < alg_count; i++) { algo = &hmac_algos[i]; - for_each_possible_cpu(cpu) { - struct crypto_shash *tfm; - struct shash_desc *shash; - shash = *per_cpu_ptr(algo->shashs, cpu); - kfree(shash); - tfm = *per_cpu_ptr(algo->tfms, cpu); - crypto_free_shash(tfm); + if (algo->shashs) { + for_each_possible_cpu(cpu) { + shash = *per_cpu_ptr(algo->shashs, cpu); + kfree(shash); + } + free_percpu(algo->shashs); + } + + if (algo->tfms) { + for_each_possible_cpu(cpu) { + tfm = *per_cpu_ptr(algo->tfms, cpu); + crypto_free_shash(tfm); + } + free_percpu(algo->tfms); } - free_percpu(algo->tfms); - free_percpu(algo->shashs); } } EXPORT_SYMBOL(seg6_hmac_exit); -- 2.34.1

2 1

[PATCH OLK-5.10] ipv6: sr: fix memleak in seg6_hmac_init_algo
by Zhengchao Shao 13 Jul '24

13 Jul '24

From: Hangbin Liu <liuhangbin(a)gmail.com> stable inclusion from stable-v5.10.219 commit daf341e0a2318b813427d5a78788c86f4a7f02be category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAC3N0 CVE: CVE-2024-39489 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit efb9f4f19f8e37fde43dfecebc80292d179f56c6 ] seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms. Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly. Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Reported-by: Sabrina Dubroca <sd(a)queasysnail.net> Closes: https://lore.kernel.org/netdev/Zj3bh-gE7eT6V6aH@hog/ Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Link: https://lore.kernel.org/r/20240517005435.2600277-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/seg6_hmac.c | 42 ++++++++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 14 deletions(-) diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c index d43c50a7310d..3c3800223e0e 100644 --- a/net/ipv6/seg6_hmac.c +++ b/net/ipv6/seg6_hmac.c @@ -354,6 +354,7 @@ static int seg6_hmac_init_algo(void) struct crypto_shash *tfm; struct shash_desc *shash; int i, alg_count, cpu; + int ret = -ENOMEM; alg_count = ARRAY_SIZE(hmac_algos); @@ -364,12 +365,14 @@ static int seg6_hmac_init_algo(void) algo = &hmac_algos[i]; algo->tfms = alloc_percpu(struct crypto_shash *); if (!algo->tfms) - return -ENOMEM; + goto error_out; for_each_possible_cpu(cpu) { tfm = crypto_alloc_shash(algo->name, 0, 0); - if (IS_ERR(tfm)) - return PTR_ERR(tfm); + if (IS_ERR(tfm)) { + ret = PTR_ERR(tfm); + goto error_out; + } p_tfm = per_cpu_ptr(algo->tfms, cpu); *p_tfm = tfm; } @@ -381,18 +384,22 @@ static int seg6_hmac_init_algo(void) algo->shashs = alloc_percpu(struct shash_desc *); if (!algo->shashs) - return -ENOMEM; + goto error_out; for_each_possible_cpu(cpu) { shash = kzalloc_node(shsize, GFP_KERNEL, cpu_to_node(cpu)); if (!shash) - return -ENOMEM; + goto error_out; *per_cpu_ptr(algo->shashs, cpu) = shash; } } return 0; + +error_out: + seg6_hmac_exit(); + return ret; } int __init seg6_hmac_init(void) @@ -410,22 +417,29 @@ int __net_init seg6_hmac_net_init(struct net *net) void seg6_hmac_exit(void) { struct seg6_hmac_algo *algo = NULL; + struct crypto_shash *tfm; + struct shash_desc *shash; int i, alg_count, cpu; alg_count = ARRAY_SIZE(hmac_algos); for (i = 0; i < alg_count; i++) { algo = &hmac_algos[i]; - for_each_possible_cpu(cpu) { - struct crypto_shash *tfm; - struct shash_desc *shash; - shash = *per_cpu_ptr(algo->shashs, cpu); - kfree(shash); - tfm = *per_cpu_ptr(algo->tfms, cpu); - crypto_free_shash(tfm); + if (algo->shashs) { + for_each_possible_cpu(cpu) { + shash = *per_cpu_ptr(algo->shashs, cpu); + kfree(shash); + } + free_percpu(algo->shashs); + } + + if (algo->tfms) { + for_each_possible_cpu(cpu) { + tfm = *per_cpu_ptr(algo->tfms, cpu); + crypto_free_shash(tfm); + } + free_percpu(algo->tfms); } - free_percpu(algo->tfms); - free_percpu(algo->shashs); } } EXPORT_SYMBOL(seg6_hmac_exit); -- 2.34.1

2 1

[PATCH OLK-6.6] ipv6: sr: fix memleak in seg6_hmac_init_algo
by Zhengchao Shao 13 Jul '24

13 Jul '24

From: Hangbin Liu <liuhangbin(a)gmail.com> stable inclusion from stable-v6.6.33 commit 0e44d6cbe8de983470c3d2f978649783384fdcb6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAC3N0 CVE: CVE-2024-39489 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit efb9f4f19f8e37fde43dfecebc80292d179f56c6 ] seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms. Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly. Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Reported-by: Sabrina Dubroca <sd(a)queasysnail.net> Closes: https://lore.kernel.org/netdev/Zj3bh-gE7eT6V6aH@hog/ Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Link: https://lore.kernel.org/r/20240517005435.2600277-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/ipv6/seg6_hmac.c | 42 ++++++++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 14 deletions(-) diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c index d43c50a7310d..3c3800223e0e 100644 --- a/net/ipv6/seg6_hmac.c +++ b/net/ipv6/seg6_hmac.c @@ -354,6 +354,7 @@ static int seg6_hmac_init_algo(void) struct crypto_shash *tfm; struct shash_desc *shash; int i, alg_count, cpu; + int ret = -ENOMEM; alg_count = ARRAY_SIZE(hmac_algos); @@ -364,12 +365,14 @@ static int seg6_hmac_init_algo(void) algo = &hmac_algos[i]; algo->tfms = alloc_percpu(struct crypto_shash *); if (!algo->tfms) - return -ENOMEM; + goto error_out; for_each_possible_cpu(cpu) { tfm = crypto_alloc_shash(algo->name, 0, 0); - if (IS_ERR(tfm)) - return PTR_ERR(tfm); + if (IS_ERR(tfm)) { + ret = PTR_ERR(tfm); + goto error_out; + } p_tfm = per_cpu_ptr(algo->tfms, cpu); *p_tfm = tfm; } @@ -381,18 +384,22 @@ static int seg6_hmac_init_algo(void) algo->shashs = alloc_percpu(struct shash_desc *); if (!algo->shashs) - return -ENOMEM; + goto error_out; for_each_possible_cpu(cpu) { shash = kzalloc_node(shsize, GFP_KERNEL, cpu_to_node(cpu)); if (!shash) - return -ENOMEM; + goto error_out; *per_cpu_ptr(algo->shashs, cpu) = shash; } } return 0; + +error_out: + seg6_hmac_exit(); + return ret; } int __init seg6_hmac_init(void) @@ -410,22 +417,29 @@ int __net_init seg6_hmac_net_init(struct net *net) void seg6_hmac_exit(void) { struct seg6_hmac_algo *algo = NULL; + struct crypto_shash *tfm; + struct shash_desc *shash; int i, alg_count, cpu; alg_count = ARRAY_SIZE(hmac_algos); for (i = 0; i < alg_count; i++) { algo = &hmac_algos[i]; - for_each_possible_cpu(cpu) { - struct crypto_shash *tfm; - struct shash_desc *shash; - shash = *per_cpu_ptr(algo->shashs, cpu); - kfree(shash); - tfm = *per_cpu_ptr(algo->tfms, cpu); - crypto_free_shash(tfm); + if (algo->shashs) { + for_each_possible_cpu(cpu) { + shash = *per_cpu_ptr(algo->shashs, cpu); + kfree(shash); + } + free_percpu(algo->shashs); + } + + if (algo->tfms) { + for_each_possible_cpu(cpu) { + tfm = *per_cpu_ptr(algo->tfms, cpu); + crypto_free_shash(tfm); + } + free_percpu(algo->tfms); } - free_percpu(algo->tfms); - free_percpu(algo->shashs); } } EXPORT_SYMBOL(seg6_hmac_exit); -- 2.34.1

2 1

[PATCH OLK-6.6 00/22] support for SMC-D loopback_lo feature
by Zhengchao Shao 13 Jul '24

13 Jul '24

Support for SMC-D loopback_lo feature. Wen Gu (22): net/smc: rename some 'fce' to 'fce_v2x' for clarity net/smc: introduce sub-functions for smc_clc_send_confirm_accept() net/smc: unify the structs of accept or confirm message for v1 and v2 net/smc: support SMCv2.x supplemental features negotiation net/smc: introduce virtual ISM device support feature net/smc: define a reserved CHID range for virtual ISM devices net/smc: compatible with 128-bits extended GID of virtual ISM device net/smc: support extended GID in SMC-D lgr netlink attribute net/smc: manage system EID in SMC stack instead of ISM driver net/smc: fix incorrect SMC-D link group matching logic net/smc: change the term virtual ISM to Emulated-ISM net/smc: decouple ism_client from SMC-D DMB registration net/smc: introduce loopback-ism for SMC intra-OS shortcut net/smc: implement ID-related operations of loopback-ism net/smc: implement DMB-related operations of loopback-ism net/smc: mark optional smcd_ops and check for support when called net/smc: ignore loopback-ism when dumping SMC-D devices net/smc: register loopback-ism into SMC-D device list net/smc: add operations to merge sndbuf with peer DMB net/smc: {at|de}tach sndbuf to peer DMB if supported net/smc: adapt cursor update when sndbuf and peer DMB are merged net/smc: implement DMB-merged operations of loopback-ism drivers/s390/net/ism.h | 7 - drivers/s390/net/ism_drv.c | 59 ++--- include/linux/ism.h | 1 - include/net/smc.h | 33 ++- include/uapi/linux/smc.h | 2 + include/uapi/linux/smc_diag.h | 2 + net/smc/Kconfig | 13 ++ net/smc/Makefile | 1 + net/smc/af_smc.c | 146 ++++++++---- net/smc/smc.h | 10 +- net/smc/smc_cdc.c | 36 ++- net/smc/smc_clc.c | 304 ++++++++++++++---------- net/smc/smc_clc.h | 64 ++--- net/smc/smc_core.c | 104 ++++++++- net/smc/smc_core.h | 19 +- net/smc/smc_diag.c | 9 +- net/smc/smc_ism.c | 136 ++++++++--- net/smc/smc_ism.h | 40 +++- net/smc/smc_loopback.c | 427 ++++++++++++++++++++++++++++++++++ net/smc/smc_loopback.h | 61 +++++ net/smc/smc_pnet.c | 4 +- 21 files changed, 1158 insertions(+), 320 deletions(-) create mode 100644 net/smc/smc_loopback.c create mode 100644 net/smc/smc_loopback.h -- 2.34.1

2 23

[PATCH OLK-6.6 00/22] support for SMC-D loopback_lo feature
by Zhengchao Shao 13 Jul '24

13 Jul '24

Support for SMC-D loopback_lo feature. Wen Gu (22): net/smc: rename some 'fce' to 'fce_v2x' for clarity net/smc: introduce sub-functions for smc_clc_send_confirm_accept() net/smc: unify the structs of accept or confirm message for v1 and v2 net/smc: support SMCv2.x supplemental features negotiation net/smc: introduce virtual ISM device support feature net/smc: define a reserved CHID range for virtual ISM devices net/smc: compatible with 128-bits extended GID of virtual ISM device net/smc: support extended GID in SMC-D lgr netlink attribute net/smc: manage system EID in SMC stack instead of ISM driver net/smc: fix incorrect SMC-D link group matching logic net/smc: change the term virtual ISM to Emulated-ISM net/smc: decouple ism_client from SMC-D DMB registration net/smc: introduce loopback-ism for SMC intra-OS shortcut net/smc: implement ID-related operations of loopback-ism net/smc: implement DMB-related operations of loopback-ism net/smc: mark optional smcd_ops and check for support when called net/smc: ignore loopback-ism when dumping SMC-D devices net/smc: register loopback-ism into SMC-D device list net/smc: add operations to merge sndbuf with peer DMB net/smc: {at|de}tach sndbuf to peer DMB if supported net/smc: adapt cursor update when sndbuf and peer DMB are merged net/smc: implement DMB-merged operations of loopback-ism drivers/s390/net/ism.h | 7 - drivers/s390/net/ism_drv.c | 59 ++--- include/linux/ism.h | 1 - include/net/smc.h | 33 ++- include/uapi/linux/smc.h | 2 + include/uapi/linux/smc_diag.h | 2 + net/smc/Kconfig | 13 ++ net/smc/Makefile | 1 + net/smc/af_smc.c | 146 ++++++++---- net/smc/smc.h | 10 +- net/smc/smc_cdc.c | 36 ++- net/smc/smc_clc.c | 304 ++++++++++++++---------- net/smc/smc_clc.h | 64 ++--- net/smc/smc_core.c | 104 ++++++++- net/smc/smc_core.h | 19 +- net/smc/smc_diag.c | 9 +- net/smc/smc_ism.c | 136 ++++++++--- net/smc/smc_ism.h | 40 +++- net/smc/smc_loopback.c | 427 ++++++++++++++++++++++++++++++++++ net/smc/smc_loopback.h | 61 +++++ net/smc/smc_pnet.c | 4 +- 21 files changed, 1158 insertions(+), 320 deletions(-) create mode 100644 net/smc/smc_loopback.c create mode 100644 net/smc/smc_loopback.h -- 2.34.1

1 9

[PATCH OLK-6.6] kvm: add coda feature
by l00500167 13 Jul '24

13 Jul '24

virtcca feature Signed-off-by: l00500167 <lijunbin4(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 ++++++++++++++ include/linux/iommu.h | 3 +++ 2 files changed, 17 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index 859d21729..0f2acb4ed 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -625,6 +625,9 @@ struct arm_smmu_strtab_l1_desc { struct arm_smmu_ste *l2ptr; dma_addr_t l2ptr_dma; +#ifdef CONFIG_CVM_HOST + bool is_sync; +#endif }; struct arm_smmu_ctx_desc { @@ -750,6 +753,12 @@ struct arm_smmu_device { struct mutex streams_mutex; bool bypass; +#ifdef CONFIG_CVM_HOST + int s_evtq_irq; + int s_gerr_irq; + resource_size_t ioaddr; + uint64_t id; +#endif }; struct arm_smmu_stream { @@ -802,6 +811,11 @@ struct arm_smmu_domain { spinlock_t devices_lock; struct list_head mmu_notifiers; +#ifdef CONFIG_CVM_HOST + bool secure; + struct list_head node; + struct kvm *kvm; +#endif }; static inline struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 1d70dd0d0..e3186fbd4 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -635,6 +635,9 @@ struct iommu_ops { struct iommu_domain *blocked_domain; struct iommu_domain *default_domain; +#ifdef CONFIG_CVM_HOST + int (*iommu_enable_secure)(struct iommu_domain *domain); +#endif KABI_RESERVE(1) KABI_RESERVE(2) KABI_RESERVE(3) -- 2.25.1

2 1

[openeuler:OLK-5.10] BUILD SUCCESS e716fc2c6d620ad9767378aeb6d9155bf7b8308f
by kernel test robot 13 Jul '24

13 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: e716fc2c6d620ad9767378aeb6d9155bf7b8308f !9368 CVE-2024-27416 elapsed time: 731m configs tested: 34 configs skipped: 111 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240713 gcc-14.1.0 arm64 randconfig-002-20240713 gcc-14.1.0 arm64 randconfig-003-20240713 clang-19 arm64 randconfig-004-20240713 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240713 clang-18 x86_64 buildonly-randconfig-002-20240713 clang-18 x86_64 buildonly-randconfig-003-20240713 gcc-13 x86_64 buildonly-randconfig-004-20240713 clang-18 x86_64 buildonly-randconfig-005-20240713 gcc-8 x86_64 buildonly-randconfig-006-20240713 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240713 clang-18 x86_64 randconfig-002-20240713 clang-18 x86_64 randconfig-003-20240713 clang-18 x86_64 randconfig-004-20240713 gcc-13 x86_64 randconfig-005-20240713 clang-18 x86_64 randconfig-006-20240713 clang-18 x86_64 randconfig-011-20240713 clang-18 x86_64 randconfig-012-20240713 clang-18 x86_64 randconfig-013-20240713 gcc-13 x86_64 randconfig-014-20240713 clang-18 x86_64 randconfig-015-20240713 gcc-13 x86_64 randconfig-016-20240713 gcc-13 x86_64 randconfig-071-20240713 gcc-8 x86_64 randconfig-072-20240713 gcc-8 x86_64 randconfig-073-20240713 clang-18 x86_64 randconfig-074-20240713 clang-18 x86_64 randconfig-075-20240713 gcc-13 x86_64 randconfig-076-20240713 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] BUILD REGRESSION 10bfbd53c8aa4c81829876b20e654c4e7c4e7aa7
by kernel test robot 13 Jul '24

13 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-6.6 branch HEAD: 10bfbd53c8aa4c81829876b20e654c4e7c4e7aa7 !5261 [OLK-6.6]Hygon: Some enhancement and bugfixes for HYGON CSV/CSV2 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202407130439.z4HZgaFv-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) include/linux/mmzone.h:1788:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE Error/Warning ids grouped by kconfigs: recent_errors |-- arm64-allmodconfig | `-- clang:warning:no-such-include-directory:drivers-infiniband-hw-hiroce3-include-mag |-- loongarch-allmodconfig | `-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument |-- loongarch-randconfig-001-20240713 | |-- arch-loongarch-kvm-..-..-..-virt-kvm-kvm_main.c:warning:kvmalloc_array-sizes-specified-with-sizeof-in-the-earlier-argument-and-not-in-the-later-argument | `-- drivers-char-virtio_console.c:warning:u-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size-between-and |-- loongarch-randconfig-002-20240713 | `-- include-linux-mmzone.h:error:error-Allocator-MAX_ORDER-exceeds-SECTION_SIZE `-- x86_64-allyesconfig `-- drivers-gpu-drm-amd-amdgpu-..-amdkfd-kfd_topology.c:warning:stack-frame-size-()-exceeds-limit-()-in-kfd_topology_add_device elapsed time: 725m configs tested: 14 configs skipped: 97 tested configs: arm64 allmodconfig clang-19 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240713 gcc-14.1.0 arm64 randconfig-002-20240713 gcc-14.1.0 arm64 randconfig-003-20240713 clang-19 arm64 randconfig-004-20240713 gcc-14.1.0 loongarch allmodconfig gcc-14.1.0 loongarch allnoconfig gcc-14.1.0 loongarch randconfig-001-20240713 gcc-14.1.0 loongarch randconfig-002-20240713 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 defconfig gcc-13 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 3892/10681] include/linux/mmzone.h:1788:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE
by kernel test robot 13 Jul '24

13 Jul '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 10bfbd53c8aa4c81829876b20e654c4e7c4e7aa7 commit: c93eb12529e21dbb59796132f4fdf75fad4eddaf [3892/10681] LoongArch: Adapted SECTION_SIZE_BITS with page size config: loongarch-randconfig-002-20240713 (https://download.01.org/0day-ci/archive/20240713/202407130439.z4HZgaFv-lkp@…) compiler: loongarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240713/202407130439.z4HZgaFv-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/202407130439.z4HZgaFv-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from include/linux/gfp.h:7, from include/linux/mm.h:7, from arch/loongarch/kernel/asm-offsets.c:9: >> include/linux/mmzone.h:1788:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE 1788 | #error Allocator MAX_ORDER exceeds SECTION_SIZE | ^~~~~ arch/loongarch/kernel/asm-offsets.c:18:6: warning: no previous prototype for 'output_ptreg_defines' [-Wmissing-prototypes] 18 | void output_ptreg_defines(void) | ^~~~~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:65:6: warning: no previous prototype for 'output_task_defines' [-Wmissing-prototypes] 65 | void output_task_defines(void) | ^~~~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:80:6: warning: no previous prototype for 'output_thread_info_defines' [-Wmissing-prototypes] 80 | void output_thread_info_defines(void) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:96:6: warning: no previous prototype for 'output_thread_defines' [-Wmissing-prototypes] 96 | void output_thread_defines(void) | ^~~~~~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:132:6: warning: no previous prototype for 'output_thread_fpu_defines' [-Wmissing-prototypes] 132 | void output_thread_fpu_defines(void) | ^~~~~~~~~~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:173:6: warning: no previous prototype for 'output_thread_lbt_defines' [-Wmissing-prototypes] 173 | void output_thread_lbt_defines(void) | ^~~~~~~~~~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:183:6: warning: no previous prototype for 'output_mm_defines' [-Wmissing-prototypes] 183 | void output_mm_defines(void) | ^~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:215:6: warning: no previous prototype for 'output_sc_defines' [-Wmissing-prototypes] 215 | void output_sc_defines(void) | ^~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:223:6: warning: no previous prototype for 'output_signal_defines' [-Wmissing-prototypes] 223 | void output_signal_defines(void) | ^~~~~~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:261:6: warning: no previous prototype for 'output_smpboot_defines' [-Wmissing-prototypes] 261 | void output_smpboot_defines(void) | ^~~~~~~~~~~~~~~~~~~~~~ arch/loongarch/kernel/asm-offsets.c:294:6: warning: no previous prototype for 'output_kvm_defines' [-Wmissing-prototypes] 294 | void output_kvm_defines(void) | ^~~~~~~~~~~~~~~~~~ make[3]: *** [scripts/Makefile.build:116: arch/loongarch/kernel/asm-offsets.s] Error 1 shuffle=784060646 make[3]: Target 'prepare' not remade because of errors. make[2]: *** [Makefile:1202: prepare0] Error 2 shuffle=784060646 make[2]: Target 'prepare' not remade because of errors. make[1]: *** [Makefile:234: __sub-make] Error 2 shuffle=784060646 make[1]: Target 'prepare' not remade because of errors. make: *** [Makefile:234: __sub-make] Error 2 shuffle=784060646 make: Target 'prepare' not remade because of errors. vim +1788 include/linux/mmzone.h d41dee369bff3b Andy Whitcroft 2005-06-23 1783 835c134ec4dd75 Mel Gorman 2007-10-16 1784 #define SECTION_BLOCKFLAGS_BITS \ d9c2340052278d Mel Gorman 2007-10-16 1785 ((1UL << (PFN_SECTION_SHIFT - pageblock_order)) * NR_PAGEBLOCK_BITS) 835c134ec4dd75 Mel Gorman 2007-10-16 1786 23baf831a32c04 Kirill A. Shutemov 2023-03-15 1787 #if (MAX_ORDER + PAGE_SHIFT) > SECTION_SIZE_BITS d41dee369bff3b Andy Whitcroft 2005-06-23 @1788 #error Allocator MAX_ORDER exceeds SECTION_SIZE d41dee369bff3b Andy Whitcroft 2005-06-23 1789 #endif d41dee369bff3b Andy Whitcroft 2005-06-23 1790 :::::: The code at line 1788 was first introduced by commit :::::: d41dee369bff3b9dcb6328d4d822926c28cc2594 [PATCH] sparsemem memory model :::::: TO: Andy Whitcroft <apw(a)shadowen.org> :::::: CC: Linus Torvalds <torvalds(a)ppc970.osdl.org> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:openEuler-1.0-LTS] BUILD REGRESSION 07c988f00903b4f0fbf9c31cea24351fbf885b1c
by kernel test robot 13 Jul '24

13 Jul '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 07c988f00903b4f0fbf9c31cea24351fbf885b1c !9492 netlabel: fix out-of-bounds memory accesses Error/Warning ids grouped by kconfigs: recent_errors `-- arm64-randconfig-001-20240712 `-- drivers-mmc-host-phytium-sdci.c:error:lvalue-required-as-unary-operand elapsed time: 727m configs tested: 31 configs skipped: 111 tested configs: arm64 allmodconfig gcc-14.1.0 arm64 allnoconfig gcc-14.1.0 arm64 randconfig-001-20240712 gcc-14.1.0 arm64 randconfig-002-20240712 gcc-14.1.0 arm64 randconfig-003-20240712 gcc-14.1.0 arm64 randconfig-004-20240712 gcc-14.1.0 x86_64 allnoconfig clang-18 x86_64 allyesconfig clang-18 x86_64 buildonly-randconfig-001-20240712 clang-18 x86_64 buildonly-randconfig-002-20240712 clang-18 x86_64 buildonly-randconfig-003-20240712 clang-18 x86_64 buildonly-randconfig-004-20240712 clang-18 x86_64 buildonly-randconfig-005-20240712 clang-18 x86_64 buildonly-randconfig-006-20240712 clang-18 x86_64 defconfig gcc-13 x86_64 randconfig-001-20240712 gcc-12 x86_64 randconfig-002-20240712 gcc-13 x86_64 randconfig-003-20240712 gcc-12 x86_64 randconfig-004-20240712 clang-18 x86_64 randconfig-005-20240712 gcc-13 x86_64 randconfig-006-20240712 clang-18 x86_64 randconfig-011-20240712 clang-18 x86_64 randconfig-012-20240712 clang-18 x86_64 randconfig-013-20240712 clang-18 x86_64 randconfig-014-20240712 gcc-13 x86_64 randconfig-015-20240712 clang-18 x86_64 randconfig-016-20240712 clang-18 x86_64 randconfig-071-20240712 gcc-13 x86_64 randconfig-072-20240712 gcc-11 x86_64 randconfig-073-20240712 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:openEuler-1.0-LTS 21349/23271] drivers/mmc/host/phytium-sdci.c:1483:23: error: lvalue required as unary '&' operand
by kernel test robot 13 Jul '24

13 Jul '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 07c988f00903b4f0fbf9c31cea24351fbf885b1c commit: d65622e6edee11f7fcbd295bdb5aef86e12dfef3 [21349/23271] mmc: add support for Phytium MMC config: arm64-randconfig-001-20240712 (https://download.01.org/0day-ci/archive/20240713/202407130055.5P1q7PDM-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.1.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240713/202407130055.5P1q7PDM-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/202407130055.5P1q7PDM-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/mmc/host/phytium-sdci.c: In function 'phytium_sdci_start_data': drivers/mmc/host/phytium-sdci.c:271:14: warning: variable 'read' set but not used [-Wunused-but-set-variable] 271 | bool read, res; | ^~~~ drivers/mmc/host/phytium-sdci.c: In function 'phytium_sdci_dma_irq': drivers/mmc/host/phytium-sdci.c:1018:29: warning: variable 'cmd' set but not used [-Wunused-but-set-variable] 1018 | struct mmc_command *cmd; | ^~~ drivers/mmc/host/phytium-sdci.c: At top level: >> drivers/mmc/host/phytium-sdci.c:1483:23: error: lvalue required as unary '&' operand 1483 | .pm = &phytium_sdci_dev_pm_ops, | ^ vim +1483 drivers/mmc/host/phytium-sdci.c 1475 1476 static struct platform_driver phytium_sdci_driver = { 1477 .probe = phytium_sdci_probe, 1478 .remove = phytium_sdci_remove, 1479 .driver = { 1480 .name = "sdci-phytium", 1481 .of_match_table = phytium_sdci_of_ids, 1482 .acpi_match_table = phytium_sdci_acpi_ids, > 1483 .pm = &phytium_sdci_dev_pm_ops, 1484 }, 1485 }; 1486 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-6.6 10626/10665] drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1922:5: warning: stack frame size (2200) exceeds limit (2048) in 'kfd_topology_add_device'
by kernel test robot 12 Jul '24

12 Jul '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 57aa1dda67c88842ffde6304bf732c7d7c81c211 commit: 241ad43fe7e9c24d5ba4cdd1ec22e731cdd22d14 [10626/10665] Compiler: Add clang's PGO support for kernel. config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20240712/202407122247.S82V5Eh3-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/20240712/202407122247.S82V5Eh3-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/202407122247.S82V5Eh3-lkp@intel.com/ All warnings (new ones prefixed by >>): >> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1922:5: warning: stack frame size (2200) exceeds limit (2048) in 'kfd_topology_add_device' [-Wframe-larger-than] 1922 | int kfd_topology_add_device(struct kfd_node *gpu) | ^ 1 warning generated. vim +/kfd_topology_add_device +1922 drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c d230f1bfe7a197 Jonathan Kim 2022-03-25 1921 8dc1db3172ae2f Mukul Joshi 2022-09-14 @1922 int kfd_topology_add_device(struct kfd_node *gpu) f701acb6a4ed0a Felix Kuehling 2022-11-16 1923 { f701acb6a4ed0a Felix Kuehling 2022-11-16 1924 uint32_t gpu_id; f701acb6a4ed0a Felix Kuehling 2022-11-16 1925 struct kfd_topology_device *dev; f701acb6a4ed0a Felix Kuehling 2022-11-16 1926 struct kfd_cu_info cu_info; f701acb6a4ed0a Felix Kuehling 2022-11-16 1927 int res = 0; f701acb6a4ed0a Felix Kuehling 2022-11-16 1928 int i; f701acb6a4ed0a Felix Kuehling 2022-11-16 1929 const char *asic_name = amdgpu_asic_name[gpu->adev->asic_type]; f701acb6a4ed0a Felix Kuehling 2022-11-16 1930 f701acb6a4ed0a Felix Kuehling 2022-11-16 1931 gpu_id = kfd_generate_gpu_id(gpu); 400a39f1ec43d2 James Zhu 2023-08-09 1932 if (gpu->xcp && !gpu->xcp->ddev) { 400a39f1ec43d2 James Zhu 2023-08-09 1933 dev_warn(gpu->adev->dev, 400a39f1ec43d2 James Zhu 2023-08-09 1934 "Won't add GPU (ID: 0x%x) to topology since it has no drm node assigned.", 400a39f1ec43d2 James Zhu 2023-08-09 1935 gpu_id); 400a39f1ec43d2 James Zhu 2023-08-09 1936 return 0; 400a39f1ec43d2 James Zhu 2023-08-09 1937 } else { f701acb6a4ed0a Felix Kuehling 2022-11-16 1938 pr_debug("Adding new GPU (ID: 0x%x) to topology\n", gpu_id); 400a39f1ec43d2 James Zhu 2023-08-09 1939 } f701acb6a4ed0a Felix Kuehling 2022-11-16 1940 f701acb6a4ed0a Felix Kuehling 2022-11-16 1941 /* Check to see if this gpu device exists in the topology_device_list. f701acb6a4ed0a Felix Kuehling 2022-11-16 1942 * If so, assign the gpu to that device, f701acb6a4ed0a Felix Kuehling 2022-11-16 1943 * else create a Virtual CRAT for this gpu device and then parse that f701acb6a4ed0a Felix Kuehling 2022-11-16 1944 * CRAT to create a new topology device. Once created assign the gpu to f701acb6a4ed0a Felix Kuehling 2022-11-16 1945 * that topology device f701acb6a4ed0a Felix Kuehling 2022-11-16 1946 */ f701acb6a4ed0a Felix Kuehling 2022-11-16 1947 down_write(&topology_lock); f701acb6a4ed0a Felix Kuehling 2022-11-16 1948 dev = kfd_assign_gpu(gpu); f701acb6a4ed0a Felix Kuehling 2022-11-16 1949 if (!dev) f701acb6a4ed0a Felix Kuehling 2022-11-16 1950 res = kfd_topology_add_device_locked(gpu, gpu_id, &dev); c0cc999f3c32e6 Ma Jun 2022-11-02 1951 up_write(&topology_lock); f701acb6a4ed0a Felix Kuehling 2022-11-16 1952 if (res) f701acb6a4ed0a Felix Kuehling 2022-11-16 1953 return res; 5b5c4e40a37e85 Evgeny Pinchuk 2014-07-16 1954 5b5c4e40a37e85 Evgeny Pinchuk 2014-07-16 1955 dev->gpu_id = gpu_id; 5b5c4e40a37e85 Evgeny Pinchuk 2014-07-16 1956 gpu->id = gpu_id; 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1957 0f28cca87e9afc Ramesh Errabolu 2022-05-26 1958 kfd_dev_create_p2p_links(); 0f28cca87e9afc Ramesh Errabolu 2022-05-26 1959 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1960 /* TODO: Move the following lines to function 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1961 * kfd_add_non_crat_information 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1962 */ 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1963 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1964 /* Fill-in additional information that is not available in CRAT but 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1965 * needed for the topology 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1966 */ 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1967 574c4183ef7511 Graham Sider 2021-10-19 1968 amdgpu_amdkfd_get_cu_info(dev->gpu->adev, &cu_info); c181159a5b1e1e Yong Zhao 2019-08-01 1969 b7675b7bbc3c4c Graham Sider 2021-11-11 1970 for (i = 0; i < KFD_TOPOLOGY_PUBLIC_NAME_SIZE-1; i++) { b7675b7bbc3c4c Graham Sider 2021-11-11 1971 dev->node_props.name[i] = __tolower(asic_name[i]); b7675b7bbc3c4c Graham Sider 2021-11-11 1972 if (asic_name[i] == '\0') b7675b7bbc3c4c Graham Sider 2021-11-11 1973 break; b7675b7bbc3c4c Graham Sider 2021-11-11 1974 } b7675b7bbc3c4c Graham Sider 2021-11-11 1975 dev->node_props.name[i] = '\0'; c181159a5b1e1e Yong Zhao 2019-08-01 1976 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1977 dev->node_props.simd_arrays_per_engine = 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1978 cu_info.num_shader_arrays_per_engine; 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1979 8dc1db3172ae2f Mukul Joshi 2022-09-14 1980 dev->node_props.gfx_target_version = 8dc1db3172ae2f Mukul Joshi 2022-09-14 1981 gpu->kfd->device_info.gfx_target_version; d69a3b762dc4c9 Mukul Joshi 2022-05-09 1982 dev->node_props.vendor_id = gpu->adev->pdev->vendor; d69a3b762dc4c9 Mukul Joshi 2022-05-09 1983 dev->node_props.device_id = gpu->adev->pdev->device; c6d1ec4134edc1 Joseph Greathouse 2020-04-16 1984 dev->node_props.capability |= 02274fc0f67259 Graham Sider 2021-11-05 1985 ((dev->gpu->adev->rev_id << HSA_CAP_ASIC_REVISION_SHIFT) & c6d1ec4134edc1 Joseph Greathouse 2020-04-16 1986 HSA_CAP_ASIC_REVISION_MASK); 92085240ef9c0e Jonathan Kim 2022-05-03 1987 d69a3b762dc4c9 Mukul Joshi 2022-05-09 1988 dev->node_props.location_id = pci_dev_id(gpu->adev->pdev); 92085240ef9c0e Jonathan Kim 2022-05-03 1989 if (KFD_GC_VERSION(dev->gpu->kfd) == IP_VERSION(9, 4, 3)) 92085240ef9c0e Jonathan Kim 2022-05-03 1990 dev->node_props.location_id |= dev->gpu->node_id; 92085240ef9c0e Jonathan Kim 2022-05-03 1991 d69a3b762dc4c9 Mukul Joshi 2022-05-09 1992 dev->node_props.domain = pci_domain_nr(gpu->adev->pdev->bus); 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1993 dev->node_props.max_engine_clk_fcompute = 574c4183ef7511 Graham Sider 2021-10-19 1994 amdgpu_amdkfd_get_max_engine_clock_in_mhz(dev->gpu->adev); 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1995 dev->node_props.max_engine_clk_ccompute = 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 1996 cpufreq_quick_get_max(0) / 1000; a476c0c645535c Philip Yang 2023-02-23 1997 a476c0c645535c Philip Yang 2023-02-23 1998 if (gpu->xcp) a476c0c645535c Philip Yang 2023-02-23 1999 dev->node_props.drm_render_minor = gpu->xcp->ddev->render->index; a476c0c645535c Philip Yang 2023-02-23 2000 else 7c9b717196b1af Oak Zeng 2018-03-15 2001 dev->node_props.drm_render_minor = 8dc1db3172ae2f Mukul Joshi 2022-09-14 2002 gpu->kfd->shared_resources.drm_render_minor; 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2003 8dc1db3172ae2f Mukul Joshi 2022-09-14 2004 dev->node_props.hive_id = gpu->kfd->hive_id; ee2f17f4d02b14 Amber Lin 2021-11-18 2005 dev->node_props.num_sdma_engines = kfd_get_num_sdma_engines(gpu); 14568cf6583e9d Oak Zeng 2019-02-08 2006 dev->node_props.num_sdma_xgmi_engines = ee2f17f4d02b14 Amber Lin 2021-11-18 2007 kfd_get_num_xgmi_sdma_engines(gpu); bb71c74db3c554 Huang Rui 2019-12-16 2008 dev->node_props.num_sdma_queues_per_engine = 8dc1db3172ae2f Mukul Joshi 2022-09-14 2009 gpu->kfd->device_info.num_sdma_queues_per_engine - 8dc1db3172ae2f Mukul Joshi 2022-09-14 2010 gpu->kfd->device_info.num_reserved_sdma_queues_per_engine; 29633d0e204df1 Joseph Greathouse 2020-01-15 2011 dev->node_props.num_gws = (dev->gpu->gws && 29e764621bbcd4 Oak Zeng 2019-05-03 2012 dev->gpu->dqm->sched_policy != KFD_SCHED_POLICY_NO_HWS) ? 02274fc0f67259 Graham Sider 2021-11-05 2013 dev->gpu->adev->gds.gws_size : 0; e6945304187dea Yong Zhao 2020-01-30 2014 dev->node_props.num_cp_queues = get_cp_queues_num(dev->gpu->dqm); 0c1690e38b5e68 Shaoyun Liu 2018-07-06 2015 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2016 kfd_fill_mem_clk_max_info(dev); 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2017 kfd_fill_iolink_non_crat_info(dev); 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2018 7eb0502ac0538e Graham Sider 2021-11-10 2019 switch (dev->gpu->adev->asic_type) { 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2020 case CHIP_KAVERI: 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2021 case CHIP_HAWAII: 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2022 case CHIP_TONGA: 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2023 dev->node_props.capability |= ((HSA_CAP_DOORBELL_TYPE_PRE_1_0 << 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2024 HSA_CAP_DOORBELL_TYPE_TOTALBITS_SHIFT) & 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2025 HSA_CAP_DOORBELL_TYPE_TOTALBITS_MASK); 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2026 break; 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2027 case CHIP_CARRIZO: 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2028 case CHIP_FIJI: 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2029 case CHIP_POLARIS10: 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2030 case CHIP_POLARIS11: 846a44d7e918a4 Gang Ba 2018-09-05 2031 case CHIP_POLARIS12: ed81cd6e0e9f37 Kent Russell 2019-03-21 2032 case CHIP_VEGAM: 42aa8793d795f1 Felix Kuehling 2017-12-08 2033 pr_debug("Adding doorbell packet type capability\n"); 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2034 dev->node_props.capability |= ((HSA_CAP_DOORBELL_TYPE_1_0 << 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2035 HSA_CAP_DOORBELL_TYPE_TOTALBITS_SHIFT) & 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2036 HSA_CAP_DOORBELL_TYPE_TOTALBITS_MASK); 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2037 break; e4804a39ba5f72 Graham Sider 2021-10-28 2038 default: d230f1bfe7a197 Jonathan Kim 2022-03-25 2039 if (KFD_GC_VERSION(dev->gpu) < IP_VERSION(9, 0, 1)) 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2040 WARN(1, "Unexpected ASIC family %u", 7eb0502ac0538e Graham Sider 2021-11-10 2041 dev->gpu->adev->asic_type); d230f1bfe7a197 Jonathan Kim 2022-03-25 2042 else d230f1bfe7a197 Jonathan Kim 2022-03-25 2043 kfd_topology_set_capabilities(dev); 7639a8c420f04c Ben Goz 2015-06-07 2044 } 7639a8c420f04c Ben Goz 2015-06-07 2045 1ae99eab34f90c Oak Zeng 2019-06-10 2046 /* 1ae99eab34f90c Oak Zeng 2019-06-10 2047 * Overwrite ATS capability according to needs_iommu_device to fix 1ae99eab34f90c Oak Zeng 2019-06-10 2048 * potential missing corresponding bit in CRAT of BIOS. 1ae99eab34f90c Oak Zeng 2019-06-10 2049 */ 1ae99eab34f90c Oak Zeng 2019-06-10 2050 dev->node_props.capability &= ~HSA_CAP_ATS_PRESENT; 1ae99eab34f90c Oak Zeng 2019-06-10 2051 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2052 /* Fix errors in CZ CRAT. 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2053 * simd_count: Carrizo CRAT reports wrong simd_count, probably 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2054 * because it doesn't consider masked out CUs 70f372bffcc84c Philip Cox 2017-12-08 2055 * max_waves_per_simd: Carrizo reports wrong max_waves_per_simd 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2056 */ 7eb0502ac0538e Graham Sider 2021-11-10 2057 if (dev->gpu->adev->asic_type == CHIP_CARRIZO) { 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2058 dev->node_props.simd_count = 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2059 cu_info.simd_per_cu * cu_info.cu_active_number; 70f372bffcc84c Philip Cox 2017-12-08 2060 dev->node_props.max_waves_per_simd = 10; 70f372bffcc84c Philip Cox 2017-12-08 2061 } 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2062 5436ab94cd9460 Stanley.Yang 2020-08-17 2063 /* kfd only concerns sram ecc on GFX and HBM ecc on UMC */ 0dee45a25a63f7 Eric Huang 2019-01-11 2064 dev->node_props.capability |= 56c5977eae8799 Graham Sider 2021-10-19 2065 ((dev->gpu->adev->ras_enabled & BIT(AMDGPU_RAS_BLOCK__GFX)) != 0) ? 0dee45a25a63f7 Eric Huang 2019-01-11 2066 HSA_CAP_SRAM_EDCSUPPORTED : 0; 56c5977eae8799 Graham Sider 2021-10-19 2067 dev->node_props.capability |= 56c5977eae8799 Graham Sider 2021-10-19 2068 ((dev->gpu->adev->ras_enabled & BIT(AMDGPU_RAS_BLOCK__UMC)) != 0) ? 0dee45a25a63f7 Eric Huang 2019-01-11 2069 HSA_CAP_MEM_EDCSUPPORTED : 0; 0dee45a25a63f7 Eric Huang 2019-01-11 2070 046e674b961594 Graham Sider 2021-11-09 2071 if (KFD_GC_VERSION(dev->gpu) != IP_VERSION(9, 0, 1)) 56c5977eae8799 Graham Sider 2021-10-19 2072 dev->node_props.capability |= (dev->gpu->adev->ras_enabled != 0) ? 0dee45a25a63f7 Eric Huang 2019-01-11 2073 HSA_CAP_RASEVENTNOTIFY : 0; 0dee45a25a63f7 Eric Huang 2019-01-11 2074 610dab118ff501 Philip Yang 2023-03-31 2075 if (KFD_IS_SVM_API_SUPPORTED(dev->gpu->adev)) 4c166eb95decf0 Philip Yang 2020-12-09 2076 dev->node_props.capability |= HSA_CAP_SVMAPI_SUPPORTED; 4c166eb95decf0 Philip Yang 2020-12-09 2077 03d400e7605e3d Alex Sierra 2023-06-15 2078 if (dev->gpu->adev->gmc.is_app_apu || 03d400e7605e3d Alex Sierra 2023-06-15 2079 dev->gpu->adev->gmc.xgmi.connected_to_cpu) 03d400e7605e3d Alex Sierra 2023-06-15 2080 dev->node_props.capability |= HSA_CAP_FLAGS_COHERENTHOSTACCESS; 03d400e7605e3d Alex Sierra 2023-06-15 2081 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2082 kfd_debug_print_topology(); 3a87177eb14113 Harish Kasiviswanathan 2017-12-08 2083 5b5c4e40a37e85 Evgeny Pinchuk 2014-07-16 2084 kfd_notify_gpu_change(gpu_id, 1); f701acb6a4ed0a Felix Kuehling 2022-11-16 2085 7d4f8db4a1448e Dan Carpenter 2022-11-25 2086 return 0; 5b5c4e40a37e85 Evgeny Pinchuk 2014-07-16 2087 } 5b5c4e40a37e85 Evgeny Pinchuk 2014-07-16 2088 :::::: The code at line 1922 was first introduced by commit :::::: 8dc1db3172ae2f17ae71e33b608a33411ce8a1aa drm/amdkfd: Introduce kfd_node struct (v5) :::::: TO: Mukul Joshi <mukul.joshi(a)amd.com> :::::: CC: Alex Deucher <alexander.deucher(a)amd.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] x86: resctrl: Fix illegal access by the chips not having RDT
by Zeng Heng 12 Jul '24

12 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IA7L2U --------------------------- If the chip not having RDT function, resctrl_arch_system_num_rmid_idx() would return 0. rmid_ptrs points to an illegal buffer after kcalloc() allocation, which would cause illegal access fault when accessing. Consequently, when we found resctrl_arch_system_num_rmid_idx() return 0, just return EOPNOTSUPP immediatly and skip initializing the resctrl file system. Fixes: 13e249bf4944 ("x86/resctrl: Move the filesystem portions of resctrl to live in '/fs/'") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- fs/resctrl/monitor.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index fcf2ab18966f..6f93ed1681c4 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -727,6 +727,9 @@ static int dom_data_init(struct rdt_resource *r) int err = 0, i; u32 idx; + if (!idx_limit) + return -EOPNOTSUPP; + mutex_lock(&rdtgroup_mutex); if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID)) { u32 *tmp; -- 2.25.1

2 1

[PATCH V2 OLK-5.10] iommu/arm-smmu-v3: Change the style to identify the the hisi_platform
by Zhang Zekun 12 Jul '24

12 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IACKUP ---------------------------------------------- The code is isolated by CONFIG_ARCH_HISI which could also be opened in other platforms . Change the style to identify the hisi platform to minimize the code influence scope. Fixes: 46f0c5798ba5 ("iommu/arm-smmu-v3: Enable iotlb_sync_map according to SMMU_IIDR") Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 33 ++++++++++++++++----- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 7c818a17ca11..c5c25be54fd5 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -129,6 +129,7 @@ struct arm_smmu_ctx_desc quiet_cd = { 0 }; static struct arm_smmu_option_prop arm_smmu_options[] = { { ARM_SMMU_OPT_SKIP_PREFETCH, "hisilicon,broken-prefetch-cmd" }, { ARM_SMMU_OPT_PAGE0_REGS_ONLY, "cavium,cn9900-broken-page1-regspace"}, + { ARM_SMMU_OPT_SYNC_MAP, "hisilicon,broken-prefetch-pgtbl"}, { 0, NULL}, }; @@ -4948,14 +4949,9 @@ static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) { u32 reg, i; - /* IIDR */ - reg = readl_relaxed(smmu->base + ARM_SMMU_IIDR); - if (!(FIELD_GET(IIDR_VARIANT, reg) == 0x3) || - !(FIELD_GET(IIDR_REVISON, reg) == 0x2)) + if (!(smmu->options & ARM_SMMU_OPT_SYNC_MAP)) return; - smmu->options |= ARM_SMMU_OPT_SYNC_MAP; - reg = readl_relaxed(smmu->base + ARM_SMMU_USER_CFG1); reg = reg & GENMASK(15, 0); for (i = 0; i < 8; i++) { @@ -4981,6 +4977,8 @@ static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) } smmu->options |= ARM_SMMU_OPT_SYNC_BATCH; } +#else +static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) {} #endif static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) @@ -5213,9 +5211,7 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) smmu->oas = 48; } -#ifdef CONFIG_HISILICON_ERRATUM_162100602 hisi_smmu_check_errata(smmu); -#endif if (arm_smmu_ops.pgsize_bitmap == -1UL) arm_smmu_ops.pgsize_bitmap = smmu->pgsize_bitmap; @@ -5248,6 +5244,25 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) } #ifdef CONFIG_ACPI +static struct acpi_platform_list arm_smmu_v3_plat_info[] __initdata = { + /* HiSilicon Hip09 Platform */ + {"HISI ", "HIP09 ", 0, ACPI_SIG_IORT, greater_than_or_equal, + "Erratum #162100602", 0}, + {"HISI ", "HIP10 ", 0, ACPI_SIG_IORT, greater_than_or_equal, + "Erratum #162100602", 0}, + {"HISI ", "HIP11 ", 0, ACPI_SIG_IORT, greater_than_or_equal, + "Erratum #162100602", 0}, + { } +}; + +static void acpi_get_hisi_options(struct arm_smmu_device *smmu) +{ + if (acpi_match_platform_list(arm_smmu_v3_plat_info) < 0) + return; + + smmu->options |= ARM_SMMU_OPT_SYNC_MAP; +} + static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu) { switch (model) { @@ -5259,6 +5274,8 @@ static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu) break; } + acpi_get_hisi_options(smmu); + dev_notice(smmu->dev, "option mask 0x%x\n", smmu->options); } -- 2.17.1

2 1

[PATCH OLK-5.10] iommu/arm-smmu-v3: Change the style to identify the the hisi_platform
by Zhang Zekun 12 Jul '24

12 Jul '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IACKUP ---------------------------------------------- The code is isolated by CONFIG_ARCH_HISI which could also be opened in other platforms . Change the style to identify the hisi platform to minimize the code influence scope. Fixes: 46f0c5798ba5 ("iommu/arm-smmu-v3: Enable iotlb_sync_map according to SMMU_IIDR") Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 33 ++++++++++++++++----- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index 7c818a17ca11..c5c25be54fd5 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -129,6 +129,7 @@ struct arm_smmu_ctx_desc quiet_cd = { 0 }; static struct arm_smmu_option_prop arm_smmu_options[] = { { ARM_SMMU_OPT_SKIP_PREFETCH, "hisilicon,broken-prefetch-cmd" }, { ARM_SMMU_OPT_PAGE0_REGS_ONLY, "cavium,cn9900-broken-page1-regspace"}, + { ARM_SMMU_OPT_SYNC_MAP, "hisilicon,broken-prefetch-pgtbl"}, { 0, NULL}, }; @@ -4948,14 +4949,9 @@ static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) { u32 reg, i; - /* IIDR */ - reg = readl_relaxed(smmu->base + ARM_SMMU_IIDR); - if (!(FIELD_GET(IIDR_VARIANT, reg) == 0x3) || - !(FIELD_GET(IIDR_REVISON, reg) == 0x2)) + if (!(smmu->options & ARM_SMMU_OPT_SYNC_MAP)) return; - smmu->options |= ARM_SMMU_OPT_SYNC_MAP; - reg = readl_relaxed(smmu->base + ARM_SMMU_USER_CFG1); reg = reg & GENMASK(15, 0); for (i = 0; i < 8; i++) { @@ -4981,6 +4977,8 @@ static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) } smmu->options |= ARM_SMMU_OPT_SYNC_BATCH; } +#else +static void hisi_smmu_check_errata(struct arm_smmu_device *smmu) {} #endif static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) @@ -5213,9 +5211,7 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) smmu->oas = 48; } -#ifdef CONFIG_HISILICON_ERRATUM_162100602 hisi_smmu_check_errata(smmu); -#endif if (arm_smmu_ops.pgsize_bitmap == -1UL) arm_smmu_ops.pgsize_bitmap = smmu->pgsize_bitmap; @@ -5248,6 +5244,25 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu) } #ifdef CONFIG_ACPI +static struct acpi_platform_list arm_smmu_v3_plat_info[] __initdata = { + /* HiSilicon Hip09 Platform */ + {"HISI ", "HIP09 ", 0, ACPI_SIG_IORT, greater_than_or_equal, + "Erratum #162100602", 0}, + {"HISI ", "HIP10 ", 0, ACPI_SIG_IORT, greater_than_or_equal, + "Erratum #162100602", 0}, + {"HISI ", "HIP11 ", 0, ACPI_SIG_IORT, greater_than_or_equal, + "Erratum #162100602", 0}, + { } +}; + +static void acpi_get_hisi_options(struct arm_smmu_device *smmu) +{ + if (acpi_match_platform_list(arm_smmu_v3_plat_info) < 0) + return; + + smmu->options |= ARM_SMMU_OPT_SYNC_MAP; +} + static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu) { switch (model) { @@ -5259,6 +5274,8 @@ static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu) break; } + acpi_get_hisi_options(smmu); + dev_notice(smmu->dev, "option mask 0x%x\n", smmu->options); } -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST
by Yongqiang Liu 12 Jul '24

12 Jul '24

From: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> stable inclusion from stable-v5.10.212 commit df193568d61234c81de7ed4d540c01975de60277 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9Q8M1 CVE: CVE-2024-27416 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7e74aa53a68bf60f6019bd5d9a9a1406ec4d4865 ] If we received HCI_EV_IO_CAPA_REQUEST while HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated. Link: https://lore.kernel.org/linux-bluetooth/CABBYNZ+9UdG1cMZVmdtN3U2aS16AKMCyTA… Fixes: c7f59461f5a7 ("Bluetooth: Fix a refcnt underflow problem for hci_conn") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Rui Xiang <rui.xiang(a)huawei.com> --- net/bluetooth/hci_event.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index e01159d8fabf..ff348a8a2424 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -4620,9 +4620,12 @@ static void hci_io_capa_request_evt(struct hci_dev *hdev, struct sk_buff *skb) hci_dev_lock(hdev); conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr); - if (!conn || !hci_conn_ssp_enabled(conn)) + if (!conn || !hci_dev_test_flag(hdev, HCI_SSP_ENABLED)) goto unlock; + /* Assume remote supports SSP since it has triggered this event */ + set_bit(HCI_CONN_SSP_ENABLED, &conn->flags); + hci_conn_hold(conn); if (!hci_dev_test_flag(hdev, HCI_MGMT)) -- 2.34.1

2 1

[PATCH OLK-5.10] fs: improve dump_mapping() robustness
by Jinjiang Tu 12 Jul '24

12 Jul '24

From: Baolin Wang <baolin.wang(a)linux.alibaba.com> mainline inclusion from mainline-v6.9-rc1 commit 8b3d838139bcd1e552f1899191f734264ce2a1a5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IACHGW CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------- We met a kernel crash issue when running stress-ng testing, and the system crashes when printing the dentry name in dump_mapping(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : dentry_name+0xd8/0x224 lr : pointer+0x22c/0x370 sp : ffff800025f134c0 ...... Call trace: dentry_name+0xd8/0x224 pointer+0x22c/0x370 vsnprintf+0x1ec/0x730 vscnprintf+0x2c/0x60 vprintk_store+0x70/0x234 vprintk_emit+0xe0/0x24c vprintk_default+0x3c/0x44 vprintk_func+0x84/0x2d0 printk+0x64/0x88 __dump_page+0x52c/0x530 dump_page+0x14/0x20 set_migratetype_isolate+0x110/0x224 start_isolate_page_range+0xc4/0x20c offline_pages+0x124/0x474 memory_block_offline+0x44/0xf4 memory_subsys_offline+0x3c/0x70 device_offline+0xf0/0x120 ...... The root cause is that, one thread is doing page migration, and we will use the target page's ->mapping field to save 'anon_vma' pointer between page unmap and page move, and now the target page is locked and refcount is 1. Currently, there is another stress-ng thread performing memory hotplug, attempting to offline the target page that is being migrated. It discovers that the refcount of this target page is 1, preventing the offline operation, thus proceeding to dump the page. However, page_mapping() of the target page may return an incorrect file mapping to crash the system in dump_mapping(), since the target page->mapping only saves 'anon_vma' pointer without setting PAGE_MAPPING_ANON flag. The page migration issue has been fixed by commit d1adb25df711 ("mm: migrate: fix getting incorrect page mapping during page migration"). In addition, Matthew suggested we should also improve dump_mapping()'s robustness to resilient against the kernel crash [1]. With checking the 'dentry.parent' and 'dentry.d_name.name' used by dentry_name(), I can see dump_mapping() will output the invalid dentry instead of crashing the system when this issue is reproduced again. [12211.189128] page:fffff7de047741c0 refcount:1 mapcount:0 mapping:ffff989117f55ea0 index:0x1 pfn:0x211dd07 [12211.189144] aops:0x0 ino:1 invalid dentry:74786574206e6870 [12211.189148] flags: 0x57ffffc0000001(locked|node=1|zone=2|lastcpupid=0x1fffff) [12211.189150] page_type: 0xffffffff() [12211.189153] raw: 0057ffffc0000001 0000000000000000 dead000000000122 ffff989117f55ea0 [12211.189154] raw: 0000000000000001 0000000000000001 00000001ffffffff 0000000000000000 [12211.189155] page dumped because: unmovable page [1] https://lore.kernel.org/all/ZXxn%2F0oixJxxAnpF@casper.infradead.org/ Suggested-by: Matthew Wilcox <willy(a)infradead.org> Signed-off-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Link: https://lore.kernel.org/r/937ab1f87328516821d39be672b6bc18861d9d3e.17053914… Signed-off-by: Christian Brauner <brauner(a)kernel.org> Conflicts: fs/inode.c mm/debug.c [Prior cleanup commit 3e9d80a891df is not merged.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/debug.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/debug.c b/mm/debug.c index 8a40b3fefbeb..6ead410ec389 100644 --- a/mm/debug.c +++ b/mm/debug.c @@ -150,7 +150,8 @@ void __dump_page(struct page *page, const char *reason) } dentry_ptr = container_of(dentry_first, struct dentry, d_u.d_alias); - if (get_kernel_nofault(dentry, dentry_ptr)) { + if (get_kernel_nofault(dentry, dentry_ptr) || + !dentry.d_parent || !dentry.d_name.name) { pr_warn("aops:%ps ino:%lx with invalid dentry %px\n", a_ops, ino, dentry_ptr); } else { -- 2.25.1

2 1

[PATCH OLK-6.6 0/1] CVE-2024-39478
by Chen Ridong 12 Jul '24

12 Jul '24

*** BLURB HERE *** Jia Jie Ho (1): crypto: starfive - Do not free stack buffer drivers/crypto/starfive/jh7110-rsa.c | 1 - 1 file changed, 1 deletion(-) -- 2.34.1

2 2