Skip to content

Fix/security audit clockring#94

Merged
TKorr merged 10 commits intomainfrom
fix/security-audit-clockring
Apr 18, 2026
Merged

Fix/security audit clockring#94
TKorr merged 10 commits intomainfrom
fix/security-audit-clockring

Conversation

@TKorr
Copy link
Copy Markdown
Contributor

@TKorr TKorr commented Apr 17, 2026

Description

Related Issue

Fixes #

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to change)
  • 📝 Documentation update
  • 🔧 Refactoring (no functional changes)
  • ⚡ Performance improvement
  • 🧪 Test addition or modification

How Has This Been Tested?

  • Unit tests
  • Integration tests
  • Manual testing

Test environment:

  • OS:
  • Rust version:

Checklist

  • My code follows the project's coding standards
  • I have run cargo fmt and cargo clippy
  • I have added tests for my changes
  • All new and existing tests pass (cargo test)
  • I have updated the documentation as needed
  • I have added an entry to CHANGELOG.md (if applicable)

Screenshots (if applicable)

Additional Notes

TKorr added 10 commits April 17, 2026 15:39
- Introduced `ClockRingError` for capacity-related errors, ensuring safe handling of excessive capacity requests.
- Added `MAX_CAPACITY` constant to limit the maximum capacity for `ClockRing`.
- Updated `ClockRing` and `ConcurrentClockRing` to support customizable hash builders, defaulting to `RandomState` for DoS resistance.
- Enhanced documentation to clarify usage and implications of closures in concurrent contexts.

This update improves robustness and flexibility in managing cache capacities and hash functions.
- Updated the internal index structure of `ClockRing` to use `std::collections::HashMap`, enhancing DoS resistance with the default `RandomState` hasher.
- Improved documentation to clarify the implications of using custom hashers and the behavior of the `insert` and `try_insert` methods regarding value dropping.
- Added error handling for allocation failures in `ClockRing`, ensuring robust management of capacity requests.

This change optimizes the cache's resilience against hash collision attacks while maintaining performance and clarity in usage.
- Modified the `step` function to safely handle a zero capacity case, returning `0` instead of panicking, ensuring totality and preventing potential release-mode crashes.
- Updated the `insert_swap` method to repair stale index entries instead of dropping values when an invariant is broken, enhancing robustness against state corruption.
- Added tests to verify the new behavior of `step` and the integrity of `insert_swap`, ensuring that the cache maintains correct state under edge cases.

These changes improve the reliability and safety of the `ClockRing` implementation, particularly in scenarios with malformed data or unexpected states.
- Updated the calculation of `bytes_per_entry` in the memory estimation to use `checked_div`, ensuring that it safely handles cases where the number of entries is zero, thus avoiding potential panics.
- This change enhances the robustness of the metrics reporting, particularly in scenarios where the cache may be empty, contributing to overall stability in performance monitoring.
…ements

- Added documentation on memory budgeting, clarifying that `ClockRing` limits the number of entries rather than the total byte footprint, and advising users to enforce a byte budget for variable-sized values.
- Introduced `KeysAreTrusted` struct to signal that a non-randomized hasher is safe for specific workloads, enhancing security against hash-collision DoS attacks.
- Updated `with_hasher` and `try_with_hasher` methods to require a `KeysAreTrusted` argument, making the trade-off explicit at the call site.
- Enhanced examples and documentation to guide users on appropriate hasher usage and the implications of key trustworthiness.

These changes improve the usability and security of the `ClockRing`, particularly in scenarios involving untrusted keys and variable-sized data.
…kRing

- Documented breaking change requiring `KeysAreTrusted` marker for `with_hasher` and `try_with_hasher` methods, enhancing security awareness for users opting out of the default hasher.
- Introduced `KeysAreTrusted` struct to signal safe usage of non-randomized hashers.
- Added `#[track_caller]` to `with_hasher` for improved panic reporting.
- Fixed silent value drops in `insert_swap` and ensured `step` handles zero capacity correctly.
- Expanded documentation with new sections on memory budgeting and timing side channels, guiding users on appropriate hasher usage and security implications.

These updates improve usability, security, and clarity in the `ClockRing` implementation.
…safety

- Introduced `ClockRing::try_clone`, a fallible clone method that surfaces allocator failures as `ClockRingError::AllocationFailed`, providing a safer alternative to the default `Clone::clone`.
- Updated the `ClockRing::clone` implementation to explicitly document its behavior and failure mode, guiding users on when to prefer `try_clone`.
- Enhanced exception safety in the `insert_swap` method to ensure that a panicking `K::Clone` during eviction does not leave the ring in an inconsistent state, preventing potential persistent panics in shared contexts.
- Added regression tests to verify the integrity of the `insert_swap` method under panic conditions, ensuring robust handling of edge cases.

These changes improve the reliability and usability of the `ClockRing`, particularly in scenarios involving untrusted keys and memory allocation failures.
- Improved exception safety in `insert_swap` and `pop_victim` methods to prevent persistent panics in `ConcurrentClockRing` when user-supplied `Hash` or `Eq` implementations panic during eviction.
- Adjusted the order of operations to remove the evictee's index entry before emptying the slot, ensuring that invariants are preserved even in the event of a panic.
- Added regression tests to verify that the ring maintains its integrity and state under panic conditions, enhancing robustness against transient failures.

These changes improve the reliability of the `ClockRing`, particularly in concurrent scenarios with untrusted keys.
- Introduced a hand-written `Debug` implementation for `ClockRing` to prevent sensitive data exposure in debug output, ensuring that keys and values are redacted.
- Updated `ConcurrentClockRing` with a similar `Debug` implementation, maintaining the same security considerations while acquiring the inner read lock.
- Enhanced the `insert_swap` method to return the caller's value when an invariant violation occurs, preventing silent drops and ensuring resource safety.
- Added regression tests to verify the integrity of the `insert_swap` method under state corruption scenarios and to confirm that the `Debug` implementations do not leak sensitive information.

These changes improve the security and robustness of the `ClockRing` implementation, particularly in contexts where sensitive data is involved.
…Ring

- Resolved silent value drops in `insert_swap` when the index pointed to an out-of-bounds slot, ensuring that caller values are returned and stale index entries are removed.
- Improved exception safety in eviction paths of `insert_swap` and `pop_victim` methods to prevent persistent panics in `ConcurrentClockRing` when user-defined `Hash` or `Eq` implementations panic.
- Updated `ClockRing` and `ConcurrentClockRing` `Debug` implementations to redact sensitive data, exposing only non-sensitive metrics when the `metrics` feature is enabled.
- Added regression tests to verify the integrity of the `insert_swap` method under various corruption scenarios and to ensure that the `Debug` implementations do not leak sensitive information.

These changes enhance the reliability and security of the `ClockRing`, particularly in concurrent scenarios and when handling sensitive data.
@TKorr TKorr merged commit c4d7c87 into main Apr 18, 2026
17 checks passed
@TKorr TKorr deleted the fix/security-audit-clockring branch April 18, 2026 15:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant