Tags: abseil/abseil-cpp
Tags
Fix potential integer overflow in hash container create/resize (#1811) The sized constructors, reserve(), and rehash() methods of absl::{flat,node}_hash_{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container's backing store. Subsequent accesses to the container might then access out-of-bounds memory. The fix is in two parts: 1) Update max_size() to return the maximum number of items that can be stored in the container 2) Validate the size arguments to the constructors, reserve(), and rehash() methods, and abort the program when the argument is invalid We've looked at uses of these containers in Google codebases like Chrome, and determined this vulnerability is likely to be difficult to exploit. This is primarily because container sizes are rarely attacker-controlled. The bug was discovered by Dmitry Vyukov <dvyukov@google.com>.
Fix potential integer overflow in hash container create/resize (#1812) The sized constructors, reserve(), and rehash() methods of absl::{flat,node}_hash_{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container's backing store. Subsequent accesses to the container might then access out-of-bounds memory. The fix is in two parts: 1) Update max_size() to return the maximum number of items that can be stored in the container 2) Validate the size arguments to the constructors, reserve(), and rehash() methods, and abort the program when the argument is invalid We've looked at uses of these containers in Google codebases like Chrome, and determined this vulnerability is likely to be difficult to exploit. This is primarily because container sizes are rarely attacker-controlled. The bug was discovered by Dmitry Vyukov <dvyukov@google.com>.
Fix potential integer overflow in hash container create/resize (#1813) The sized constructors, reserve(), and rehash() methods of absl::{flat,node}_hash_{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container's backing store. Subsequent accesses to the container might then access out-of-bounds memory. The fix is in two parts: 1) Update max_size() to return the maximum number of items that can be stored in the container 2) Validate the size arguments to the constructors, reserve(), and rehash() methods, and abort the program when the argument is invalid We've looked at uses of these containers in Google codebases like Chrome, and determined this vulnerability is likely to be difficult to exploit. This is primarily because container sizes are rarely attacker-controlled. The bug was discovered by Dmitry Vyukov <dvyukov@google.com>.
Update GoogleTest dependency to 1.15.2 (#1736) This updates to a version of GoogleTest that fixes google/googletest#4581 for downstream users of rules_python Cherry-pick of d0159ea
Apply LTS transformations for 20240722 LTS branch (#1724)
Abseil LTS Branch, Jan 2024, Patch 2 (#1650) * Prevent overflow in absl::CEscape() Strings larger than 1 GiB on a platform with a 32-bit size_t could potentially overflow size_t in `CEscapedLength()`, resulting in an undersized allocation. The resulting write in `CEscapeAndAppendInternal()` would then write beyond the bounds of the output buffer. A second overflow, where the calculated escaped length is added to the size of the string being appended to, is also fixed. In both cases the program will now abort prior to the overflow. Credit goes to Ronald Crane (Zippenhop LLC) for reporting this issue. PiperOrigin-RevId: 607019573 Change-Id: I97bf246cde96102a793d2db49446cccae08abf59 * Workaround for NVIDIA C++ compiler being unable to parse variadic expansions in range of range-based for loop Fixes: #1629 PiperOrigin-RevId: 611131201 Change-Id: I787731e00207b544ee16055e6e0d323a5094a433 * Fix OSX support with CocoaPods and Xcode 15 PiperOrigin-RevId: 615090942 Change-Id: I7cc20a0129dcfbbddedd9e6d816bb6234bff14b3 * PR #1643: add xcprivacy to all subspecs Imported from GitHub PR #1643 Addressing comments at #1604 Add a xcprivacy subspec and have all other subspecs depend on it (option 1) Didn't going with option 3 because there are several levels of subspecs in abseil podspec, it's difficult to track whether all of them directly or indirectly depends on abseil/base/config or ensure they will continue to depend on it. Example of generated podsped: https://gist.github.com/HannahShiSFB/15d8fb6aa637f2781b7be4218d080f11 Merge 4405cdf into 4539c54 Merging this change closes #1643 COPYBARA_INTEGRATE_REVIEW=#1643 from HannahShiSFB:privacy-manifests 4405cdf PiperOrigin-RevId: 616914674 Change-Id: If56d5a4f1a7cc6f9fac7a2d8e95b55d140e645fc