1. 16 Jan, 2018 1 commit
    • Marc-André Lureau's avatar
      crypto: fix stack-buffer-overflow error · 83e33300
      Marc-André Lureau authored
      ASAN complains about:
      
      ==8856==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd8a1fe168 at pc 0x561136cb4451 bp 0x7ffd8a1fe130 sp 0x7ffd8a1fd8e0
      READ of size 16 at 0x7ffd8a1fe168 thread T0
          #0 0x561136cb4450 in __asan_memcpy (/home/elmarco/src/qq/build/tests/test-crypto-ivgen+0x110450)
          #1 0x561136d2a6a7 in qcrypto_ivgen_essiv_calculate /home/elmarco/src/qq/crypto/ivgen-essiv.c:83:5
          #2 0x561136d29af8 in qcrypto_ivgen_calculate /home/elmarco/src/qq/crypto/ivgen.c:72:12
          #3 0x561136d07c8e in test_ivgen /home/elmarco/src/qq/tests/test-crypto-ivgen.c:148:5
          #4 0x7f77772c3b04 in test_case_run /home/elmarco/src/gnome/glib/builddir/../glib/gtestutils.c:2237
          #5 0x7f77772c3ec4 in g_test_run_suite_internal /home/elmarco/src/gnome/glib/builddir/../glib/gtestutils.c:2321
          #6 0x7f77772c3f6d in g_test_run_suite_internal /home/elmarco/src/gnome/glib/builddir/../glib/gtestutils.c:2333
          #7 0x7f77772c3f6d in g_test_run_suite_internal /home/elmarco/src/gnome/glib/builddir/../glib/gtestutils.c:2333
          #8 0x7f77772c3f6d in g_test_run_suite_internal /home/elmarco/src/gnome/glib/builddir/../glib/gtestutils.c:2333
          #9 0x7f77772c4184 in g_test_run_suite /home/elmarco/src/gnome/glib/builddir/../glib/gtestutils.c:2408
          #10 0x7f77772c2e0d in g_test_run /home/elmarco/src/gnome/glib/builddir/../glib/gtestutils.c:1674
          #11 0x561136d0799b in main /home/elmarco/src/qq/tests/test-crypto-ivgen.c:173:12
          #12 0x7f77756e6039 in __libc_start_main (/lib64/libc.so.6+0x21039)
          #13 0x561136c13d89 in _start (/home/elmarco/src/qq/build/tests/test-crypto-ivgen+0x6fd89)
      
      Address 0x7ffd8a1fe168 is located in stack of thread T0 at offset 40 in frame
          #0 0x561136d2a40f in qcrypto_ivgen_essiv_calculate /home/elmarco/src/qq/crypto/ivgen-essiv.c:76
      
        This frame has 1 object(s):
          [32, 40) 'sector.addr' <== Memory access at offset 40 overflows this variable
      HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
            (longjmp and C++ exceptions *are* supported)
      SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/elmarco/src/qq/build/tests/test-crypto-ivgen+0x110450) in __asan_memcpy
      Shadow bytes around the buggy address:
        0x100031437bd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x100031437be0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x100031437bf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x100031437c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x100031437c10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      =>0x100031437c20: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00[f3]f3 f3
        0x100031437c30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x100031437c40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x100031437c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x100031437c60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x100031437c70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      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
        Freed heap region:       fd
        Stack left redzone:      f1
        Stack mid redzone:       f2
        Stack right redzone:     f3
        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
        Left alloca redzone:     ca
        Right alloca redzone:    cb
      
      It looks like the rest of the code copes with ndata being larger than
      sizeof(sector), so limit the memcpy() range.
      Signed-off-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <20180104160523.22995-13-marcandre.lureau@redhat.com>
      Tested-by: 's avatarThomas Huth <thuth@redhat.com>
      Reviewed-by: 's avatarThomas Huth <thuth@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      83e33300
  2. 08 Nov, 2017 1 commit
  3. 06 Oct, 2017 2 commits
  4. 04 Sep, 2017 4 commits
  5. 31 Jul, 2017 1 commit
  6. 19 Jul, 2017 15 commits
  7. 11 Jul, 2017 1 commit
  8. 16 May, 2017 1 commit
  9. 09 May, 2017 2 commits
  10. 24 Apr, 2017 1 commit
  11. 27 Feb, 2017 2 commits
  12. 22 Dec, 2016 4 commits
  13. 21 Dec, 2016 2 commits
  14. 20 Oct, 2016 1 commit
    • Daniel P. Berrange's avatar
      crypto: fix initialization of gcrypt threading · 37316663
      Daniel P. Berrange authored
      The gcrypt threads implementation must be set before calling
      any other gcrypt APIs, especially gcry_check_version(),
      since that triggers initialization of the random pool. After
      that is initialized, changes to the threads impl won't be
      honoured by the random pool code. This means that gcrypt
      will think thread locking is needed and so try to acquire
      the random pool mutex, but this is NULL as no threads impl
      was set originally. This results in a crash in the random
      pool code.
      
      For the same reasons, we must set the gcrypt threads impl
      before calling gnutls_init, since that will also trigger
      gcry_check_version
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
      37316663
  15. 19 Oct, 2016 2 commits