- Kernel - mailweb.openeuler.org

[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: 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 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: 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 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 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