- Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1] kdb: Fix buffer overflow during tab-complete
by Tengda Wu 08 Jul '24

08 Jul '24

From: Daniel Thompson <daniel.thompson(a)linaro.org> stable inclusion from stable-v5.10.219 commit cfdc2fa4db57503bc6d3817240547c8ddc55fa96 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAB05N CVE: CVE-2024-39480 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e9730744bf3af04cda23799029342aa3cddbc454 upstream. Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around. Reported-by: Justin Stitt <justinstitt(a)google.com> Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziU… Cc: stable(a)vger.kernel.org Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Reviewed-by: Justin Stitt <justinstitt(a)google.com> Tested-by: Justin Stitt <justinstitt(a)google.com> Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@lin… Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Fixes: 5d5314d6795f ("kdb: core for kgdb back end (1 of 2)") Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/debug/kdb/kdb_io.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c index 6735ac36b718..dcc7e13e98b3 100644 --- a/kernel/debug/kdb/kdb_io.c +++ b/kernel/debug/kdb/kdb_io.c @@ -354,14 +354,19 @@ static char *kdb_read(char *buffer, size_t bufsize) kdb_printf(kdb_prompt_str); kdb_printf("%s", buffer); } else if (tab != 2 && count > 0) { - len_tmp = strlen(p_tmp); - strncpy(p_tmp+len_tmp, cp, lastchar-cp+1); - len_tmp = strlen(p_tmp); - strncpy(cp, p_tmp+len, len_tmp-len + 1); - len = len_tmp - len; - kdb_printf("%s", cp); - cp += len; - lastchar += len; + /* How many new characters do we want from tmpbuffer? */ + len_tmp = strlen(p_tmp) - len; + if (lastchar + len_tmp >= bufend) + len_tmp = bufend - lastchar; + + if (len_tmp) { + /* + 1 ensures the '\0' is memmove'd */ + memmove(cp+len_tmp, cp, (lastchar-cp) + 1); + memcpy(cp, p_tmp+len, len_tmp); + kdb_printf("%s", cp); + cp += len_tmp; + lastchar += len_tmp; + } } kdb_nextline = 1; /* reset output line number */ break; -- 2.34.1

2 1

[PATCH OLK-5.10] arm64: mm: Pass pbha-performance-only bit under chosen node
by Wupeng Ma 08 Jul '24

08 Jul '24

From: Ma Wupeng <mawupeng1(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I96IZH -------------------------------- Pass pbha-performance-only under chosen node to slove booting problem. Fixes: f43933b3f947 ("arm64: cpufeature: Enable PBHA for stage1 early via FDT") Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- arch/arm64/kernel/cpufeature.c | 12 +++++++++++- drivers/firmware/efi/libstub/fdt.c | 7 ------- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 9a4193991be5..36a426b0def2 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -1802,14 +1802,24 @@ void __init early_pbha_init(void) if (!fdt) goto unlock; + /* arm,pbha-performance-only may exist in both chosen and cpus node */ + node = fdt_path_offset(fdt, "/chosen"); + if (node < 0) + goto unlock; + + prop = fdt_getprop(fdt, node, "arm,pbha-performance-only", &size); + if (prop) + goto found; + node = fdt_path_offset(fdt, "/cpus"); if (node < 0) goto unlock; prop = fdt_getprop(fdt, node, "arm,pbha-performance-only", &size); - if (!prop) + if (prop) goto unlock; +found: if (!cpu_has_pbha()) goto unlock; diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c index cb8e8e4e3f63..30aeb2b54569 100644 --- a/drivers/firmware/efi/libstub/fdt.c +++ b/drivers/firmware/efi/libstub/fdt.c @@ -57,13 +57,6 @@ static efi_status_t fdt_init_hbm_mode(void *fdt, int node) if (status) return EFI_LOAD_ERROR; - node = fdt_subnode_offset(fdt, 0, "cpus"); - if (node < 0) { - node = fdt_add_subnode(fdt, 0, "cpus"); - if (node < 0) - return EFI_LOAD_ERROR; - } - /* Current PBHA bit59 is need to enable PBHA bit0 mode. */ status = fdt_setprop_var(fdt, node, "arm,pbha-performance-only", arr); if (status) { -- 2.25.1

2 1

[PATCH OLK-6.6] mm: mem_reliable: Make counting reliable task usage compatible with folio
by Wupeng Ma 08 Jul '24

08 Jul '24

From: Ma Wupeng <mawupeng1(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8USBA -------------------------------- Memory folio is enabled in current branch, however the counting of reliale memory task need some polish to make the counting right. In zap_present_folio_ptes, non-anon folio should also be counted. Fixes: b5be205e006a ("mm/memory: factor out zapping of present pte into zap_present_pte()") Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> --- kernel/events/uprobes.c | 2 +- mm/huge_memory.c | 4 ++-- mm/khugepaged.c | 2 +- mm/ksm.c | 2 +- mm/memory.c | 7 ++++--- mm/rmap.c | 8 ++++---- 6 files changed, 13 insertions(+), 12 deletions(-) diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c index 9f8d9baa7a2f..a80072c3f888 100644 --- a/kernel/events/uprobes.c +++ b/kernel/events/uprobes.c @@ -199,7 +199,7 @@ static int __replace_page(struct vm_area_struct *vma, unsigned long addr, set_pte_at_notify(mm, addr, pvmw.pte, mk_pte(new_page, vma->vm_page_prot)); - add_reliable_page_counter(old_page, mm, -1); + add_reliable_folio_counter(old_folio, mm, -1); folio_remove_rmap_pte(old_folio, old_page, vma); if (!folio_mapped(old_folio)) folio_free_swap(old_folio); diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 32ddf09db52b..d743502c70f0 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1608,7 +1608,7 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm, return -EAGAIN; } add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR); - add_reliable_page_counter(src_page, dst_mm, HPAGE_PMD_NR); + add_reliable_folio_counter(src_folio, dst_mm, HPAGE_PMD_NR); out_zero_page: mm_inc_nr_ptes(dst_mm); pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable); @@ -2577,7 +2577,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd, folio_mark_dirty(folio); if (!folio_test_referenced(folio) && pmd_young(old_pmd)) folio_set_referenced(folio); - add_reliable_page_counter(page, mm, -HPAGE_PMD_NR); + add_reliable_folio_counter(folio, mm, -HPAGE_PMD_NR); folio_remove_rmap_pmd(folio, page, vma); folio_put(folio); } diff --git a/mm/khugepaged.c b/mm/khugepaged.c index fa787464662f..06f31ad4452e 100644 --- a/mm/khugepaged.c +++ b/mm/khugepaged.c @@ -1644,7 +1644,7 @@ int collapse_pte_mapped_thp(struct mm_struct *mm, unsigned long addr, */ ptep_clear(mm, addr, pte); folio_remove_rmap_pte(folio, page, vma); - add_reliable_page_counter(page, mm, -1); + add_reliable_folio_counter(folio, mm, -1); nr_ptes++; } diff --git a/mm/ksm.c b/mm/ksm.c index 94207293e6fc..09411079262b 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -1236,7 +1236,7 @@ static int replace_page(struct vm_area_struct *vma, struct page *page, */ if (!is_zero_pfn(page_to_pfn(kpage))) { folio_get(kfolio); - add_reliable_page_counter(kpage, mm, 1); + add_reliable_folio_counter(kfolio, mm, 1); folio_add_anon_rmap_pte(kfolio, kpage, vma, addr, RMAP_NONE); newpte = mk_pte(kpage, vma->vm_page_prot); } else { diff --git a/mm/memory.c b/mm/memory.c index fe10342687d0..49a5618661d8 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1495,12 +1495,12 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb, if (pte_young(ptent) && likely(vma_has_recency(vma))) folio_mark_accessed(folio); rss[mm_counter(folio)] -= nr; - add_reliable_page_counter(page, mm, -nr); } else { /* We don't need up-to-date accessed/dirty bits. */ clear_full_ptes(mm, addr, pte, nr, tlb->fullmm); rss[MM_ANONPAGES] -= nr; } + add_reliable_folio_counter(folio, mm, -nr); /* Checking a single PTE in a batch is sufficient. */ arch_check_zapped_pte(vma, ptent); @@ -1637,7 +1637,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb, */ WARN_ON_ONCE(!vma_is_anonymous(vma)); rss[mm_counter(folio)]--; - add_reliable_page_counter(page, mm, -1); + add_reliable_folio_counter(folio, mm, -1); if (is_device_private_entry(entry)) folio_remove_rmap_pte(folio, page, vma); folio_put(folio); @@ -1654,6 +1654,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb, if (!should_zap_folio(details, folio)) continue; rss[mm_counter(folio)]--; + add_reliable_folio_counter(folio, mm, -1); } else if (pte_marker_entry_uffd_wp(entry)) { /* * For anon: always drop the marker; for file: only @@ -4643,7 +4644,7 @@ vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page) entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); add_mm_counter(vma->vm_mm, mm_counter_file(folio), HPAGE_PMD_NR); - add_reliable_page_counter(page, vma->vm_mm, HPAGE_PMD_NR); + add_reliable_folio_counter(folio, vma->vm_mm, HPAGE_PMD_NR); folio_add_file_rmap_pmd(folio, page, vma); /* diff --git a/mm/rmap.c b/mm/rmap.c index d13003244e6a..d78bb701bda1 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1757,7 +1757,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, hsz); } else { dec_mm_counter(mm, mm_counter(folio)); - add_reliable_page_counter(&folio->page, mm, -1); + add_reliable_folio_counter(folio, mm, -1); set_pte_at(mm, address, pvmw.pte, pteval); } @@ -1773,7 +1773,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, * copied pages. */ dec_mm_counter(mm, mm_counter(folio)); - add_reliable_page_counter(&folio->page, mm, -1); + add_reliable_folio_counter(folio, mm, -1); } else if (folio_test_anon(folio)) { swp_entry_t entry = page_swap_entry(subpage); pte_t swp_pte; @@ -2163,7 +2163,7 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma, hsz); } else { dec_mm_counter(mm, mm_counter(folio)); - add_reliable_page_counter(&folio->page, mm, -1); + add_reliable_folio_counter(folio, mm, -1); set_pte_at(mm, address, pvmw.pte, pteval); } @@ -2179,7 +2179,7 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma, * copied pages. */ dec_mm_counter(mm, mm_counter(folio)); - add_reliable_page_counter(&folio->page, mm, -1); + add_reliable_folio_counter(folio, mm, -1); } else { swp_entry_t entry; pte_t swp_pte; -- 2.25.1

2 1

[PATCH openEuler-22.03-LTS-SP1] kdb: Fix buffer overflow during tab-complete
by Tengda Wu 08 Jul '24

08 Jul '24

From: Daniel Thompson <daniel.thompson(a)linaro.org> stable inclusion from stable-v5.10.219 commit cfdc2fa4db57503bc6d3817240547c8ddc55fa96 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAB05N CVE: CVE-2024-39480 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e9730744bf3af04cda23799029342aa3cddbc454 upstream. Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around. Reported-by: Justin Stitt <justinstitt(a)google.com> Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziU… Cc: stable(a)vger.kernel.org Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Reviewed-by: Justin Stitt <justinstitt(a)google.com> Tested-by: Justin Stitt <justinstitt(a)google.com> Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@lin… Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Fixes: 5d5314d6795f3c1c0f415348ff8c51f7de042b77 ("kdb: core for kgdb back end (1 of 2)") Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/debug/kdb/kdb_io.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c index 6735ac36b718..dcc7e13e98b3 100644 --- a/kernel/debug/kdb/kdb_io.c +++ b/kernel/debug/kdb/kdb_io.c @@ -354,14 +354,19 @@ static char *kdb_read(char *buffer, size_t bufsize) kdb_printf(kdb_prompt_str); kdb_printf("%s", buffer); } else if (tab != 2 && count > 0) { - len_tmp = strlen(p_tmp); - strncpy(p_tmp+len_tmp, cp, lastchar-cp+1); - len_tmp = strlen(p_tmp); - strncpy(cp, p_tmp+len, len_tmp-len + 1); - len = len_tmp - len; - kdb_printf("%s", cp); - cp += len; - lastchar += len; + /* How many new characters do we want from tmpbuffer? */ + len_tmp = strlen(p_tmp) - len; + if (lastchar + len_tmp >= bufend) + len_tmp = bufend - lastchar; + + if (len_tmp) { + /* + 1 ensures the '\0' is memmove'd */ + memmove(cp+len_tmp, cp, (lastchar-cp) + 1); + memcpy(cp, p_tmp+len, len_tmp); + kdb_printf("%s", cp); + cp += len_tmp; + lastchar += len_tmp; + } } kdb_nextline = 1; /* reset output line number */ break; -- 2.34.1

