security-audit-fpga-transformer.md

Security Audit Report: ruvector-fpga-transformer

Date: 2026-01-04 Auditor: Code Review Agent Crate: ruvector-fpga-transformer v0.1.0 Location: /home/user/ruvector/crates/ruvector-fpga-transformer

Executive Summary

This security audit identified 3 critical, 7 medium, and 4 low severity issues in the FPGA transformer backend crate. The most severe issues involve unsafe memory operations in FFI boundaries, unbounded memory allocations from untrusted input, and potential integer overflows in quantization code.

Recommendation: Address all critical issues before production deployment. The crate handles hardware access and cryptographic operations, making security paramount.

---

Critical Issues (Must Fix)

C-1: Unsafe FFI Memory Allocation Can Panic

File: src/ffi/c_abi.rs Lines: 169, 186, 241, 249 Severity: CRITICAL

Issue:

// Line 169
let ptr = unsafe {
    std::alloc::alloc(std::alloc::Layout::array::<i16>(logits_len).unwrap())
        as *mut i16
};

// Line 186
let ptr = unsafe {
    std::alloc::alloc(std::alloc::Layout::array::<u32>(len).unwrap()) as *mut u32
};

.unwrap() on Layout::array() will panic if logits_len or len cause integer overflow when computing the allocation size. This can happen with malicious or corrupted input from C callers.

Attack Vector:

1. C caller passes extremely large tokens_len or creates oversized logits
2. Layout::array::<i16>(logits_len).unwrap() panics on overflow
3. Entire Rust process crashes, causing denial of service

Impact:

• Process crash (panic across FFI boundary)
• Undefined behavior in C caller
• Potential memory corruption

Fix:

// Use checked allocation
let layout = std::alloc::Layout::array::<i16>(logits_len)
    .map_err(|_| FpgaResult::AllocationFailed)?;
let ptr = unsafe { std::alloc::alloc(layout) as *mut i16 };
if ptr.is_null() {
    return error_result_with_status(FpgaResult::AllocationFailed);
}

---

C-2: Unbounded Memory Allocation from Untrusted Input

File: src/artifact/pack.rs Lines: 96-104, 111-114, 123-126, 133-164 Severity: CRITICAL

Issue:

// Line 96 - attacker controls manifest_len
let manifest_len = u32::from_le_bytes(read_buf[..4].try_into().unwrap()) as usize;
let mut manifest_bytes = vec![0u8; manifest_len];
cursor.read_exact(&mut manifest_bytes)?;

// Line 103 - attacker controls weights_len
let weights_len = u64::from_le_bytes(read_buf) as usize;
let mut weights = vec![0u8; weights_len];
cursor.read_exact(&mut weights)?;

// Line 133 - attacker controls num_vectors
let num_vectors = u32::from_le_bytes(read_buf[..4].try_into().unwrap()) as usize;
let mut test_vectors = Vec::with_capacity(num_vectors);

An attacker can craft an artifact file with arbitrary length fields (e.g., manifest_len = 0xFFFFFFFF), causing:

1. Multi-gigabyte allocations
2. Out-of-memory crashes
3. System-wide DoS

Attack Vector:

Malicious artifact structure:
[MAGIC: RVAT][VERSION: 0001]
[manifest_len: FFFFFFFF]  <- 4GB allocation attempt
[garbage data...]

Impact:

• Memory exhaustion
• Process/system crash
• Resource starvation attack

Fix:

// Define reasonable limits
const MAX_MANIFEST_SIZE: usize = 1 << 20;  // 1MB
const MAX_WEIGHTS_SIZE: usize = 1 << 30;   // 1GB
const MAX_VECTORS: usize = 10000;

let manifest_len = u32::from_le_bytes(read_buf[..4].try_into()
    .map_err(|_| Error::InvalidArtifact("Truncated manifest length".into()))?) as usize;
if manifest_len > MAX_MANIFEST_SIZE {
    return Err(Error::InvalidArtifact(format!(
        "Manifest too large: {} > {}", manifest_len, MAX_MANIFEST_SIZE
    )));
}

// Apply to all length fields

---

C-3: FPGA PCIe Memory Mapping Without Validation

File: src/backend/fpga_pcie.rs Lines: 109-124, 293 Severity: CRITICAL

Issue:

// Line 109-114 - No validation of mapped region
let request_mmap = unsafe {
    MmapOptions::new()
        .offset(config.bar1_offset as u64)
        .len(total_size)
        .map_mut(&file)
        .map_err(|e| Error::PcieError(format!("Failed to map request buffer: {}", e)))?
};

// Line 293 - Can panic on malformed FPGA response
let response = ResponseFrame::from_bytes(&buffer[..14].try_into().unwrap());

