[PATCH] D97239: [profile] Fix buffer overrun when parsing %c in filename string

Dave Lee via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 24 14:27:49 PST 2021


kastiglione added inline comments.


================
Comment at: compiler-rt/lib/profile/InstrProfilingFile.c:740
+      ++I; /* Advance to the next character. */
+      if (getChar(FilenamePat, I, FilenamePatLen) == 'p') {
         if (!NumPids++) {
----------------
It might be nice to have reading a char be consistent across the cases. This first one uses `getChar(…)`, but the others use `FilenamePat[I]`. One option is a function like `bool checkBounds(…)`, then the for loop could have:

```
for (I = 0; checkBounds(I, FilenamePatLen) && FilenamePat[I]; ++I)
```

and then here:

```
++I; /* Advance to the next character. */
if (!checkBounds(I, FilenamePatLen))
  break;
if (FilenamePat[I] == 'p') {
```

Another option is to keep `getChar` and save its result to a variable, which each of the cases reuse rather than directly reading from the array. Given that these are case-like, this could be structured as  single read by doing `switch (getChar(…))` and then having each read be a `case 'c':` etc.


================
Comment at: compiler-rt/lib/profile/InstrProfilingFile.c:773
         __llvm_profile_set_page_size(getpagesize());
         __llvm_profile_enable_continuous_mode();
       } else {
----------------
vsk wrote:
> MaskRay wrote:
> > Adding `getChar` seems excessive. Does simply dropping `I++` here fix the bug?
> Yes. `getChar` adds a little complexity, but lets us write a test that reliably fails pre-patch. I think that's worth it.
So adding `getChar`, but not removing the `I++` causes test failure. And then leaving `getChar` also protects against future changes to the loop body?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97239/new/

https://reviews.llvm.org/D97239



More information about the llvm-commits mailing list