2 1

[PATCH OLK-6.6] kdb: Fix buffer overflow during tab-complete
by Tengda Wu 08 Jul '24

08 Jul '24

From: Daniel Thompson <daniel.thompson(a)linaro.org> stable inclusion from stable-v6.6.34 commit 107e825cc448b7834b31e8b1b3cf0f57426d46d5 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAB05N CVE: CVE-2024-39480 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e9730744bf3af04cda23799029342aa3cddbc454 upstream. Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around. Reported-by: Justin Stitt <justinstitt(a)google.com> Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziU… Cc: stable(a)vger.kernel.org Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Reviewed-by: Justin Stitt <justinstitt(a)google.com> Tested-by: Justin Stitt <justinstitt(a)google.com> Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@lin… Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Fixes: 5d5314d6795f3c1c0f415348ff8c51f7de042b77 ("kdb: core for kgdb back end (1 of 2)") Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/debug/kdb/kdb_io.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c index 9443bc63c5a2..06dfbccb1033 100644 --- a/kernel/debug/kdb/kdb_io.c +++ b/kernel/debug/kdb/kdb_io.c @@ -367,14 +367,19 @@ static char *kdb_read(char *buffer, size_t bufsize) kdb_printf(kdb_prompt_str); kdb_printf("%s", buffer); } else if (tab != 2 && count > 0) { - len_tmp = strlen(p_tmp); - strncpy(p_tmp+len_tmp, cp, lastchar-cp+1); - len_tmp = strlen(p_tmp); - strncpy(cp, p_tmp+len, len_tmp-len + 1); - len = len_tmp - len; - kdb_printf("%s", cp); - cp += len; - lastchar += len; + /* How many new characters do we want from tmpbuffer? */ + len_tmp = strlen(p_tmp) - len; + if (lastchar + len_tmp >= bufend) + len_tmp = bufend - lastchar; + + if (len_tmp) { + /* + 1 ensures the '\0' is memmove'd */ + memmove(cp+len_tmp, cp, (lastchar-cp) + 1); + memcpy(cp, p_tmp+len, len_tmp); + kdb_printf("%s", cp); + cp += len_tmp; + lastchar += len_tmp; + } } kdb_nextline = 1; /* reset output line number */ break; -- 2.34.1