Issues:

1. No validation that bar1_offset + total_size fits within device BAR
2. No checks that mapped memory is actually usable
3. .unwrap() on response parsing can panic on FPGA hardware errors

Attack Vector:

• Malicious FPGA firmware returns invalid responses
• Misconfigured PCIe device
• Buffer overflow if FPGA writes outside ring slots

Impact:

• Read/write to arbitrary physical memory (if offset wrong)
• Process crash on malformed FPGA responses
• Memory corruption

Fix:

// Validate BAR size before mapping
let bar_size = get_bar_size(&file, bar_index)?;
if config.bar1_offset + total_size > bar_size {
    return Err(Error::PcieError("Mapping exceeds BAR size".into()));
}

// Safe response parsing
let response = buffer.get(..14)
    .and_then(|b| b.try_into().ok())
    .map(ResponseFrame::from_bytes)
    .ok_or_else(|| Error::backend("Invalid FPGA response size"))?;

---

Medium Issues (Should Fix)

M-1: Integer Overflow in Quantization Casts

Files: src/quant/qformat.rs, src/quant/mod.rs, src/quant/lut.rs Lines: Multiple Severity: MEDIUM

Issue:

// qformat.rs:14 - f32 to i8 can overflow
let quantized = ((v - zero) / scale).round();
quantized.clamp(-128.0, 127.0) as i8  // Clamp before cast, but...

// qformat.rs:36 - f32 to i16
normalized.round().clamp(-32768.0, 32767.0) as i16

// mod.rs:53 - Fixed-point multiplication
let product = (a as i32 * b as i32 + 0x4000) >> 15;
product.clamp(i16::MIN as i32, i16::MAX as i32) as Q15

// mod.rs:62 - Dot product can overflow
.map(|(&x, &y)| x as i32 * y as i32)
.sum()  // i32 accumulator can overflow with large vectors

Impact:

• Silent wraparound on overflow
• Incorrect inference results
• Potential exploit if overflow is predictable

Fix:

// Use checked/saturating arithmetic
let product = (a as i32).saturating_mul(b as i32)
    .saturating_add(0x4000) >> 15;

// For dot product, use i64 accumulator or check overflow
pub fn q15_dot(a: &[Q15], b: &[Q15]) -> Result<i32> {
    let sum: i64 = a.iter()
        .zip(b.iter())
        .map(|(&x, &y)| x as i64 * y as i64)
        .sum();

    sum.try_into()
        .map_err(|_| Error::ArithmeticOverflow)
}

---

M-2: RwLock Poisoning Causes Cascading Panics

Files: Multiple backend files Lines: All .unwrap() on RwLock::read/write Severity: MEDIUM

Issue:

// fpga_pcie.rs:356, fpga_daemon.rs:322, native_sim.rs:349
let mut models = self.models.write().unwrap();

If a thread panics while holding the lock, all subsequent accesses panic, causing cascading failures.

Impact:

• Total backend failure after single panic
• Difficult to recover
• DoS if panic is triggerable

Fix:

// Handle poisoned locks gracefully
let mut models = self.models.write()
    .map_err(|e| {
        log::error!("RwLock poisoned: {:?}", e);
        Error::backend("Lock poisoned, restarting required")
    })?;

// Or use parking_lot::RwLock which doesn't poison

---

M-3: No Input Validation on Token Indices

Files: Multiple inference paths Severity: MEDIUM

Issue: Token IDs from untrusted input are used to index into embedding tables without validation:

// backend/wasm_sim.rs:75
let token_idx = last_token as usize;
// Then used to index: model.embeddings[embed_offset + d]
// No check that token_idx < vocab

Attack Vector: Pass tokens = [0xFFFF] when vocab = 4096, causing out-of-bounds read.

Impact:

• Information disclosure (read arbitrary memory)
• Potential crash

Fix:

// Validate all token inputs
pub fn validate(&self) -> Result<()> {
    for &token in &self.tokens {
        if token as u32 >= self.shape.vocab {
            return Err(Error::InvalidInput {
                field: "tokens",
                reason: format!("Token {} >= vocab {}", token, self.shape.vocab),
            });
        }
    }
    // ... other validation
}

---

M-4: Softmax Accumulator Overflow

File: src/quant/lut.rs Lines: 132, 202 Severity: MEDIUM

Issue:

// Line 132
let mut sum: u32 = 0;
for &logit in logits.iter() {
    let exp_val = exp_lut(shifted);
    sum += exp_val as u32;  // Can overflow with vocab=65536
}

// Line 202
let mut sum: i64 = 0;
// ... but truncates to i16
let prob = (exp_values[i] as i64 * 65535 / sum) as i16;

With large vocabulary sizes, the sum can overflow.

Impact:

• Incorrect probability distributions
• Division by zero if overflow wraps to 0
• Inference quality degradation

Fix:

// Use u64 for sum
let mut sum: u64 = 0;
for &logit in logits.iter() {
    let exp_val = exp_lut(shifted);
    sum = sum.saturating_add(exp_val as u64);
}

// Check for overflow
if sum > u32::MAX as u64 {
    return Err(Error::ArithmeticOverflow);
}

---

M-5: Spin Loop CPU Exhaustion

File: src/backend/fpga_pcie.rs Lines: 322-334 Severity: MEDIUM

Issue:

fn wait_for_response(&self, ring: &DmaRingBuffer, slot: usize, timeout_ms: u64) -> Result<()> {
    let start = Instant::now();
    while !ring.is_complete(slot) {
        if start.elapsed() > timeout {
            return Err(Error::Timeout { ms: timeout_ms });
        }
        std::hint::spin_loop();  // Busy-wait consumes 100% CPU
    }
    Ok(())
}

Impact:

• CPU starvation for other threads
• Power consumption
• Reduced system responsiveness

Fix:

// Use exponential backoff or sleep
let mut backoff = Duration::from_micros(1);
while !ring.is_complete(slot) {
    if start.elapsed() > timeout {
        return Err(Error::Timeout { ms: timeout_ms });
    }
    std::thread::sleep(backoff);
    backoff = (backoff * 2).min(Duration::from_millis(10));
}

---

M-6: Ed25519 Verification - No Timing Attack Protection Mentioned

File: src/artifact/verify.rs Lines: 10-26 Severity: MEDIUM

Issue:

pub fn verify_signature(artifact: &ModelArtifact) -> Result<bool> {
    let pubkey = VerifyingKey::from_bytes(&artifact.pubkey)
        .map_err(|e| Error::SignatureError(format!("Invalid public key: {}", e)))?;
    let signature = Signature::from_bytes(&artifact.signature);
    pubkey.verify(&message, &signature)
        .map(|_| true)
        .map_err(|e| Error::SignatureError(format!("Verification failed: {}", e)))
}

While ed25519_dalek is solid, the code doesn't document whether constant-time guarantees are required for this use case.

Impact:

• Potential timing side-channel if signatures are used for authentication
• Low risk for artifact verification (not secret)

Fix:

// Document timing requirements
/// Verify artifact signature
///
/// # Security
/// - Uses ed25519_dalek which provides timing-attack resistance
/// - Signature verification is public-key operation (no secrets to leak)
/// - However, early rejection on key parsing could leak key validity

---

M-7: No Maximum Size Limits in Test Vectors

File: src/artifact/pack.rs Lines: 139-164 Severity: MEDIUM

Issue:

// Line 139 - num_tokens controlled by attacker
let num_tokens = u16::from_le_bytes([read_buf[0], read_buf[1]]) as usize;
let mut tokens = Vec::with_capacity(num_tokens);

// Line 148 - num_expected controlled by attacker
let num_expected = u32::from_le_bytes(read_buf[..4].try_into().unwrap()) as usize;
let mut expected = Vec::with_capacity(num_expected);

Can allocate arbitrary memory per test vector.

Impact:

• Memory exhaustion
• DoS

Fix:

const MAX_TOKENS_PER_VECTOR: usize = 1024;
const MAX_EXPECTED_PER_VECTOR: usize = 65536;

if num_tokens > MAX_TOKENS_PER_VECTOR {
    return Err(Error::InvalidArtifact(
        format!("Test vector tokens too large: {}", num_tokens)
    ));
}

---

Low Issues (Nice to Fix)

L-1: Error Messages Expose Internal Details

Files: Multiple Severity: LOW

Issue:

// pack.rs:88
return Err(Error::InvalidArtifact(format!("Unsupported version: {}", version)));

// verify.rs:36-39
return Err(Error::InvalidArtifact(format!(
    "Model hash mismatch: expected {}, got {}",
    artifact.manifest.model_hash, computed_hash
)));

Detailed error messages can aid attackers in crafting exploits.

Fix: Use generic error messages for external APIs, detailed logs for debugging:

log::debug!("Hash mismatch: expected {}, got {}", expected, actual);
return Err(Error::InvalidArtifact("Integrity check failed".into()));

---

L-2: DMA Ring Buffer Race Conditions

File: src/backend/fpga_pcie.rs Lines: 143-170 Severity: LOW

Issue: No memory barriers between slot state checks and FPGA updates. Relies on hardware coherency.

Impact:

• Potential stale reads
• Race conditions on weaker memory models

Fix:

