Hardening: input validation and bounds tightening across 31 subsystems (round 3) #31221
Claude / Claude Code Review
completed
May 23, 2026 in 18m 26s
Code review found 2 potential issues
Found 5 candidates, confirmed 2. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 0 |
| 🟡 Nit | 2 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🟡 Nit | packages/bun-usockets/src/crypto/openssl.c:818-823 |
openssl.c renegotiation window uses wall-clock time(NULL) instead of a monotonic clock |
| 🟡 Nit | src/runtime/webcore/FormData.rs:443-446 |
FormData part Content-Type guard rejects HTAB (valid per RFC 9110) |
Annotations
Check warning on line 823 in packages/bun-usockets/src/crypto/openssl.c
claude / Claude Code Review
openssl.c renegotiation window uses wall-clock time(NULL) instead of a monotonic clock
nit: this window uses wall-clock `time(NULL)`, so a backward clock step (NTP, manual `date -s`) makes the unsigned `now_ms - st->window_start_ms` underflow to ~2^64 ≥ `window*1000` and resets `st->count = 0` (fail-open). The Rust SSLWrapper path aligned to this one in resolved comment #3292012717 uses monotonic `std::time::Instant` for the same window — `clock_gettime(CLOCK_MONOTONIC)` here would match it. Not blocking: an attacker doesn't control the victim's clock, and pre-PR there was no limi
Check warning on line 446 in src/runtime/webcore/FormData.rs
claude / Claude Code Review
FormData part Content-Type guard rejects HTAB (valid per RFC 9110)
The printable-ASCII guard `(0x20..=0x7E).contains(&b)` rejects HTAB (0x09), so a part header like `Content-Type: text/plain;\tcharset=utf-8` (interior tab as OWS, valid per RFC 9110 §5.5/§8.3.1) has its content-type silently dropped to empty. HTAB is not a header-injection vector, so adding `b == b'\t' ||` to the predicate would preserve the security goal while accepting RFC-valid values. Nit — fails closed and tabs in Content-Type are vanishingly rare.
Loading