2 1

[PATCH OLK-5.10] kdb: Fix buffer overflow during tab-complete
by Tengda Wu 08 Jul '24

08 Jul '24

From: Daniel Thompson <daniel.thompson(a)linaro.org> stable inclusion from stable-v5.10.219 commit cfdc2fa4db57503bc6d3817240547c8ddc55fa96 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAB05N CVE: CVE-2024-39480 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e9730744bf3af04cda23799029342aa3cddbc454 upstream. Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around. Reported-by: Justin Stitt <justinstitt(a)google.com> Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziU… Cc: stable(a)vger.kernel.org Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Reviewed-by: Justin Stitt <justinstitt(a)google.com> Tested-by: Justin Stitt <justinstitt(a)google.com> Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@lin… Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Fixes: 5d5314d6795f3c1c0f415348ff8c51f7de042b77 ("kdb: core for kgdb back end (1 of 2)") Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/debug/kdb/kdb_io.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c index 6735ac36b718..dcc7e13e98b3 100644 --- a/kernel/debug/kdb/kdb_io.c +++ b/kernel/debug/kdb/kdb_io.c @@ -354,14 +354,19 @@ static char *kdb_read(char *buffer, size_t bufsize) kdb_printf(kdb_prompt_str); kdb_printf("%s", buffer); } else if (tab != 2 && count > 0) { - len_tmp = strlen(p_tmp); - strncpy(p_tmp+len_tmp, cp, lastchar-cp+1); - len_tmp = strlen(p_tmp); - strncpy(cp, p_tmp+len, len_tmp-len + 1); - len = len_tmp - len; - kdb_printf("%s", cp); - cp += len; - lastchar += len; + /* How many new characters do we want from tmpbuffer? */ + len_tmp = strlen(p_tmp) - len; + if (lastchar + len_tmp >= bufend) + len_tmp = bufend - lastchar; + + if (len_tmp) { + /* + 1 ensures the '\0' is memmove'd */ + memmove(cp+len_tmp, cp, (lastchar-cp) + 1); + memcpy(cp, p_tmp+len, len_tmp); + kdb_printf("%s", cp); + cp += len_tmp; + lastchar += len_tmp; + } } kdb_nextline = 1; /* reset output line number */ break; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] kdb: Fix buffer overflow during tab-complete
by Tengda Wu 08 Jul '24