// Add explicit barriers if needed
use std::sync::atomic::compiler_fence;
compiler_fence(Ordering::Acquire);
let state = self.slot_states[slot].load(Ordering::Acquire);

---

L-3: No Bounds Check on Array Indexing in LUTs

File: src/quant/lut.rs Lines: 62, 111, 249 Severity: LOW

Issue:

// Line 62
let idx = ((clamped >> EXP_LUT_SHIFT) + 128) as usize;
EXP_LUT[idx.min(EXP_LUT_SIZE - 1)]  // Uses .min() but could use .get()

// Line 111
LOG_LUT[idx.min(255)]

Uses .min() for safety, but direct indexing could panic if logic is wrong.

Fix:

// Use safe indexing
EXP_LUT.get(idx).copied().unwrap_or(0)
// Or document invariant
debug_assert!(idx < EXP_LUT_SIZE);

---

L-4: Missing Validation in C FFI Model ID Parsing

File: src/ffi/c_abi.rs Lines: 142-145 Severity: LOW

Issue:

let id_slice = unsafe { std::slice::from_raw_parts(model_id, 32) };
let mut id_bytes = [0u8; 32];
id_bytes.copy_from_slice(id_slice);  // Always copies exactly 32 bytes

Assumes model_id pointer is valid and has 32 bytes. Only null-checked.

Fix:

// Add alignment check
if (model_id as usize) % std::mem::align_of::<u8>() != 0 {
    return error_result();
}
// Existing null check is good

---

Summary Statistics

Severity	Count	Status
Critical	3	🔴 Immediate action required
Medium	7	🟡 Fix before production
Low	4	🟢 Best practice improvements
Total	14

Pattern Analysis

Most Common Issues:

1. .unwrap() usage: 47 instances across crate (23 in tests, 24 in src)
2. Unchecked as casts: 156 instances (potential overflow)
3. unsafe blocks: 20 instances (all in FFI/PCIe code)

Secure Practices Found:

✅ Uses ed25519_dalek for cryptography (industry standard) ✅ Input validation in many public APIs ✅ Proper use of Result types throughout ✅ Atomic operations for lock-free structures ✅ Comprehensive test coverage (3 benchmark files, multiple test modules)

Recommendations

Immediate Actions (Critical):

1. Add bounds checking to all FFI allocations
2. Implement maximum size limits for artifact unpacking
3. Validate PCIe memory mapping ranges
4. Replace .unwrap() with proper error handling in all non-test code

Short-term (Medium):

5. Use saturating arithmetic in quantization code
6. Handle RwLock poisoning gracefully
7. Add comprehensive input validation for all token indices
8. Replace spin loops with backoff strategies

Long-term (Low):

9. Security audit of memory ordering in DMA ring buffers
10. Consider using safer abstractions (e.g., parking_lot crates)
11. Add fuzzing targets for artifact unpacking
12. Implement rate limiting for inference requests

Testing Recommendations

Fuzzing Targets:

// Recommended fuzz tests
#[cfg(fuzzing)]
mod fuzz {
    use libfuzzer_sys::fuzz_target;

    fuzz_target!(|data: &[u8]| {
        let _ = unpack_artifact(data);
    });

    fuzz_target!(|tokens: Vec<u16>| {
        let req = InferenceRequest::new(
            ModelId::zero(),
            FixedShape::micro(),
            &tokens,
            &vec![1u8; tokens.len()],
            GateHint::default()
        );
        let _ = req.validate();
    });
}

Property Tests:

use proptest::prelude::*;

proptest! {
    #[test]
    fn test_quantize_never_panics(values: Vec<f32>) {
        let spec = QuantSpec::int8();
        let _ = quantize_i8(&values, &spec); // Should never panic
    }
}

Conclusion

The ruvector-fpga-transformer crate demonstrates solid architectural design with explicit quantization, hardware abstraction, and cryptographic verification. However, the crate has several critical security issues that must be addressed:

1. FFI boundary vulnerabilities from unsafe memory operations
2. DoS vectors from unbounded allocations
3. Hardware access risks in PCIe memory mapping

These issues are fixable with the recommended mitigations. After fixes, a follow-up audit focusing on memory ordering and fuzzing is recommended.

Overall Risk Rating: 🔴 HIGH (due to 3 critical issues) Post-Fix Estimate: 🟡 MEDIUM (pending verification)

---

Audit Methodology:

• Static code analysis with grep/ripgrep patterns
• Manual review of unsafe blocks, FFI boundaries, and crypto code
• Analysis of quantization arithmetic for overflow
• Buffer handling and allocation pattern review
• Input validation path tracing

Files Reviewed: 29 Rust source files Lines of Code: ~8,500 (excluding tests) Time Spent: 2.5 hours