The following issues were found

src/third_party/mozjs-60/include/mozilla/Poison.h
1 issues
memcpy - Does not check for buffer overflows when copying to destination
Security

Line: 46 Column: 5 CWE codes: 120
Suggestion: Make sure destination can always hold the source data

                char* limit = p + (aSize & ~(sizeof(uintptr_t) - 1));
  MOZ_ASSERT(aSize >= sizeof(uintptr_t), "poisoning this object has no effect");
  for (; p < limit; p += sizeof(uintptr_t)) {
    memcpy(p, &POISON, sizeof(POISON));
  }
}

/**
 * Initialize the poison value.

            

Reported by FlawFinder.

src/third_party/mozjs-60/include/mozilla/SegmentedVector.h
1 issues
char - Statically-sized arrays can be improperly restricted, leading to potential overflows or other issues
Security

Line: 107 Column: 7 CWE codes: 119 120
Suggestion: Perform bounds checking, use functions that limit length, or ensure that the size is larger than the maximum possible length

                  // The union ensures that the elements are appropriately aligned.
    union Storage
    {
      char mBuf[sizeof(T) * SegmentCapacity];
      mozilla::AlignedElem<MOZ_ALIGNOF(T)> mAlign;
    } mStorage;

    static_assert(MOZ_ALIGNOF(T) == MOZ_ALIGNOF(Storage),
                  "SegmentedVector provides incorrect alignment");

            

Reported by FlawFinder.

src/third_party/mozjs-60/include/mozilla/Sprintf.h
1 issues
vsnprintf - If format strings can be influenced by an attacker, they can be exploited, and note that sprintf variations do not always \0-terminate
Security

Line: 25 Column: 18 CWE codes: 134
Suggestion: Use a constant for the format specification

              int VsprintfLiteral(char (&buffer)[N], const char* format, va_list args)
{
    MOZ_ASSERT(format != buffer);
    int result = vsnprintf(buffer, N, format, args);
    buffer[N - 1] = '\0';
    return result;
}

template <size_t N>

            

Reported by FlawFinder.

src/third_party/boost/boost/asio/detail/win_iocp_socket_service.hpp
1 issues
open - Check when opening files - can an attacker redirect it (via symlinks), force the opening of special file type (e.g., device files), move things around to create a race condition, control its ancestors, or change its contents?
Security

Line: 199 Column: 29 CWE codes: 362

                }

  // Open a new socket implementation.
  boost::system::error_code open(implementation_type& impl,
      const protocol_type& protocol, boost::system::error_code& ec)
  {
    if (!do_open(impl, protocol.family(),
          protocol.type(), protocol.protocol(), ec))
    {

            

Reported by FlawFinder.

src/third_party/mozjs-60/include/mozilla/Vector.h
1 issues
char - Statically-sized arrays can be improperly restricted, leading to potential overflows or other issues
Security

Line: 413 Column: 25 CWE codes: 119 120
Suggestion: Perform bounds checking, use functions that limit length, or ensure that the size is larger than the maximum possible length

                  {}
    CRAndStorage() = default;

    alignas(T) unsigned char mBytes[Capacity * sizeof(T)];

    // GCC fails due to -Werror=strict-aliasing if |mBytes| is directly cast to
    // T*.  Indirecting through this function addresses the problem.
    void* data() { return mBytes; }


            

Reported by FlawFinder.

src/third_party/mozjs-60/include/mozmemory_wrap.h
1 issues
memalign - On some systems (though not Linux-based systems) an attempt to free() results from memalign() may fail. This may, on a few systems, be exploitable. Also note that memalign() may not check that the boundary parameter is correct
Security

Line: 149 Column: 42 CWE codes: 676
Suggestion: Use posix_memalign instead (defined in POSIX's 1003.1d). Don't switch to valloc(); it is marked as obsolete in BSD 4.3, as legacy in SUSv2, and is no longer defined in SUSv3. In some cases, malloc()'s alignment may be sufficient

              #define calloc_impl mozmem_malloc_impl(calloc)
#define realloc_impl mozmem_malloc_impl(realloc)
#define free_impl mozmem_malloc_impl(free)
#define memalign_impl mozmem_malloc_impl(memalign)
#define valloc_impl mozmem_malloc_impl(valloc)
#define malloc_usable_size_impl mozmem_malloc_impl(malloc_usable_size)
#define malloc_good_size_impl mozmem_malloc_impl(malloc_good_size)

// Duplication functions

            

Reported by FlawFinder.

src/third_party/pcre-8.42/dftables.c
1 issues
fopen - Check when opening files - can an attacker redirect it (via symlinks), force the opening of special file type (e.g., device files), move things around to create a race condition, control its ancestors, or change its contents?
Security

Line: 87 Column: 5 CWE codes: 362

              tables = pcre_maketables();
base_of_tables = tables;

f = fopen(argv[i], "wb");
if (f == NULL)
  {
  fprintf(stderr, "dftables: failed to open %s for writing\n", argv[1]);
  return 1;
  }

            

Reported by FlawFinder.

src/third_party/pcre-8.42/pcre_dfa_exec.c
1 issues
memcpy - Does not check for buffer overflows when copying to destination
Security

Line: 548 Column: 7 CWE codes: 120
Suggestion: Make sure destination can always hold the source data

                  do { end_code += GET(end_code, 1); } while (*end_code == OP_ALT);
    new_count = workspace[1];
    if (!workspace[0])
      memcpy(new_states, active_states, new_count * sizeof(stateblock));
    }

  /* Not restarting */

  else

            

Reported by FlawFinder.

src/third_party/boost/boost/asio/detail/win_iocp_serial_port_service.hpp
1 issues
open - Check when opening files - can an attacker redirect it (via symlinks), force the opening of special file type (e.g., device files), move things around to create a race condition, control its ancestors, or change its contents?
Security

Line: 80 Column: 45 CWE codes: 362

                }

  // Open the serial port using the specified device name.
  BOOST_ASIO_DECL boost::system::error_code open(implementation_type& impl,
      const std::string& device, boost::system::error_code& ec);

  // Assign a native handle to a serial port implementation.
  boost::system::error_code assign(implementation_type& impl,
      const native_handle_type& handle, boost::system::error_code& ec)

            

Reported by FlawFinder.

src/third_party/pcre-8.42/pcre_study.c
1 issues
memcpy - Does not check for buffer overflows when copying to destination
Security

Line: 1594 Column: 5 CWE codes: 120
Suggestion: Make sure destination can always hold the source data

                if (bits_set)
    {
    study->flags |= PCRE_STUDY_MAPPED;
    memcpy(study->start_bits, start_bits, sizeof(start_bits));
    }
  else memset(study->start_bits, 0, 32 * sizeof(pcre_uint8));

#ifdef PCRE_DEBUG
  if (bits_set)

            

Reported by FlawFinder.