Description of problem:

in function ``RemoveSectionType`` line 665 of jpgfile.c , when ``a`` equals ``0`` ``SectionsRead`` equals ``SectionsAllocated``, ``memmove`` will move memory start from ``Sections+1`` end with ``Sections+SectionsAllocated``, bigger than allocated memory, will cause an heap-buffer-overflow.

Version-Release number of selected component (if applicable):
3.04

How reproducible:
stable

Steps to Reproduce:
1.git clone the code from https://salsa.debian.org/debian/jhead/, or from the upstream.

2.compile the code with ASAN
3.run ./jhead poc

Actual results:
=================================================================
==3122==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60e00000e000 at pc 0x7fe1beefadf8 bp 0x7ffdde5ea610 sp 0x7ffdde5e9db8
READ of size 160 at 0x60e00000e000 thread T0
    #0 0x7fe1beefadf7 in __asan_memmove (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x8cdf7)
    #1 0x40922f in memmove /usr/include/x86_64-linux-gnu/bits/string3.h:59
    #2 0x40922f in RemoveSectionType /home/ubuntu/jhead-3.04/jpgfile.c:665
    #3 0x40e00a in create_EXIF /home/ubuntu/jhead-3.04/exif.c:1193
    #4 0x405bc4 in ProcessFile /home/ubuntu/jhead-3.04/jhead.c:974
    #5 0x4025d5 in main /home/ubuntu/jhead-3.04/jhead.c:1756
    #6 0x7fe1be7bb82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #7 0x403b08 in _start (/home/ubuntu/jhead-3.04/jhead+0x403b08)

0x60e00000e000 is located 0 bytes to the right of 160-byte region [0x60e00000df60,0x60e00000e000)
allocated by thread T0 here:
    #0 0x7fe1bef06961 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98961)
    #1 0x407143 in CheckSectionsAllocated /home/ubuntu/jhead-3.04/jpgfile.c:108

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 __asan_memmove
Shadow bytes around the buggy address:
  0x0c1c7fff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff9bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff9be0: fa fa fa fa fa fa fa fa fa fa fa fa 00 00 00 00
  0x0c1c7fff9bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c1c7fff9c00:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff9c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff9c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1c7fff9c50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==3122==ABORTING


Expected results:


Additional info:
We have reported to the upstream, but the upstream is not active responsive, so we post the bug here