Uploaded image for project: 'C++ Standard Library'
  1. C++ Standard Library
  2. STDCXX-581

purify reports uninitialized memory read in __rw_memattr

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.2.0
    • Fix Version/s: 4.2.1
    • Component/s: Test Driver
    • Labels:
      None
    • Patch Info:
      Patch Available
    • Severity:
      Incorrect Behavior

      Description

      __rw_memattr() checks that a specified block of memory is addressable for reading or writing. It takes a pointer and a length. If the length is _RWSTD_SIZE_MAX, then it is assumed that the pointer refers to a null terminated string and the number of bytes is counted via a call to memchr() or strchr(). Unfortunately, sof the formatted io functions in printf.cpp cause __rw_memattr() to unnecessarily touch uninitialized memory or even worse to look for the null terminator in a buffer that is not null terminated.

      An example of this is _rw_fmtlong(). It allocates a buffer of 130 chars and formats a long value into that buffer without null terminating the buffer [it appears that this is intentional]. It then calls _rw_fmtstr() on the result. Internally _rw_fmtstr() calls __rw_memattr() with _RWSTD_SIZE_MAX as the number of bytes to verify read/write access to. Because the buffer is not null terminated, the __rw_memattr() call could walk past the end of the array looking for a null terminator.

      I believe that the call to __rw_memattr() in _rw_fmtlong() should be getting the actual length of the string that is being formatted so as to avoid reading past the end of the source array. I see no reason to allow __rw_memattr() to go looking for a null terminator when we don't know that there is one there. This same problem occurs in _rw_fmtwstr() and _rw_fmtarray().

        Attachments

        1. stdcxx-581.patch
          2 kB
          Travis Vitek
        2. 0.char.log
          7 kB
          Travis Vitek

          Activity

            People

            • Assignee:
              vitek Travis Vitek
              Reporter:
              vitek Travis Vitek
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: