fastalloc 1.5.0

High-performance memory pooling library with type-safe handles, predictable latency, and zero fragmentation. Perfect for game engines, real-time systems, and high-churn workloads.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97

# Security Policy

## Supported Versions

The following versions of fastalloc are currently supported with security updates:

| Version | Supported          |
| ------- | ------------------ |
| 0.1.x   | :white_check_mark: |

## Reporting a Vulnerability

We take security seriously. If you discover a security vulnerability in fastalloc, please report it responsibly.

### How to Report

**Please do not report security vulnerabilities through public GitHub issues.**

Instead, please send an email to: **eshanized@proton.me**

Include the following information:

- Type of vulnerability
- Full description of the vulnerability
- Steps to reproduce or proof of concept
- Potential impact
- Suggested fix (if any)

### What to Expect

- **Acknowledgment**: Within 48 hours of submission
- **Initial Assessment**: Within 7 days
- **Status Updates**: Every 7 days until resolution
- **Fix Timeline**: We aim to release fixes for critical vulnerabilities within 30 days

### Disclosure Policy

- We request that you give us reasonable time to fix the vulnerability before public disclosure
- We will acknowledge your contribution in the security advisory (unless you prefer to remain anonymous)
- Once fixed, we will publish a security advisory

## Security Best Practices

When using fastalloc:

1. **Keep Updated**: Always use the latest version
2. **Review Dependencies**: Use `cargo audit` regularly
3. **Bounds Checking**: Enable debug assertions during development
4. **Statistics**: Use the `stats` feature to monitor for unusual allocation patterns
5. **Thread Safety**: Use appropriate pool types for your concurrency needs

## Known Security Considerations

### Memory Safety

- fastalloc minimizes `unsafe` code
- All `unsafe` blocks are documented with safety invariants
- Debug builds include additional runtime checks
- Miri testing is part of our CI pipeline

### Thread Safety

- Thread-safe pools use proper synchronization
- Thread-local pools explicitly prevent cross-thread usage
- No data races possible with safe API usage

### Resource Exhaustion

- Pool exhaustion returns errors rather than panicking
- Maximum capacity limits can prevent unbounded growth
- Statistics help detect resource exhaustion patterns

## Security Hardening

Optional features for enhanced security:

```toml
[dependencies]
fastalloc = { version = "0.1", features = ["stats"] }
```

Monitor allocation patterns to detect:
- Unusual allocation rates
- Memory exhaustion attempts
- Resource leaks

## Hall of Fame

We appreciate responsible disclosure. Contributors will be listed here:

- (No vulnerabilities reported yet)

## Contact

For security-related questions: eshanized@proton.me

For general questions: Open an issue on GitHub at https://github.com/TIVerse/fastalloc/issues