!117 arm64: fix segfault

From: @wangxiao65 
Reviewed-by: @wangbin224 
Signed-off-by: @wangbin224

0004-CVE-2019-1010180-Add-bfd_get_file_size-to-get-archive-element-size.patch

@@ -0,0 +1,78 @@
+From 8e2f54bcee7e3e8315d4a39a302eaf8e4389e07d Mon Sep 17 00:00:00 2001
+From: "H.J. Lu" <hjl.tools@gmail.com>
+Date: Tue, 30 May 2017 06:34:05 -0700
+Subject: [PATCH] Add bfd_get_file_size to get archive element size
+
+We can't use stat() to get archive element size.  Add bfd_get_file_size
+to get size for both normal files and archive elements.
+
+bfd/
+
+	PR binutils/21519
+	* bfdio.c (bfd_get_file_size): New function.
+	* bfd-in2.h: Regenerated.
+
+Conflict:1.remove changelog; 2.the folder binutils/ does not exist.
+Reference:https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8e2f54bcee7e3e8315d4a39a302eaf8e4389e07d
+
+---
+ gdb-7.6.patch | 43 +++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 43 insertions(+)
+
+diff --git a/gdb-7.6.patch b/gdb-7.6.patch
+index 106d164..b29ccc9 100644
+--- a/gdb-7.6.patch
++++ b/gdb-7.6.patch
+@@ -22,6 +22,49 @@ tar xvzmf gdb-7.6.tar.gz \
+ 
+ exit 0
+ 
++--- gdb-7.6/bfd/bfd-in2.h
+++++ gdb-7.6/bfd/bfd-in2.h
++@@ -1242,6 +1242,8 @@ long bfd_get_mtime (bfd *abfd);
++
++ file_ptr bfd_get_size (bfd *abfd);
++
+++file_ptr bfd_get_file_size (bfd *abfd);
+++
++ void *bfd_mmap (bfd *abfd, void *addr, bfd_size_type len,
++     int prot, int flags, file_ptr offset,
++     void **map_addr, bfd_size_type *map_len);
++--- gdb-7.6/bfd/bfdio.c
+++++ gdb-7.6/bfd/bfdio.c
++@@ -434,6 +434,29 @@ bfd_get_size (bfd *abfd)
++   return buf.st_size;
++ }
++
+++/*
+++FUNCTION
+++       bfd_get_file_size
+++
+++SYNOPSIS
+++       file_ptr bfd_get_file_size (bfd *abfd);
+++
+++DESCRIPTION
+++       Return the file size (as read from file system) for the file
+++       associated with BFD @var{abfd}.  It supports both normal files
+++       and archive elements.
+++
+++*/
+++
+++file_ptr
+++bfd_get_file_size (bfd *abfd)
+++{
+++  if (abfd->my_archive != NULL
+++      && !bfd_is_thin_archive (abfd->my_archive))
+++    return arelt_size (abfd);
+++
+++  return bfd_get_size (abfd);
+++}
++
++ /*
++ FUNCTION
+ --- gdb-7.6/libiberty/Makefile.in.orig
+ +++ gdb-7.6/libiberty/Makefile.in
+ @@ -175,6 +175,7 @@ REQUIRED_OFILES =							\
+-- 
+2.27.0
+

0005-CVE-2019-1010180-DWARF-reader-Reject-sections-with-invalid-sizes.patch

@@ -0,0 +1,144 @@
+From 950b74950f6020eda38647f22e9077ac7f68ca49 Mon Sep 17 00:00:00 2001
+From: Keith Seitz <keiths@redhat.com>
+Date: Wed, 16 Oct 2019 11:33:59 -0700
+Subject: [PATCH] DWARF reader: Reject sections with invalid sizes
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This is another fuzzer bug, gdb/23567.  This time, the fuzzer has
+specifically altered the size of .debug_str:
+
+$ eu-readelf -S objdump
+Section Headers:
+[Nr] Name                 Type         Addr             Off      Size     ES Flags Lk Inf Al
+[31] .debug_str           PROGBITS     0000000000000000 0057116d ffffffffffffffff  1 MS     0   0  1
+
+When this file is loaded into GDB, the DWARF reader crashes attempting
+to access the string table (or it may just store a bunch of nonsense):
+
+[gdb-8.3-6-fc30]
+$ gdb -nx -q objdump
+BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
+Reading symbols from /path/to/objdump...
+Segmentation fault (core dumped)
+
+Nick has already committed a BFD patch to issue the warning seen above.
+
+[gdb master 6acc1a0b]
+$ gdb -BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
+Reading symbols from /path/to/objdump...
+(gdb) inf func
+All defined functions:
+
+File ./../include/dwarf2.def:
+186:	const
+
+              8 *>(.:
+                     ;'@<40>B);
+747:	const
+
+              8 *<2A>(.:
+                     ;'@<40>B);
+701:	const
+
+              8 *<2A>D <20>
+                     (.:
+                        ;'@<40>B);
+71:	const
+
+              8 *(.:
+                    ;'@<40>B);
+/* and more gibberish  */
+
+Consider read_indirect_string_at_offset_from:
+
+static const char *
+read_indirect_string_at_offset_from (struct objfile *objfile,
+                                     bfd *abfd, LONGEST str_offset,
+                                     struct dwarf2_section_info *sect,
+                                     const char *form_name,
+                                     const char *sect_name)
+{
+  dwarf2_read_section (objfile, sect);
+  if (sect->buffer == NULL)
+    error (_("%s used without %s section [in module %s]"),
+           form_name, sect_name, bfd_get_filename (abfd));
+  if (str_offset >= sect->size)
+    error (_("%s pointing outside of %s section [in module %s]"),
+           form_name, sect_name, bfd_get_filename (abfd));
+  gdb_assert (HOST_CHAR_BIT == 8);
+  if (sect->buffer[str_offset] == '\0')
+    return NULL;
+  return (const char *) (sect->buffer + str_offset);
+}
+
+With sect_size being ginormous, the code attempts to access
+sect->buffer[GINORMOUS], and depending on the layout of memory,
+GDB either stores a bunch of gibberish strings or crashes.
+
+This is an attempt to mitigate this by implementing a similar approach
+used by BFD. In our case, we simply reject the section with the invalid
+length:
+
+$ ./gdb -nx -q objdump
+BFD: warning: /path/to/objdump has a corrupt section with a size (ffffffffffffffff) larger than the file size
+Reading symbols from /path/to/objdump...
+
+warning: Discarding section .debug_str which has a section size (ffffffffffffffff) larger than the file size [in module /path/to/objdump]
+DW_FORM_strp used without .debug_str section [in module /path/to/objdump]
+(No debugging symbols found in /path/to/objdump)
+(gdb)
+
+Unfortunately, I have not found a way to regression test this, since it
+requires poking ELF section headers.
+
+gdb/ChangeLog:
+2019-10-16  Keith Seitz  <keiths@redhat.com>
+
+	PR gdb/23567
+	* dwarf2read.c (dwarf2_per_objfile::locate_sections): Discard
+	sections whose size is greater than the file size.
+
+Change-Id: I896ac3b4eb2207c54e8e05c16beab3051d9b4b2f
+
+Conflict:1.remove changelog; 2.patch context adaptation; 
+	3.use sectp->name replace bfd_section_name (sectp);use abfd->filename replace bfd_get_filename.
+Reference:https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=950b74950f6020eda38647f22e9077ac7f68ca49
+
+---
+ gdb-7.6.patch | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+diff --git a/gdb-7.6.patch b/gdb-7.6.patch
+index b29ccc9..0989724 100644
+--- a/gdb-7.6.patch
++++ b/gdb-7.6.patch
+@@ -65,6 +65,24 @@ exit 0
+ 
+  /*
+  FUNCTION
++--- gdb-7.6/gdb/dwarf2read.c
+++++ gdb-7.6/gdb/dwarf2read.c
++@@ -1822,6 +1822,15 @@ dwarf2_locate_sections (bfd *abfd, asection *sectp, void *vnames)
++   if ((aflag & SEC_HAS_CONTENTS) == 0)
++     {
++     }
+++    else if (elf_section_data (sectp)->this_hdr.sh_size
+++          > bfd_get_file_size (abfd))
+++    {
+++      bfd_size_type size = elf_section_data (sectp)->this_hdr.sh_size;
+++      warning (_("Discarding section %s which has a section size (%s"
+++                ") larger than the file size [in module %s]"),
+++              sectp->name, phex_nz (size, sizeof (size)),
+++              abfd->filename);
+++    }
++   else if (section_is_p (sectp->name, &names->info))
++     {
++       dwarf2_per_objfile->info.asection = sectp;
+ --- gdb-7.6/libiberty/Makefile.in.orig
+ +++ gdb-7.6/libiberty/Makefile.in
+ @@ -175,6 +175,7 @@ REQUIRED_OFILES =							\
+-- 
+2.27.0
+

0006-arm64-fix-backtraces-of-KASAN-kernel-dumpfile-truncated.patch

@@ -0,0 +1,181 @@
+From 41f9396b3ec962121553a2e59027db7b08741321 Mon Sep 17 00:00:00 2001
+From: Ding Hui <dinghui@sangfor.com.cn>
+Date: Thu, 1 Dec 2022 11:59:33 +0800
+Subject: [PATCH] arm64: fix backtraces of KASAN kernel dumpfile truncated
+
+We met "bt" cmd on KASAN kernel vmcore display truncated backtraces
+like this:
+
+crash> bt
+PID: 4131   TASK: ffff8001521df000  CPU: 3   COMMAND: "bash"
+ #0 [ffff2000224b0cb0] machine_kexec_prepare at ffff2000200bff4c
+
+After digging the root cause, it turns out that arm64_in_kdump_text()
+found wrong bt->bptr at "machine_kexec" branch.
+
+If CONFIG_KASAN=y, disassemble machine_kexec() of KASAN vmlinux (gcc 7.3.0)
+like this:
+
+crash> dis -x machine_kexec
+0xffff2000200bff50 <machine_kexec>:     stp     x29, x30, [sp,#-208]!
+0xffff2000200bff54 <machine_kexec+0x4>: mov     x29, sp
+0xffff2000200bff58 <machine_kexec+0x8>: stp     x19, x20, [sp,#16]
+0xffff2000200bff5c <machine_kexec+0xc>: str     x24, [sp,#56]
+0xffff2000200bff60 <machine_kexec+0x10>:        str     x26, [sp,#72]
+0xffff2000200bff64 <machine_kexec+0x14>:        mov     x2, #0x8ab3
+0xffff2000200bff68 <machine_kexec+0x18>:        add     x1, x29, #0x70
+0xffff2000200bff6c <machine_kexec+0x1c>:        lsr     x1, x1, #3
+0xffff2000200bff70 <machine_kexec+0x20>:        movk    x2, #0x41b5, lsl #16
+0xffff2000200bff74 <machine_kexec+0x24>:        mov     x19, #0x200000000000
+0xffff2000200bff78 <machine_kexec+0x28>:        adrp    x3, 0xffff2000224b0000
+0xffff2000200bff7c <machine_kexec+0x2c>:        movk    x19, #0xdfff, lsl #48
+0xffff2000200bff80 <machine_kexec+0x30>:        add     x3, x3, #0xcb0
+0xffff2000200bff84 <machine_kexec+0x34>:        add     x4, x1, x19
+0xffff2000200bff88 <machine_kexec+0x38>:        stp     x2, x3, [x29,#112]
+0xffff2000200bff8c <machine_kexec+0x3c>:        adrp    x2, 0xffff2000200bf000 <swsusp_arch_resume+0x1e8>
+0xffff2000200bff90 <machine_kexec+0x40>:        add     x2, x2, #0xf50
+0xffff2000200bff94 <machine_kexec+0x44>:        str     x2, [x29,#128]
+0xffff2000200bff98 <machine_kexec+0x48>:        mov     w2, #0xf1f1f1f1
+0xffff2000200bff9c <machine_kexec+0x4c>:        str     w2, [x1,x19]
+0xffff2000200bffa0 <machine_kexec+0x50>:        mov     w2, #0xf200
+0xffff2000200bffa4 <machine_kexec+0x54>:        mov     w1, #0xf3f3f3f3
+0xffff2000200bffa8 <machine_kexec+0x58>:        movk    w2, #0xf2f2, lsl #16
+0xffff2000200bffac <machine_kexec+0x5c>:        stp     w2, w1, [x4,#4]
+
+We notice that:
+1. machine_kexec() start address is 0xffff2000200bff50
+2. the instruction at machine_kexec+0x44 store the same value
+   0xffff2000200bff50 (comes from 0xffff2000200bf000 + 0xf50)
+   into stack postion [x29,#128].
+
+When arm64_in_kdump_text() search LR from stack, it met
+0xffff2000200bff50 firstly, so got wrong bt->bptr.
+
+We know that the real LR is always great than the start address
+of a function, so let's fix it by change the search conditon to
+(*ptr > xxx_start) && (*ptr < xxx_end).
+
+[ dh: port for SDEI stack ]
+
+Signed-off-by: Ding Hui <dinghui@sangfor.com.cn>
+
+Index: crash-7.3.0/arm64.c
+===================================================================
+--- crash-7.3.0.orig/arm64.c
++++ crash-7.3.0/arm64.c
+@@ -3060,7 +3060,7 @@ arm64_in_kdump_text(struct bt_info *bt,
+ 	ms = machdep->machspec;
+ 	for (ptr = start - 8; ptr >= base; ptr--) {
+ 		if (bt->flags & BT_OPT_BACK_TRACE) {
+-			if ((*ptr >= ms->crash_kexec_start) &&
++			if ((*ptr > ms->crash_kexec_start) &&
+ 			    (*ptr < ms->crash_kexec_end) &&
+ 			    INSTACK(*(ptr - 1), bt)) {
+ 				bt->bptr = ((ulong)(ptr - 1) - (ulong)base)
+@@ -3069,7 +3069,7 @@ arm64_in_kdump_text(struct bt_info *bt,
+ 					fprintf(fp, "%lx: %lx (crash_kexec)\n", bt->bptr, *ptr);
+ 				return TRUE;
+ 			}
+-			if ((*ptr >= ms->crash_save_cpu_start) &&
++			if ((*ptr > ms->crash_save_cpu_start) &&
+ 			    (*ptr < ms->crash_save_cpu_end) &&
+ 			    INSTACK(*(ptr - 1), bt)) {
+ 				bt->bptr = ((ulong)(ptr - 1) - (ulong)base)
+@@ -3079,14 +3079,14 @@ arm64_in_kdump_text(struct bt_info *bt,
+ 				return TRUE;
+ 			}
+ 		} else {
+-			if ((*ptr >= ms->machine_kexec_start) && (*ptr < ms->machine_kexec_end)) {
++			if ((*ptr > ms->machine_kexec_start) && (*ptr < ms->machine_kexec_end)) {
+ 				bt->bptr = ((ulong)ptr - (ulong)base)
+ 					   + task_to_stackbase(bt->tc->task);
+ 				if (CRASHDEBUG(1))
+ 					fprintf(fp, "%lx: %lx (machine_kexec)\n", bt->bptr, *ptr);
+ 				return TRUE;
+ 			}
+-			if ((*ptr >= ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
++			if ((*ptr > ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
+ 				/*
+ 				 *  Stash the first crash_kexec frame in case the machine_kexec
+ 				 *  frame is not found.
+@@ -3100,7 +3100,7 @@ arm64_in_kdump_text(struct bt_info *bt,
+ 				}
+ 				continue;
+ 			}
+-			if ((*ptr >= ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
++			if ((*ptr > ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
+ 				bt->bptr = ((ulong)ptr - (ulong)base)
+ 					   + task_to_stackbase(bt->tc->task);
+ 				if (CRASHDEBUG(1))
+@@ -3149,7 +3149,7 @@ arm64_in_kdump_text_on_sdei_stack(struct
+ 
+ 	for (ptr = start - 8; ptr >= base; ptr--) {
+ 		if (bt->flags & BT_OPT_BACK_TRACE) {
+-			if ((*ptr >= ms->crash_kexec_start) &&
++			if ((*ptr > ms->crash_kexec_start) &&
+ 			    (*ptr < ms->crash_kexec_end) &&
+ 			    INSTACK(*(ptr - 1), bt)) {
+ 				bt->bptr = ((ulong)(ptr - 1) - (ulong)base) + stackbase;
+@@ -3159,7 +3159,7 @@ arm64_in_kdump_text_on_sdei_stack(struct
+ 				FREEBUF(stackbuf);
+ 				return TRUE;
+ 			}
+-			if ((*ptr >= ms->crash_save_cpu_start) &&
++			if ((*ptr > ms->crash_save_cpu_start) &&
+ 			    (*ptr < ms->crash_save_cpu_end) &&
+ 			    INSTACK(*(ptr - 1), bt)) {
+ 				bt->bptr = ((ulong)(ptr - 1) - (ulong)base) + stackbase;
+@@ -3170,7 +3170,7 @@ arm64_in_kdump_text_on_sdei_stack(struct
+ 				return TRUE;
+ 			}
+ 		} else {
+-			if ((*ptr >= ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
++			if ((*ptr > ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
+ 				bt->bptr = ((ulong)ptr - (ulong)base) + stackbase;
+ 				if (CRASHDEBUG(1))
+ 					fprintf(fp, "%lx: %lx (crash_kexec on IRQ stack)\n",
+@@ -3178,7 +3178,7 @@ arm64_in_kdump_text_on_sdei_stack(struct
+ 				FREEBUF(stackbuf);
+ 				return TRUE;
+ 			}
+-			if ((*ptr >= ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
++			if ((*ptr > ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
+ 				bt->bptr = ((ulong)ptr - (ulong)base) + stackbase;
+ 				if (CRASHDEBUG(1))
+ 					fprintf(fp, "%lx: %lx (crash_save_cpu on IRQ stack)\n",
+@@ -3222,7 +3222,7 @@ arm64_in_kdump_text_on_irq_stack(struct
+ 
+ 	for (ptr = start - 8; ptr >= base; ptr--) {
+ 		if (bt->flags & BT_OPT_BACK_TRACE) {
+-			if ((*ptr >= ms->crash_kexec_start) &&
++			if ((*ptr > ms->crash_kexec_start) &&
+ 			    (*ptr < ms->crash_kexec_end) &&
+ 			    INSTACK(*(ptr - 1), bt)) {
+ 				bt->bptr = ((ulong)(ptr - 1) - (ulong)base) + stackbase;
+@@ -3232,7 +3232,7 @@ arm64_in_kdump_text_on_irq_stack(struct
+ 				FREEBUF(stackbuf);
+ 				return TRUE;
+ 			}
+-			if ((*ptr >= ms->crash_save_cpu_start) &&
++			if ((*ptr > ms->crash_save_cpu_start) &&
+ 			    (*ptr < ms->crash_save_cpu_end) &&
+ 			    INSTACK(*(ptr - 1), bt)) {
+ 				bt->bptr = ((ulong)(ptr - 1) - (ulong)base) + stackbase;
+@@ -3243,7 +3243,7 @@ arm64_in_kdump_text_on_irq_stack(struct
+ 				return TRUE;
+ 			}
+ 		} else {
+-			if ((*ptr >= ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
++			if ((*ptr > ms->crash_kexec_start) && (*ptr < ms->crash_kexec_end)) {
+ 				bt->bptr = ((ulong)ptr - (ulong)base) + stackbase;
+ 				if (CRASHDEBUG(1))
+ 					fprintf(fp, "%lx: %lx (crash_kexec on IRQ stack)\n", 
+@@ -3251,7 +3251,7 @@ arm64_in_kdump_text_on_irq_stack(struct
+ 				FREEBUF(stackbuf);
+ 				return TRUE;
+ 			}
+-			if ((*ptr >= ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
++			if ((*ptr > ms->crash_save_cpu_start) && (*ptr < ms->crash_save_cpu_end)) {
+ 				bt->bptr = ((ulong)ptr - (ulong)base) + stackbase;
+ 				if (CRASHDEBUG(1))
+ 					fprintf(fp, "%lx: %lx (crash_save_cpu on IRQ stack)\n", 

0007-arm64-Fix-again-segfault-in-arm64_is_kernel_exceptio.patch

@@ -0,0 +1,47 @@
+From 6c8cd9b5dcf48221e5f75fc5850bb4719d77acce Mon Sep 17 00:00:00 2001
+From: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
+Date: Wed, 7 Jun 2023 18:37:34 +0900
+Subject: [PATCH] arm64: Fix again segfault in
+ arm64_is_kernel_exception_frame() when corrupt stack pointer address is given
+
+This is the second trial from the commit
+9868ebc8e648e5791764a51567a23efae7170d9b that was reverted at the
+previous commit.
+
+As described in the previous commit, result of STACK_OFFSET_TYPE() can
+be an address out of bt->stackbuf and hence the address needs to be
+checked prior to being referred to as an pt_regs object.
+
+So, to fix the issue, let's check if stkptr points to within the range
+of the kernel stack first.
+
+[ kh: added a warning at Lianbo's suggestion ]
+
+Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
+
+Conflict: Adapat patch context
+Reference: https://github.com/crash-utility/crash/commit/6c8cd9b5dcf48221e5f75fc5850bb4719d77acce
+---
+ arm64.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/arm64.c b/arm64.c
+index efbdccb..67b1a22 100644
+--- a/arm64.c
++++ b/arm64.c
+@@ -1844,6 +1844,12 @@ arm64_is_kernel_exception_frame(struct bt_info *bt, ulong stkptr)
+ {
+         struct arm64_pt_regs *regs;
+ 
++	if (stkptr > STACKSIZE() && !INSTACK(stkptr, bt)) {
++		if (CRASHDEBUG(1))
++			error(WARNING, "stkptr: %lx is outside the kernel stack range\n", stkptr);
++		return FALSE;
++	}
++
+         regs = (struct arm64_pt_regs *)&bt->stackbuf[(ulong)(STACK_OFFSET_TYPE(stkptr))];
+ 
+ 	if (INSTACK(regs->sp, bt) && INSTACK(regs->regs[29], bt) && 
+-- 
+2.33.0
+

0008-arm64-fix-a-potential-segfault-when-unwind-frame.patch

@@ -0,0 +1,71 @@
+From af895b219876b293d551e6dec825aba3905c0588 Mon Sep 17 00:00:00 2001
+From: "qiwu.chen" <qiwu.chen@transsion.com>
+Date: Wed, 24 Jul 2024 01:36:09 +0000
+Subject: [PATCH] arm64: fix a potential segfault when unwind frame
+
+The range of frame->fp is checked insufficiently, which may lead to a wrong
+next fp. As a result, bt->stackbuf will be accessed out of range, and segfault.
+
+  crash> bt
+  [Detaching after fork from child process 11409]
+  PID: 7661     TASK: ffffff81858aa500  CPU: 4    COMMAND: "sh"
+   #0 [ffffffc008003f50] local_cpu_stop at ffffffdd7669444c
+
+  Thread 1 "crash" received signal SIGSEGV, Segmentation fault.
+  0x00005555558266cc in arm64_unwind_frame (bt=0x7fffffffd8f0, frame=0x7fffffffd080) at
+  arm64.c:2821
+  2821            frame->fp = GET_STACK_ULONG(fp);
+  (gdb) bt
+  arm64.c:2821
+  out>) at main.c:1338
+  gdb_interface.c:81
+  (gdb) p /x *(struct bt_info*) 0x7fffffffd8f0
+  $3 = {task = 0xffffff81858aa500, flags = 0x0, instptr = 0xffffffdd76694450, stkptr =
+  0xffffffc008003f40, bptr = 0x0, stackbase = 0xffffffc027288000,
+    stacktop = 0xffffffc02728c000, stackbuf = 0x555556115a40, tc = 0x55559d16fdc0, hp = 0x0,
+  textlist = 0x0, ref = 0x0, frameptr = 0xffffffc008003f50,
+    call_target = 0x0, machdep = 0x0, debug = 0x0, eframe_ip = 0x0, radix = 0x0, cpumask =
+  0x0}
+  (gdb) p /x *(struct arm64_stackframe*) 0x7fffffffd080
+  $4 = {fp = 0xffffffc008003f50, sp = 0xffffffc008003f60, pc = 0xffffffdd76694450}
+  crash> bt -S 0xffffffc008003f50
+  PID: 7661     TASK: ffffff81858aa500  CPU: 4    COMMAND: "sh"
+  bt: non-process stack address for this task: ffffffc008003f50
+      (valid range: ffffffc027288000 - ffffffc02728c000)
+
+Check frame->fp value sufficiently before access it. Only frame->fp within
+the range of bt->stackbase and bt->stacktop will be regarded as valid.
+
+Signed-off-by: qiwu.chen <qiwu.chen@transsion.com>
+
+Conflict: NA
+Reference: https://github.com/crash-utility/crash/commit/af895b219876b293d551e6dec825aba3905c0588
+---
+ arm64.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/arm64.c b/arm64.c
+index b3040d7..624dba2 100644
+--- a/arm64.c
++++ b/arm64.c
+@@ -2814,7 +2814,7 @@ arm64_unwind_frame(struct bt_info *bt, struct arm64_stackframe *frame)
+ 	low  = frame->sp;
+ 	high = (low + stack_mask) & ~(stack_mask);
+ 
+-	if (fp < low || fp > high || fp & 0xf)
++	if (fp < low || fp > high || fp & 0xf || !INSTACK(fp, bt))
+ 		return FALSE;
+ 
+ 	frame->sp = fp + 0x10;
+@@ -3024,7 +3024,7 @@ arm64_unwind_frame_v2(struct bt_info *bt, struct arm64_stackframe *frame,
+ 	low  = frame->sp;
+ 	high = (low + stack_mask) & ~(stack_mask);
+ 
+-	if (fp < low || fp > high || fp & 0xf)
++	if (fp < low || fp > high || fp & 0xf || !INSTACK(fp, bt))
+ 		return FALSE;
+ 
+ 	if (CRASHDEBUG(1))
+-- 
+2.33.0
+

crash.spec

@@ -1,15 +1,21 @@
 Name: crash
 Version: 7.2.8
-Release: 1
+Release: 6
 Summary: Linux kernel crash utility.
 License: GPLv3
-URL: https://github.com/crash-utility/crash
-Source0: https://github.com/crash-utility/crash/archive//%{name}-%{version}.tar.gz
+URL: https://crash-utility.github.io
+Source0: https://github.com/crash-utility/crash/archive/%{version}.tar.gz#/%{name}-%{version}.tar.gz
+Source1: http://ftp.gnu.org/gnu/gdb/gdb-7.6.tar.gz
 
-Patch0: lzo_snappy.patch
-Patch1: use_system_readline_v3.patch
-Patch2: add-SDEI-stack-resolution.patch
-Patch3: fix-bitmap_len-calculation-overflow-problem-in-large.patch
+Patch0: 0000-lzo_snappy.patch
+Patch1: 0001-use_system_readline_v3.patch
+Patch2: 0002-add-SDEI-stack-resolution.patch
+Patch3: 0003-fix-bitmap_len-calculation-overflow-problem-in-large.patch
+Patch4: 0004-CVE-2019-1010180-Add-bfd_get_file_size-to-get-archive-element-size.patch
+Patch5: 0005-CVE-2019-1010180-DWARF-reader-Reject-sections-with-invalid-sizes.patch
+Patch6: 0006-arm64-fix-backtraces-of-KASAN-kernel-dumpfile-truncated.patch
+Patch7: 0007-arm64-Fix-again-segfault-in-arm64_is_kernel_exceptio.patch
+Patch8: 0008-arm64-fix-a-potential-segfault-when-unwind-frame.patch
 
 BuildRequires: ncurses-devel zlib-devel lzo-devel snappy-devel
 BuildRequires: gcc gcc-c++ bison readline-devel
@@ -43,7 +49,8 @@ created by manufacturer-specific firmware.
 %autosetup -n %{name}-%{version} -p1
 
 %build
-make RPMPKG="%{version}-%{release}" CFLAGS="%{optflags}" LDFLAGS="%{build_ldflags}"
+cp %{SOURCE1} .
+make -j RPMPKG="%{version}-%{release}" CFLAGS="%{optflags}" LDFLAGS="%{build_ldflags}"
 
 %install
 rm -rf %{buildroot}
@@ -74,6 +81,22 @@ install -D -m 0644 defs.h %{buildroot}%{_includedir}/%{name}/defs.h
 %{_mandir}/man8/crash.8*
 
 %changelog
+* Tue Nov 12 2024 wangxiao <wangxiao184@h-partners.com> - 7.2.8-6
+- arm64: fix again segfault in arm64_is_kernel_exception_frame
+  arm64: fix a potential segfault when unwind frame
+
+* Thu Dec 1 2022 Ding Hui <dinghui@sangfor.com.cn> - 7.2.8-5
+- fix backtraces of arm64 KASAN kernel dumpfile truncated
+
+* Fri Oct 14 2022 chenhaixiang <chenhaixiang3@huawei.com> - 7.2.8-4
+- fix gdb CVE-2019-1010180
+
+* Mon May 10 2021 shixuantong <shixuantong@huawei.com> - 7.2.8-3
+- add -j option for building efficiency optimization
+
+* Sat Dec 12 2020 shixuantong <shixuantong@huawei.com> - 7.2.8-2
+- Update Source0, URL, add Source1 and update tarball from upstream release
+
 * Mon Aug 3 2020 chengquan <chengquan3@huawei.com> - 7.2.8-1
 - Update software to v7.2.8