08 Jul '24

From: Daniel Thompson <daniel.thompson(a)linaro.org> stable inclusion from stable-v4.19.316 commit fb824a99e148ff272a53d71d84122728b5f00992 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAB05N CVE: CVE-2024-39480 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e9730744bf3af04cda23799029342aa3cddbc454 upstream. Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around. Reported-by: Justin Stitt <justinstitt(a)google.com> Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziU… Cc: stable(a)vger.kernel.org Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Reviewed-by: Justin Stitt <justinstitt(a)google.com> Tested-by: Justin Stitt <justinstitt(a)google.com> Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@lin… Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Fixes: 5d5314d6795f3c1c0f415348ff8c51f7de042b77 ("kdb: core for kgdb back end (1 of 2)") Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/debug/kdb/kdb_io.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c index 6a4b41484afe..2ce307c86977 100644 --- a/kernel/debug/kdb/kdb_io.c +++ b/kernel/debug/kdb/kdb_io.c @@ -364,14 +364,19 @@ static char *kdb_read(char *buffer, size_t bufsize) kdb_printf(kdb_prompt_str); kdb_printf("%s", buffer); } else if (tab != 2 && count > 0) { - len_tmp = strlen(p_tmp); - strncpy(p_tmp+len_tmp, cp, lastchar-cp+1); - len_tmp = strlen(p_tmp); - strncpy(cp, p_tmp+len, len_tmp-len + 1); - len = len_tmp - len; - kdb_printf("%s", cp); - cp += len; - lastchar += len; + /* How many new characters do we want from tmpbuffer? */ + len_tmp = strlen(p_tmp) - len; + if (lastchar + len_tmp >= bufend) + len_tmp = bufend - lastchar; + + if (len_tmp) { + /* + 1 ensures the '\0' is memmove'd */ + memmove(cp+len_tmp, cp, (lastchar-cp) + 1); + memcpy(cp, p_tmp+len, len_tmp); + kdb_printf("%s", cp); + cp += len_tmp; + lastchar += len_tmp; + } } kdb_nextline = 1; /* reset output line number */ break; -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] fix CVE-2024-39481
by Hongbo Li 08 Jul '24

08 Jul '24

Fix CVE-2024-39481. Tomi Valkeinen (1): media: mc: Fix graph walk in media_pipeline_start drivers/media/mc/mc-entity.c | 6 ++++++ 1 file changed, 6 insertions(+) -- 2.34.1

2 2

[PATCH OLK-6.6] KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked
by Zizhi Wo 08 Jul '24

08 Jul '24

From: Sean Christopherson <seanjc(a)google.com> stable inclusion from stable-v6.6.34 commit f79edaf7370986d73d204b36c50cc563a4c0f356 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAB16D CVE: CVE-2024-39483 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit b4bd556467477420ee3a91fbcba73c579669edc6 upstream. When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly). Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small). That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. And KVM has allowed simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 ("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be modified without a *really* good reason to do so, and if KVM's behavior were to be modified, it should be done irrespective of vNMI support. Fixes: fa4c027a7956 ("KVM: x86: Add support for SVM's Virtual NMI") Cc: stable(a)vger.kernel.org Cc: Santosh Shukla <Santosh.Shukla(a)amd.com> Cc: Maxim Levitsky <mlevitsk(a)redhat.com> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-ID: <20240522021435.1684366-1-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- arch/x86/kvm/svm/svm.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 8adb6e31c113..1424eb898028 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3860,16 +3860,27 @@ static void svm_enable_nmi_window(struct kvm_vcpu *vcpu) struct vcpu_svm *svm = to_svm(vcpu); /* - * KVM should never request an NMI window when vNMI is enabled, as KVM - * allows at most one to-be-injected NMI and one pending NMI, i.e. if - * two NMIs arrive simultaneously, KVM will inject one and set - * V_NMI_PENDING for the other. WARN, but continue with the standard - * single-step approach to try and salvage the pending NMI. + * If NMIs are outright masked, i.e. the vCPU is already handling an + * NMI, and KVM has not yet intercepted an IRET, then there is nothing + * more to do at this time as KVM has already enabled IRET intercepts. + * If KVM has already intercepted IRET, then single-step over the IRET, + * as NMIs aren't architecturally unmasked until the IRET completes. + * + * If vNMI is enabled, KVM should never request an NMI window if NMIs + * are masked, as KVM allows at most one to-be-injected NMI and one + * pending NMI. If two NMIs arrive simultaneously, KVM will inject one + * NMI and set V_NMI_PENDING for the other, but if and only if NMIs are + * unmasked. KVM _will_ request an NMI window in some situations, e.g. + * if the vCPU is in an STI shadow or if GIF=0, KVM can't immediately + * inject the NMI. In those situations, KVM needs to single-step over + * the STI shadow or intercept STGI. */ - WARN_ON_ONCE(is_vnmi_enabled(svm)); + if (svm_get_nmi_mask(vcpu)) { + WARN_ON_ONCE(is_vnmi_enabled(svm)); - if (svm_get_nmi_mask(vcpu) && !svm->awaiting_iret_completion) - return; /* IRET will cause a vm exit */ + if (!svm->awaiting_iret_completion) + return; /* IRET will cause a vm exit */ + } /* * SEV-ES guests are responsible for signaling when a vCPU is ready to -- 2.39.2

2 1

[openeuler:OLK-6.6 3342/10598] include/linux/pgplib.h:36:23: error: field has incomplete type 'enum pgp_key_version'
by kernel test robot 08 Jul '24

08 Jul '24

tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: 01c2a11a75f4f8b273ef3e34cca3974b10314a3a commit: 43d4042e06d2bf96adf67d25e8d91653507a4cf9 [3342/10598] KEYS: Provide a function to load keys from a PGP keyring blob config: arm64-randconfig-r131-20240707 (https://download.01.org/0day-ci/archive/20240708/202407081638.r5xQjyqM-lkp@…) compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project a0c6b8aef853eedaa0980f07c0a502a5a8a9740e) reproduce: (https://download.01.org/0day-ci/archive/20240708/202407081638.r5xQjyqM-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/202407081638.r5xQjyqM-lkp@intel.com/ Note: the openeuler/OLK-6.6 HEAD 01c2a11a75f4f8b273ef3e34cca3974b10314a3a builds fine. It only hurts bisectability. All errors (new ones prefixed by >>): In file included from crypto/asymmetric_keys/pgp_preload.c:19: include/linux/pgplib.h:26:15: warning: declaration of 'enum pgp_packet_tag' will not be visible outside of this function [-Wvisibility] 26 | enum pgp_packet_tag type, | ^ >> include/linux/pgplib.h:36:23: error: field has incomplete type 'enum pgp_key_version' 36 | enum pgp_key_version version : 8; | ^ include/linux/pgplib.h:36:7: note: forward declaration of 'enum pgp_key_version' 36 | enum pgp_key_version version : 8; | ^ >> include/linux/pgplib.h:37:23: error: field has incomplete type 'enum pgp_pubkey_algo' 37 | enum pgp_pubkey_algo pubkey_algo : 8; | ^ include/linux/pgplib.h:37:7: note: forward declaration of 'enum pgp_pubkey_algo' 37 | enum pgp_pubkey_algo pubkey_algo : 8; | ^ crypto/asymmetric_keys/pgp_preload.c:63:10: warning: declaration of 'enum pgp_packet_tag' will not be visible outside of this function [-Wvisibility] 63 | enum pgp_packet_tag type, u8 headerlen, | ^ crypto/asymmetric_keys/pgp_preload.c:63:25: error: variable has incomplete type 'enum pgp_packet_tag' 63 | enum pgp_packet_tag type, u8 headerlen, | ^ crypto/asymmetric_keys/pgp_preload.c:63:10: note: forward declaration of 'enum pgp_packet_tag' 63 | enum pgp_packet_tag type, u8 headerlen, | ^ crypto/asymmetric_keys/pgp_preload.c:107:36: error: use of undeclared identifier 'PGP_PKT_PUBLIC_KEY' 107 | ctx.pgp.types_of_interest = (1 << PGP_PKT_PUBLIC_KEY); | ^ >> crypto/asymmetric_keys/pgp_preload.c:108:25: error: incompatible function pointer types assigning to 'int (*)(struct pgp_parse_context *, enum pgp_packet_tag, u8, const u8 *, size_t)' (aka 'int (*)(struct pgp_parse_context *, enum pgp_packet_tag, unsigned char, const unsigned char *, unsigned long)') from 'int (struct pgp_parse_context *, enum pgp_packet_tag, u8, const u8 *, size_t)' (aka 'int (struct pgp_parse_context *, enum pgp_packet_tag, unsigned char, const unsigned char *, unsigned long)') [-Wincompatible-function-pointer-types] 108 | ctx.pgp.process_packet = found_pgp_key; | ^ ~~~~~~~~~~~~~ crypto/asymmetric_keys/pgp_preload.c:101:12: warning: no previous prototype for function 'preload_pgp_keys' [-Wmissing-prototypes] 101 | int __init preload_pgp_keys(const u8 *pgpdata, size_t pgpdatalen, | ^ crypto/asymmetric_keys/pgp_preload.c:101:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 101 | int __init preload_pgp_keys(const u8 *pgpdata, size_t pgpdatalen, | ^ | static 3 warnings and 5 errors generated. -- In file included from crypto/asymmetric_keys/pgp_public_key.c:19: In file included from include/linux/mpi.h:21: In file included from include/linux/scatterlist.h:8: In file included from include/linux/mm.h:2193: include/linux/vmstat.h:522:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 522 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ In file included from crypto/asymmetric_keys/pgp_public_key.c:20: include/linux/pgplib.h:26:15: warning: declaration of 'enum pgp_packet_tag' will not be visible outside of this function [-Wvisibility] 26 | enum pgp_packet_tag type, | ^ >> include/linux/pgplib.h:36:23: error: field has incomplete type 'enum pgp_key_version' 36 | enum pgp_key_version version : 8; | ^ include/linux/pgplib.h:36:7: note: forward declaration of 'enum pgp_key_version' 36 | enum pgp_key_version version : 8; | ^ >> include/linux/pgplib.h:37:23: error: field has incomplete type 'enum pgp_pubkey_algo' 37 | enum pgp_pubkey_algo pubkey_algo : 8; | ^ include/linux/pgplib.h:37:7: note: forward declaration of 'enum pgp_pubkey_algo' 37 | enum pgp_pubkey_algo pubkey_algo : 8; | ^ crypto/asymmetric_keys/pgp_public_key.c:63:2: error: call to undeclared function 'kenter'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 63 | kenter(""); | ^ crypto/asymmetric_keys/pgp_public_key.c:65:22: error: use of undeclared identifier 'PGP_KEY_VERSION_4' 65 | n = (pgp->version < PGP_KEY_VERSION_4) ? 8 : 6; | ^ crypto/asymmetric_keys/pgp_public_key.c:67:9: error: call to undeclared function 'mpi_key_length'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 67 | ret = mpi_key_length(key_ptr, keylen, nb + i, nn + i); | ^ crypto/asymmetric_keys/pgp_public_key.c:95:21: error: use of undeclared identifier 'PGP_KEY_VERSION_4' 95 | if (pgp->version < PGP_KEY_VERSION_4) { | ^ crypto/asymmetric_keys/pgp_public_key.c:115:2: error: call to undeclared function 'kleave'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 115 | kleave(" = %d", ret); | ^ crypto/asymmetric_keys/pgp_public_key.c:134:42: error: use of undeclared identifier 'PGP_KEY_VERSION_4' 134 | tfm = crypto_alloc_shash(pgp->version < PGP_KEY_VERSION_4 ? | ^ crypto/asymmetric_keys/pgp_public_key.c:191:2: error: call to undeclared function 'kleave'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 191 | kleave(" = %d", ret); | ^ crypto/asymmetric_keys/pgp_public_key.c:199:12: warning: declaration of 'enum pgp_packet_tag' will not be visible outside of this function [-Wvisibility] 199 | enum pgp_packet_tag type, | ^ crypto/asymmetric_keys/pgp_public_key.c:199:27: error: variable has incomplete type 'enum pgp_packet_tag' 199 | enum pgp_packet_tag type, | ^ crypto/asymmetric_keys/pgp_public_key.c:199:12: note: forward declaration of 'enum pgp_packet_tag' 199 | enum pgp_packet_tag type, | ^ crypto/asymmetric_keys/pgp_public_key.c:211:2: error: call to undeclared function 'kenter'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 211 | kenter(",%u,%u,,%zu", type, headerlen, datalen); | ^ >> crypto/asymmetric_keys/pgp_public_key.c:213:14: error: use of undeclared identifier 'PGP_PKT_USER_ID' 213 | if (type == PGP_PKT_USER_ID) { | ^ crypto/asymmetric_keys/pgp_public_key.c:216:3: error: call to undeclared function 'kleave'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 216 | kleave(" = 0 [user ID]"); | ^ crypto/asymmetric_keys/pgp_public_key.c:221:3: error: call to undeclared function 'kleave'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 221 | kleave(" = -ENOKEY [already]"); | ^ >> crypto/asymmetric_keys/pgp_public_key.c:234:25: error: use of undeclared identifier 'PGP_PUBKEY__LAST' 234 | if (pgp.pubkey_algo >= PGP_PUBKEY__LAST) | ^ >> crypto/asymmetric_keys/pgp_public_key.c:236:9: error: use of undeclared identifier 'pgp_to_public_key_algo' 236 | algo = pgp_to_public_key_algo[pgp.pubkey_algo]; | ^ crypto/asymmetric_keys/pgp_public_key.c:252:2: error: call to undeclared function 'kleave'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 252 | kleave(" = 0 [use]"); | ^ crypto/asymmetric_keys/pgp_public_key.c:310:2: error: call to undeclared function 'kenter'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 310 | kenter(""); | ^ >> crypto/asymmetric_keys/pgp_public_key.c:313:36: error: use of undeclared identifier 'PGP_PKT_PUBLIC_KEY' 313 | ctx.pgp.types_of_interest = (1 << PGP_PKT_PUBLIC_KEY) | | ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 3 warnings and 20 errors generated. Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for PGP_KEY_PARSER Depends on [n]: CRYPTO [=y] && ASYMMETRIC_KEY_TYPE [=y] && ASYMMETRIC_PUBLIC_KEY_SUBTYPE [=n] Selected by [y]: - PGP_PRELOAD [=y] && CRYPTO [=y] && ASYMMETRIC_KEY_TYPE [=y] vim +36 include/linux/pgplib.h b78af6579e15dc David Howells 2023-09-12 31 b78af6579e15dc David Howells 2023-09-12 32 extern int pgp_parse_packets(const u8 *data, size_t datalen, b78af6579e15dc David Howells 2023-09-12 33 struct pgp_parse_context *ctx); b78af6579e15dc David Howells 2023-09-12 34 b78af6579e15dc David Howells 2023-09-12 35 struct pgp_parse_pubkey { b78af6579e15dc David Howells 2023-09-12 @36 enum pgp_key_version version : 8; b78af6579e15dc David Howells 2023-09-12 @37 enum pgp_pubkey_algo pubkey_algo : 8; b78af6579e15dc David Howells 2023-09-12 38 __kernel_old_time_t creation_time; b78af6579e15dc David Howells 2023-09-12 39 __kernel_old_time_t expires_at; b78af6579e15dc David Howells 2023-09-12 40 }; b78af6579e15dc David Howells 2023-09-12 41 :::::: The code at line 36 was first introduced by commit :::::: b78af6579e15dcdff86504da90af77f3e890270e PGPLIB: Basic packet parser :::::: TO: David Howells <dhowells(a)redhat.com> :::::: CC: zgzxx <zhangguangzhi3(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0