New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fortify scan of some Abseil libraries #940
Comments
Do you have any links or details for those reports?
Many static analysis checks are (shall we say) blunt instruments. We can
say bluntly "strcpy is error prone", which may be true, but if the uses of
strcpy are already audited and battle tested, there isn't particularly any
value in making substantive changes here.
Having more details on what is being reported (and under what models we
believe there is severity) would help. Many such reports we field are
strictly false-positives - I can't count how many times people have
complained about a bogus diagnostic warning. (For example: warnings about
non-standard feature reliance, triggering on lines that are conditionally
compiled only based on detecting compilers known to implement said feature.)
…On Wed, Apr 14, 2021 at 9:45 AM tombmantle ***@***.***> wrote:
Hello abseil devs,
My company has been testing some various logging, string manip libraries
and abseil has come up in the discussion. We are required to run fortify
scans on our code and to use C++11 for a certain project, and can not have
and "CAT I" issues in our code.
Small disclaimer, I'm aware that fortify is far from perfect, and that
abseil has ported some C++11 compatible C++17.
I scanned several abseil libraries and more than a few CAT I's (and CAT
II, can share if there is interest) have come up. Is this known by the
developers/has this been brought up before? Is this a concern in your
opinions?
Best,
Tom
Below are several examples, there are about a dozen more:
CAT I's
Format string buffer overflow vulnerabilities:
abseil/abseil-cpp/absl/synchronization/mutex.cc:433 Sink: snprintf()
Enclosing Method: PostSynchEvent()
Type mismatch overflow vulnerability:
1 abseil/abseil-cpp/absl/numeric/bits.h:136 Sink: ReturnStatement
Enclosing Method: bit_width()
2 abseil/abseil-cpp/absl/strings/charconv.cc:249 Sink: ReturnStatement
Enclosing Method: bit_width()
3 abseil/abseil-cpp/absl/strings/escaping.cc:314 Sink: AssignmentStatement
Enclosing Method: CEscapeInternal()
4 abseil/abseil-cpp/absl/strings/escaping.cc:378 Sink: AssignmentStatement
Enclosing Method: CEscapedLength()
5 abseil/abseil-cpp/absl/strings/escaping.cc:394 Sink: AssignmentStatement
Enclosing Method: CEscapeAndAppendInternal()
6 abseil/abseil-cpp/absl/strings/escaping.cc:503 Sink: AssignmentStatement
Enclosing Method: Base64UnescapeInternal()
7 abseil/abseil-cpp/absl/strings/internal/charconv_parse.cc:193 Sink:
ReturnStatement Enclosing Method: ToDigit()
8 abseil/abseil-cpp/absl/base/internal/low_level_alloc.cc:335 Sink:
ReturnStatement Enclosing Method: GetPageSize()
9 abseil/abseil-cpp/absl/hash/internal/city.cc:233 Sink:
AssignmentStatement Enclosing Method: HashLen0to16()
10 abseil/abseil-cpp/absl/hash/internal/city.cc:234 Sink:
AssignmentStatement Enclosing Method: HashLen0to16()
11 abseil/abseil-cpp/absl/hash/internal/city.cc:235 Sink:
AssignmentStatement Enclosing Method: HashLen0to16()
12 abseil/abseil-cpp/absl/strings/numbers.cc:218 Sink: ReturnStatement
Enclosing Method: FastHexToBufferZeroPad16()
13 abseil/abseil-cpp/absl/strings/internal/str_format/extension.cc:62
Sink: AssignmentStatement Enclosing Method: PutPaddedString()
14 abseil/abseil-cpp/absl/strings/internal/str_format/arg.cc:168 Sink:
AssignmentStatement Enclosing Method: without_neg_or_zero()
15 abseil/abseil-cpp/absl/time/internal/cctz/src/time_zone_info.cc:625
Sink: AssignmentStatement
Enclosing Method: Open()
16 abseil/abseil-cpp/absl/time/internal/cctz/src/time_zone_info.cc:674
Sink: AssignmentStatement
Enclosing Method: Open()
17 abseil/abseil-cpp/absl/synchronization/mutex.cc:348 Sink: strcpy()
Enclosing Method: EnsureSynchEvent
18 abseil/abseil-cpp/absl/strings/numbers.cc:495 Sink: strcpy() Enclosing
Method: SixDigitsToBuffer()
19 abseil/abseil-cpp/absl/strings/numbers.cc:495 Sink: strcpy() Enclosing
Method: SixDigitsToBuffer()
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#940>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC7CRX22N6Q7WT5MJ7ACUG3TIWL65ANCNFSM425NWVQQ>
.
--
*If you get an email from me outside of the 9-5 it is *not* because I'm
always on or expect an immediate response from you; it is because of work
flexibility
<http://www.inc.com/john-boitnott/how-flexible-hours-can-create-a-better-work-life-balance.html>
. Evening and weekend emails are a sign I allocated some regular working
hours for other things (such as family, gym, friends,...). And I encourage
you to feel free to do the same.
|
Titus, I appreciate your response. I'll add that I just also realized that the gcc we are using is apparently more advanced than the max version that fortify officially supports, so you can consider this as a potential DOUBLE false positive. I'm getting gcc 5. installed on our scanning system ASAP and will re-post the results at that point. Fortify is blunt, and I gave the full reports that are given for each issue... there is a developer workbook that give automated long and generic responses about "this is a stack overflow attack" with simple examples and explanations as well. The previous message is as precise as the output gets for the absl Assuming that things are somewhat okay in our scan considering the compiler issue, the precise details of the scan are pretty straight forward. I compiled our code with the static analysis flags relevant for running fortify, with adding absl::strings to target_link_libraries of the main executable. I was just interested in what fortify would have to say about the lib, I didn't test any functionality. I'll post an update as soon as I rescan with a definitely compatible compiler. |
Sounds good, I'm interested to hear what you find.
Broadly: if there are legitimate bugs, we'll fix 'em. If small changes can
be made that allow these libraries to be used in more contexts, that's
often good - but we'll have to balance the quality of the reporting tool
vs. runtime pessimization + maintainability + code clarity. (That is, we
may choose to not prioritize conformance with a ill-designed static
analysis check if that would have maintainability or runtime costs.)
…On Wed, Apr 14, 2021 at 10:51 AM tombmantle ***@***.***> wrote:
Titus, I appreciate your response. I'll add that I just also realized that
the gcc we are using is apparently more advanced than the max version that
fortify officially supports, so you can consider this as a potential DOUBLE
false positive. I'm getting gcc 5. installed on our scanning system ASAP
and will re-post the results at that point.
Fortify is blunt, and I gave the full reports that are given for each
issue... there is a developer workbook that give automated long and generic
responses about "this is a stack overflow attack" with simple examples and
explanations as well. The previous message is as precise as the output gets
for the absl issues.
Assuming that things are somewhat okay in our scan considering the
compiler issue, the precise details of the scan are pretty straight
forward. I compiled our code with the static analysis flags relevant for
running fortify, with adding absl::strings to target_link_libraries of the
main executable. I was just interested in what fortify would have to say
about the lib, I didn't test any functionality. I'll post an update as soon
as I rescan with a definitely compatible compiler.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#940 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC7CRX74KZSMWJGV4PSJBYTTIWTYDANCNFSM425NWVQQ>
.
--
*If you get an email from me outside of the 9-5 it is *not* because I'm
always on or expect an immediate response from you; it is because of work
flexibility
<http://www.inc.com/john-boitnott/how-flexible-hours-can-create-a-better-work-life-balance.html>
. Evening and weekend emails are a sign I allocated some regular working
hours for other things (such as family, gym, friends,...). And I encourage
you to feel free to do the same.
|
This comment has been minimized.
This comment has been minimized.
I don't think there's much difference in the results for gcc > 4.9 in the scan. Here are the remaining issues that were pointed out -- which I completely agree may be the result of an ill designed check, but may be of some mild interest to devs. At the very least it may be worth considering that people would like to use this library and have certain requirements for code conformance from "larger customers" -- and the use cases of abseil may increase if reports on such static analyses were available directly on some site or repo. This isn't a suggestion, more of a comment. Anyway -- here are the remaining issues: abseil-cpp/absl/flags/internal/program_name.cc:53 Sink: program_name = operator new(...) abseil-cpp/absl/random/internal/pool_urbg.cc:197 Sink: memory = malloc(...) abseil-cpp/absl/flags/internal/flag.h:102 Sink: Dereferenced : 0 abseil-cpp/absl/random/internal/seed_material.cc:132 Sink: dev_urandom = open(...) abseil-cpp/absl/time/internal/cctz/ abseil-cpp/absl/time/internal/cctz/src/time_zone_info.cc:647 Sink: fp = FOpen(...) abseil-cpp/absl/random/internal/pool_urbg.cc:197 Sink: memory = malloc(...) : malloc may return NULL abseil-cpp/absl/time/internal/cctz/src/time_zone_format.cc:912 Sink: ParseTM(data, ?, ?) : ParseTM may return NULL Enclosing Method: parse() abseil/abseil-cpp/absl/synchronization/mutex.cc:2057 Sink: Dereferenced : waitp CAT I "input handling vulnerabilities" abseil-cpp/absl/base/internal/low_level_alloc.cc:162 Sink: Assignment to prev[] abseil-cpp/absl/base/internal/low_level_alloc.cc:162 Sink: Assignment to prev[] Enclosing Method: LLA_SkiplistSearch() Source: sysconf() from absl::debugging_internal. SymbolizerSize() In abseil/abseil-cpp/absl/debugging/symbolize_elf.inc:355 abseil-cpp/absl/debugging/symbolize_elf.inc:419 Sink: read() Enclosing Method: ReadPersistent() abseil-cpp/absl/synchronization/internal/graphcycles.cc:96 Sink: Assignment to this->ptr_[] Enclosing Method: push_back() Source: mmap() from absl::base_internal.DoAllocWithArena() In /abseil-cpp/absl/base/internal/low_level_alloc.cc:562 all cases of strcpy, stlen, strmp, snprintf, GetPageSize() |
I've patched this one. The fix should be appearing on GitHub soon. The rest of the issues do not appear to be legitimate bugs. As @tituswinters mentioned, we will accept patches for the rest of the warning if the patches do not complicate or pessimize the code. However, we are unable to prioritize silencing the rest of the warning ourselves. |
Hey Derek, thanks for checking out the issues. I'm glad that the fortify report was worth reading over for you all -- and I fully understand that engineering fixes for all of those is not a priority. It's something that our company may at some point in the future consider making a branch for. Best, |
-- ac1df60490c9583e475e22de7adfc40023196fbf by Martijn Vels <mvels@google.com>: Change Cord constructor(string_view) to explicit make_tree and Cordz tracking This CL changes the ctor to use an easier to maintain model where Cord code explicitly invokes Cordz update or new / tree logic, which avoids the ambiguity of the 'branched' InlineRep::set_tree code. This removes the need to equip InlineRep with 'MethodIdentifier' or other necessary call info, and also is a cleaner model: InlineRep is carrying too much code now that should plainly sit in Cord, especially with all internal abstractions having moved to InlineData. See child CL(s) for desired state PiperOrigin-RevId: 369433619 -- b665af7f586e6c679a8b27d4f78d5a1d2b596058 by Abseil Team <absl-team@google.com>: Rename the 'Compare' template type to 'LessThan', as the passed-in function is expected to act like operator<. It is worth avoiding confusion with std::compare, which returns an int (-1/0/1), as due to implicit casting this can lead to hard-to-spot bugs. PiperOrigin-RevId: 369391118 -- c3c775269cad0f4982ec63f3616dd78bb9e52dca by Martijn Vels <mvels@google.com>: Integrate CordzUpdateTracker into CordzInfo PiperOrigin-RevId: 369348824 -- 771d81ed357496c117179e1daec76eba5155932d by Martijn Vels <mvels@google.com>: Replace mutex() with Lock() / Unlock() function Mini design future tracking of CordzInfo sampled cords: CordzInfo holds a CordRep* reference without a reference count. Cord is responsible for synchronizing updates for sampled cords such that the CordRep* contained in CordzInfo is at all times valid. This is done by scoping Lock() and Unlock() calls around the code modifying the code of a sampled cord. For example (using the future CL CordzUpdateScope()): CordzInfo* cordz_info = get_cordz_info(); CordzUpdateScope scope(cordz_info, CordzUpdateTracker::kRemovePrefix); CordRep* rep = RemovePrefixImpl(root); set_tree(rep); if (cordz_info) { cordz_info->SetCordRep(rep); } On CordzInfo::Unlock(), if the internal rep is null, the cord is no longer sampled, and CordzInfo will be deleted. Thus any update resulting in the Cord being inlined will automatically no longer be sampled. PiperOrigin-RevId: 369338802 -- 5563c12df04a1e965a03b50bdd032739c55c0706 by Martijn Vels <mvels@google.com>: Add UpdateTracker to CordzStatistics PiperOrigin-RevId: 369318178 -- 6b4d8463722a3e55a3e8f6cb3741a41055e7f83e by Martijn Vels <mvels@google.com>: Add kClear, kConstructor* and kUnknown values and fix typo PiperOrigin-RevId: 369297163 -- 041adcbc929789d6d53371a8236840fc350e1eeb by Derek Mauro <dmauro@google.com>: Switch from malloc to operator new in pool_urbg.cc so it can only fail by throwing/aborting PiperOrigin-RevId: 369274087 -- 5d97a5f43e3f2d02d0a5bbe586d93b5751812981 by Benjamin Barenblat <bbaren@google.com>: Correct Thumb function bound computation in the symbolizer On 32-bit ARM, all functions are aligned to multiples of two bytes, and the lowest-order bit in a function’s address is ignored by the CPU when computing branch targets. That bit is still present in instructions and ELF symbol tables, though; it’s repurposed to indicate whether the function contains ARM or Thumb code. If the symbolizer doesn’t ignore that bit, it will believe Thumb functions have boundaries that are off by one byte, so instruct the symbolizer to null out the lowest-order bit after retrieving it from the symbol table. PiperOrigin-RevId: 369254082 -- 462bb307c6cc332c1e2c3adb5f0cad51804bf937 by Derek Mauro <dmauro@google.com>: Add a check for malloc failure in pool_urbg.cc GitHub #940 PiperOrigin-RevId: 369238100 GitOrigin-RevId: ac1df60490c9583e475e22de7adfc40023196fbf Change-Id: Ic6ec91c62cd3a0031f6a75a43a83da959ece2d25
If that branch isn't too messy, let us know. :)
…On Tue, Apr 20, 2021 at 12:14 PM tombmantle ***@***.***> wrote:
Hey Derek, thanks for checking out the issues. I'm glad that the fortify
report was worth reading over for you all -- and I fully understand that
engineering fixes for all of those is not a priority. It's something that
our company may at some point in the future consider making a branch for.
Best,
Tom
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#940 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC7CRX6DSRWHBXBSXOMIOSTTJWR6RANCNFSM425NWVQQ>
.
--
*If you get an email from me outside of the 9-5 it is *not* because I'm
always on or expect an immediate response from you; it is because of work
flexibility
<http://www.inc.com/john-boitnott/how-flexible-hours-can-create-a-better-work-life-balance.html>
. Evening and weekend emails are a sign I allocated some regular working
hours for other things (such as family, gym, friends,...). And I encourage
you to feel free to do the same.
|
-- ac1df60490c9583e475e22de7adfc40023196fbf by Martijn Vels <mvels@google.com>: Change Cord constructor(string_view) to explicit make_tree and Cordz tracking This CL changes the ctor to use an easier to maintain model where Cord code explicitly invokes Cordz update or new / tree logic, which avoids the ambiguity of the 'branched' InlineRep::set_tree code. This removes the need to equip InlineRep with 'MethodIdentifier' or other necessary call info, and also is a cleaner model: InlineRep is carrying too much code now that should plainly sit in Cord, especially with all internal abstractions having moved to InlineData. See child CL(s) for desired state PiperOrigin-RevId: 369433619 -- b665af7f586e6c679a8b27d4f78d5a1d2b596058 by Abseil Team <absl-team@google.com>: Rename the 'Compare' template type to 'LessThan', as the passed-in function is expected to act like operator<. It is worth avoiding confusion with std::compare, which returns an int (-1/0/1), as due to implicit casting this can lead to hard-to-spot bugs. PiperOrigin-RevId: 369391118 -- c3c775269cad0f4982ec63f3616dd78bb9e52dca by Martijn Vels <mvels@google.com>: Integrate CordzUpdateTracker into CordzInfo PiperOrigin-RevId: 369348824 -- 771d81ed357496c117179e1daec76eba5155932d by Martijn Vels <mvels@google.com>: Replace mutex() with Lock() / Unlock() function Mini design future tracking of CordzInfo sampled cords: CordzInfo holds a CordRep* reference without a reference count. Cord is responsible for synchronizing updates for sampled cords such that the CordRep* contained in CordzInfo is at all times valid. This is done by scoping Lock() and Unlock() calls around the code modifying the code of a sampled cord. For example (using the future CL CordzUpdateScope()): CordzInfo* cordz_info = get_cordz_info(); CordzUpdateScope scope(cordz_info, CordzUpdateTracker::kRemovePrefix); CordRep* rep = RemovePrefixImpl(root); set_tree(rep); if (cordz_info) { cordz_info->SetCordRep(rep); } On CordzInfo::Unlock(), if the internal rep is null, the cord is no longer sampled, and CordzInfo will be deleted. Thus any update resulting in the Cord being inlined will automatically no longer be sampled. PiperOrigin-RevId: 369338802 -- 5563c12df04a1e965a03b50bdd032739c55c0706 by Martijn Vels <mvels@google.com>: Add UpdateTracker to CordzStatistics PiperOrigin-RevId: 369318178 -- 6b4d8463722a3e55a3e8f6cb3741a41055e7f83e by Martijn Vels <mvels@google.com>: Add kClear, kConstructor* and kUnknown values and fix typo PiperOrigin-RevId: 369297163 -- 041adcbc929789d6d53371a8236840fc350e1eeb by Derek Mauro <dmauro@google.com>: Switch from malloc to operator new in pool_urbg.cc so it can only fail by throwing/aborting PiperOrigin-RevId: 369274087 -- 5d97a5f43e3f2d02d0a5bbe586d93b5751812981 by Benjamin Barenblat <bbaren@google.com>: Correct Thumb function bound computation in the symbolizer On 32-bit ARM, all functions are aligned to multiples of two bytes, and the lowest-order bit in a function’s address is ignored by the CPU when computing branch targets. That bit is still present in instructions and ELF symbol tables, though; it’s repurposed to indicate whether the function contains ARM or Thumb code. If the symbolizer doesn’t ignore that bit, it will believe Thumb functions have boundaries that are off by one byte, so instruct the symbolizer to null out the lowest-order bit after retrieving it from the symbol table. PiperOrigin-RevId: 369254082 -- 462bb307c6cc332c1e2c3adb5f0cad51804bf937 by Derek Mauro <dmauro@google.com>: Add a check for malloc failure in pool_urbg.cc GitHub abseil#940 PiperOrigin-RevId: 369238100 GitOrigin-RevId: ac1df60490c9583e475e22de7adfc40023196fbf Change-Id: Ic6ec91c62cd3a0031f6a75a43a83da959ece2d25
-- ac1df60490c9583e475e22de7adfc40023196fbf by Martijn Vels <mvels@google.com>: Change Cord constructor(string_view) to explicit make_tree and Cordz tracking This CL changes the ctor to use an easier to maintain model where Cord code explicitly invokes Cordz update or new / tree logic, which avoids the ambiguity of the 'branched' InlineRep::set_tree code. This removes the need to equip InlineRep with 'MethodIdentifier' or other necessary call info, and also is a cleaner model: InlineRep is carrying too much code now that should plainly sit in Cord, especially with all internal abstractions having moved to InlineData. See child CL(s) for desired state PiperOrigin-RevId: 369433619 -- b665af7f586e6c679a8b27d4f78d5a1d2b596058 by Abseil Team <absl-team@google.com>: Rename the 'Compare' template type to 'LessThan', as the passed-in function is expected to act like operator<. It is worth avoiding confusion with std::compare, which returns an int (-1/0/1), as due to implicit casting this can lead to hard-to-spot bugs. PiperOrigin-RevId: 369391118 -- c3c775269cad0f4982ec63f3616dd78bb9e52dca by Martijn Vels <mvels@google.com>: Integrate CordzUpdateTracker into CordzInfo PiperOrigin-RevId: 369348824 -- 771d81ed357496c117179e1daec76eba5155932d by Martijn Vels <mvels@google.com>: Replace mutex() with Lock() / Unlock() function Mini design future tracking of CordzInfo sampled cords: CordzInfo holds a CordRep* reference without a reference count. Cord is responsible for synchronizing updates for sampled cords such that the CordRep* contained in CordzInfo is at all times valid. This is done by scoping Lock() and Unlock() calls around the code modifying the code of a sampled cord. For example (using the future CL CordzUpdateScope()): CordzInfo* cordz_info = get_cordz_info(); CordzUpdateScope scope(cordz_info, CordzUpdateTracker::kRemovePrefix); CordRep* rep = RemovePrefixImpl(root); set_tree(rep); if (cordz_info) { cordz_info->SetCordRep(rep); } On CordzInfo::Unlock(), if the internal rep is null, the cord is no longer sampled, and CordzInfo will be deleted. Thus any update resulting in the Cord being inlined will automatically no longer be sampled. PiperOrigin-RevId: 369338802 -- 5563c12df04a1e965a03b50bdd032739c55c0706 by Martijn Vels <mvels@google.com>: Add UpdateTracker to CordzStatistics PiperOrigin-RevId: 369318178 -- 6b4d8463722a3e55a3e8f6cb3741a41055e7f83e by Martijn Vels <mvels@google.com>: Add kClear, kConstructor* and kUnknown values and fix typo PiperOrigin-RevId: 369297163 -- 041adcbc929789d6d53371a8236840fc350e1eeb by Derek Mauro <dmauro@google.com>: Switch from malloc to operator new in pool_urbg.cc so it can only fail by throwing/aborting PiperOrigin-RevId: 369274087 -- 5d97a5f43e3f2d02d0a5bbe586d93b5751812981 by Benjamin Barenblat <bbaren@google.com>: Correct Thumb function bound computation in the symbolizer On 32-bit ARM, all functions are aligned to multiples of two bytes, and the lowest-order bit in a function’s address is ignored by the CPU when computing branch targets. That bit is still present in instructions and ELF symbol tables, though; it’s repurposed to indicate whether the function contains ARM or Thumb code. If the symbolizer doesn’t ignore that bit, it will believe Thumb functions have boundaries that are off by one byte, so instruct the symbolizer to null out the lowest-order bit after retrieving it from the symbol table. PiperOrigin-RevId: 369254082 -- 462bb307c6cc332c1e2c3adb5f0cad51804bf937 by Derek Mauro <dmauro@google.com>: Add a check for malloc failure in pool_urbg.cc GitHub abseil#940 PiperOrigin-RevId: 369238100 GitOrigin-RevId: ac1df60490c9583e475e22de7adfc40023196fbf Change-Id: Ic6ec91c62cd3a0031f6a75a43a83da959ece2d25
Hello abseil devs,
My company has been testing some various logging, string manip libraries and abseil has come up in the discussion. We are required to run fortify scans on our code and to use C++11 for a certain project, and can not have and "CAT I" issues in our code.
Small disclaimer, I'm aware that fortify is far from perfect, and that abseil has ported some C++11 compatible C++17.
I scanned several abseil libraries and more than a few CAT I's (and CAT II, can share if there is interest) have come up. Is this known by the developers/has this been brought up before? Is this a concern in your opinions?
Best,
Tom
Below are several examples, there are about a dozen more:
CAT I's
Format string buffer overflow vulnerabilities:
abseil/abseil-cpp/absl/synchronization/mutex.cc:433 Sink: snprintf() Enclosing Method: PostSynchEvent()
Type mismatch overflow vulnerability:
1 abseil/abseil-cpp/absl/numeric/bits.h:136 Sink: ReturnStatement Enclosing Method: bit_width()
2 abseil/abseil-cpp/absl/strings/charconv.cc:249 Sink: ReturnStatement Enclosing Method: bit_width()
3 abseil/abseil-cpp/absl/strings/escaping.cc:314 Sink: AssignmentStatement Enclosing Method: CEscapeInternal()
4 abseil/abseil-cpp/absl/strings/escaping.cc:378 Sink: AssignmentStatement Enclosing Method: CEscapedLength()
5 abseil/abseil-cpp/absl/strings/escaping.cc:394 Sink: AssignmentStatement Enclosing Method: CEscapeAndAppendInternal()
6 abseil/abseil-cpp/absl/strings/escaping.cc:503 Sink: AssignmentStatement Enclosing Method: Base64UnescapeInternal()
7 abseil/abseil-cpp/absl/strings/internal/charconv_parse.cc:193 Sink: ReturnStatement Enclosing Method: ToDigit()
8 abseil/abseil-cpp/absl/base/internal/low_level_alloc.cc:335 Sink: ReturnStatement Enclosing Method: GetPageSize()
9 abseil/abseil-cpp/absl/hash/internal/city.cc:233 Sink: AssignmentStatement Enclosing Method: HashLen0to16()
10 abseil/abseil-cpp/absl/hash/internal/city.cc:234 Sink: AssignmentStatement Enclosing Method: HashLen0to16()
11 abseil/abseil-cpp/absl/hash/internal/city.cc:235 Sink: AssignmentStatement Enclosing Method: HashLen0to16()
12 abseil/abseil-cpp/absl/strings/numbers.cc:218 Sink: ReturnStatement Enclosing Method: FastHexToBufferZeroPad16()
13 abseil/abseil-cpp/absl/strings/internal/str_format/extension.cc:62 Sink: AssignmentStatement Enclosing Method: PutPaddedString()
14 abseil/abseil-cpp/absl/strings/internal/str_format/arg.cc:168 Sink: AssignmentStatement Enclosing Method: without_neg_or_zero()
15 abseil/abseil-cpp/absl/time/internal/cctz/src/time_zone_info.cc:625 Sink: AssignmentStatement
Enclosing Method: Open()
16 abseil/abseil-cpp/absl/time/internal/cctz/src/time_zone_info.cc:674 Sink: AssignmentStatement
Enclosing Method: Open()
17 abseil/abseil-cpp/absl/synchronization/mutex.cc:348 Sink: strcpy() Enclosing Method: EnsureSynchEvent
18 abseil/abseil-cpp/absl/strings/numbers.cc:495 Sink: strcpy() Enclosing Method: SixDigitsToBuffer()
19 abseil/abseil-cpp/absl/strings/numbers.cc:495 Sink: strcpy() Enclosing Method: SixDigitsToBuffer()
The text was updated successfully, but these errors were encountered: