[robobun]

Problem

• Bun.password.hash / hashSync accept memoryCost up to 4294967295 KiB (4 TiB), and verify / verifySync take m= from the encoded hash (the existing prescan caps it at 4 GiB). pwhash::argon2::str_hash / str_verify (src/runtime/crypto/pwhash.rs) hand the cost to rust-argon2, whose Memory::new allocates the block matrix with vec![Block::zero(); n] (rust-argon2 3.0.0 memory.rs:36, reached from run() for both hashing and verifying). When that allocation fails the process aborts: memory allocation of N bytes failed, panic(main thread): abort() called, and a "Bun has crashed" report, for a value the caller passed in (or, for verify, for a hash string somebody else produced).
• Reproduced on the current release build: sh -c 'ulimit -v 4194304; exec bun -e "Bun.password.hashSync(\"pw\", { algorithm: \"argon2id\", memoryCost: 4194304 })"' aborts with memory allocation of 4294967296 bytes failed; a 512 MiB cost under a 1 GB limit aborts the same way, and so does the 4 TiB maximum on a machine with Linux's default overcommit setting (the request exceeds RAM plus swap, so mmap refuses it).
• Before the Rust port, Zig's std.crypto.pwhash.argon2 took an allocator and returned error.OutOfMemory, which PasswordObject.zig reported like every other hash failure: Password hashing failed with error "OutOfMemory" with code: "PASSWORD_OUT_OF_MEMORY".

Fix

• check_memory_is_allocatable(m) reserves m * 1024 bytes with try_reserve_exact, drops the probe, and returns Error::Alloc on failure. str_hash calls it right before hash_encoded; str_verify records m in the prescan it already runs over the cost fields and calls it right before verify_encoded (the decoder only accepts strings with exactly one m=, so this is the cost it would allocate for; anything else fails to decode before allocating).
• Error::Alloc names itself OutOfMemory, so the unchanged password_error_instance in PasswordObject.rs produces exactly the pre-port error, on both the sync path and the work-pool path: Password hashing failed with error "OutOfMemory" / Password verification failed with error "OutOfMemory", code: "PASSWORD_OUT_OF_MEMORY".
• Where this changes behavior: wherever the allocation itself fails. That is every Windows machine without the commit charge to spare (Windows does not overcommit), Linux with the default overcommit heuristic whenever the cost exceeds RAM plus swap (for example a cost given in bytes or MiB instead of KiB, or the m= of a hash string an attacker controls), and any address-space or commit limit. It deliberately changes nothing when the allocation succeeds and the machine later runs out of memory while argon2 touches the blocks (overcommit_memory=1, cgroup limits); that is the OOM killer's domain, as before.
• Why a probe: rust-argon2 has no API that takes caller-provided memory or fails on allocation, and the two ways to change that (patching the crate, which build: fetch and patch rust-argon2 as a vendored cargo path dependency #33153 is the open infrastructure for, or switching to RustCrypto's argon2, which changes the PHC codec and the verify semantics) are much larger changes than this needs. The probe is best effort by construction (another thread can take the memory between the probe and the crate's allocation, and the crate rounds the cost down to a multiple of 4 blocks), which is acceptable: it cannot make anything that works today fail, and it converts every deterministic failure into the error. It costs one untouched reservation and release per call, microseconds next to the hash itself. The function is pub(crate) so the node:crypto argon2 binding proposed in node:crypto: implement argon2 and argon2Sync #37015, which drives the same crate, can use the same check.
• Not changed here: the memoryCost ceiling for hash. Bun.password: reject argon2 cost options that verify would refuse #33865 proposes capping it at verify's 4 GiB; that is compatible with this and does not replace it, since the costs that fail to allocate in practice (64 MiB default, 4 GiB maximum) are well inside any plausible ceiling. crypto: accept argon2 PHC params in any order in Bun.password.verify #32314 edits the same prescan loop; whichever lands second has a three-line conflict.
• Verified with test/js/bun/util/password.test.ts: the same child script runs hashSync, hash, verifySync and verify against an unallocatable cost and checks an allocatable one still works afterwards, in two variants. Under ASAN (test.skipIf(!isASAN)) with allocator_may_return_null=1:max_allocation_size_mb=32 and the default 64 MiB cost: fails on main with memory allocation of 67108864 bytes failed, passes here. On Linux release builds (test.skipIf(isASAN || !isLinux); ASAN builds cannot start under an address-space limit) with ulimit -v 4194304 and a 4 GiB cost, which can never fit while bun itself starts in about 0.35 GB: fails against the current release build with memory allocation of 4294967296 bytes failed (output below); its passing side runs on CI's Linux release lanes, since the local debug build is ASAN. The rest of the file: 72 pass, 9 debug-only skips.
• This was split out of TextEncoderStream: throw out of memory instead of aborting when a chunk's output buffer cannot be allocated #38941 (the TextEncoderStream half of the same port regression), which shares no code with it.

Background

• argon2's memory cost m is in KiB: the algorithm fills a matrix of m one-kibibyte blocks, allocated up front in one piece, and reads it back while hashing, so it is the dominant allocation of a hash or verify call. verify gets it from the PHC string it is given ($argon2id$v=19$m=65536,t=2,p=1$salt$hash), so it is input, not configuration.
• Vec::try_reserve_exact returns Err when the allocator returns null, where the crate's vec! calls handle_alloc_error and aborts. Reserving without writing touches no pages, so the probe costs the allocator a reservation and a release and nothing else.
• Error::Alloc(AllocError) is the runtime crate's out-of-memory variant; Error::name() reports it as OutOfMemory, and Bun.password builds both the message and the PASSWORD_* code from that name, which is also how the Zig implementation formatted error.OutOfMemory.
• Under ASAN the global allocator is libc's, and ASAN_OPTIONS=allocator_may_return_null=1:max_allocation_size_mb=N makes any single allocation above N MiB return null; ulimit -v (RLIMIT_AS) makes mmap fail once the process's address space would exceed the limit, which is how mimalloc ends up returning null in the release variant.

Release build, without the fix, address-space variant of the test

memory allocation of 4294967296 bytes failed
...
RSS: 29.65 MB | Peak: 0.35 GB | Commit: 25.10 MB | Faults: 0 | Machine: 34.36 GB

panic(main thread): abort() called
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

With the fix, all four entry points report
{"name":"Error","code":"PASSWORD_OUT_OF_MEMORY","message":"Password hashing failed with error \"OutOfMemory\""}
(verification for the verify pair) and a hash with memoryCost: 8 still round-trips afterwards.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: oven-sh/bun/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Essentials

Run ID: f88aa32c-91b4-40a4-8c53-954a5a91602c

📥 Commits

Reviewing files that changed from the base of the PR and between bf42a52 and ecd4be5.

📒 Files selected for processing (2)

• src/runtime/crypto/pwhash.rs
• test/js/bun/util/password.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 0 remain after this review.

---

Walkthrough

Argon2 hashing and verification now probe whether the configured memory allocation can be reserved before calling the vendor implementation. New child-process tests check allocation errors under constrained memory limits and confirm that low-cost verification still succeeds.

Changes

Argon2 Allocation Handling

Layer / File(s)	Summary
Memory allocation checks src/runtime/crypto/pwhash.rs	A shared helper checks allocation-size overflow and uses fallible reservation. Hashing and verification probe allocation before vendor operations. Verification skips the probe when m is absent and retains the existing parameter limits.
Allocation failure tests test/js/bun/util/password.test.ts	Platform- and configuration-specific child-process tests check sync and async hashing and verification errors under constrained allocation limits. They also check that a later low-cost verification succeeds.

Suggested reviewers: jarred-sumner

Priority: ➖ Normal

Merge Risk: ⚪ Minimal · up to ecd4b

No actionable merge-blocking defect was established. The change adds allocation-failure handling and recovery tests; merge after normal CI checks pass.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main change: report unallocatable Argon2 memory as an out-of-memory error instead of aborting.
Description check	✅ Passed	The description explains the problem, implementation, behavior changes, limitations, and verification results. It does not use the template headings exactly, but it includes the required content in th…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Status: fixed, waiting on CI. Split out of #38941.

• Reproduced on the current release build: sh -c 'ulimit -v 4194304; exec bun -e "Bun.password.hashSync(\"pw\", { algorithm: \"argon2id\", memoryCost: 4194304 })"' aborts with memory allocation of 4294967296 bytes failed and a crash report; the debug (ASAN) build aborts the same way for the default 64 MiB cost under max_allocation_size_mb=32, on hash and on verify of a hash string claiming that cost.
• With this branch all four entry points throw or reject with PASSWORD_OUT_OF_MEMORY, the error the pre-port implementation produced, and the process continues.
• Test: test/js/bun/util/password.test.ts, an ASAN variant (fails on main, passes here locally) and a Linux release variant under ulimit -v (fails against the current release build; its passing side runs on the Linux release lanes).

[claude]

I reviewed this PR and didn't find any bugs. The probe-then-allocate approach is sound and strictly additive (can only turn aborts into errors, never the reverse), but since it's a deliberate interim design choice in Bun.password — chosen over patching rust-argon2 or switching crates — a maintainer should confirm they're happy landing it this way.

What was reviewed

• check_memory_is_allocatable: u32 → usize widening + checked_mul(1024) before try_reserve_exact; ? on bun_alloc::AllocError reaches crate::Error::Alloc via #[from], and Error::name() returns "OutOfMemory" → PASSWORD_OUT_OF_MEMORY in password_error_instance.
• Verify path: m= recorded inside the existing prescan; the ulimit test's m=4194304 is exactly MAX_VERIFY_MEMORY_COST (1 << 22), so it passes the WeakParameters cap and reaches the probe as intended.
• Probe uses the global allocator, same as rust-argon2's vec[Block; n], so ASAN's max_allocation_size_mb and mimalloc under ulimit -v see the same failure the real allocation would.

Extended reasoning...

Overview

The PR adds a fallible allocation probe (check_memory_is_allocatable) in src/runtime/crypto/pwhash.rs that reserves memoryCost * 1024 bytes via Vec::try_reserve_exact before rust-argon2's infallible vec[Block::zero(); n] runs. It is called from str_hash (using config.mem_cost) and from str_verify (using the m= value already parsed by the existing cost-cap prescan). On failure it returns Error::Alloc(AllocError), which Error::name() reports as "OutOfMemory" and password_error_instance formats as PASSWORD_OUT_OF_MEMORY — the same error the pre-port Zig implementation produced. Two new subprocess tests cover all four entry points (hash/hashSync/verify/verifySync) under ASAN's max_allocation_size_mb cap and under a Linux ulimit -v address-space limit.

Security risks

None introduced. This does not touch the argon2/bcrypt primitives, salts, or comparison logic; it only front-runs an allocation that would otherwise abort the process. If anything it hardens verify slightly against a hostile PHC string whose m= is sized to abort the process — that now becomes a catchable error. The probe cannot cause a previously-successful hash to fail: if the probe reservation succeeds it is immediately dropped, and the subsequent real allocation sees the same allocator state modulo a TOCTOU window the PR description explicitly acknowledges.

Level of scrutiny

Moderate-to-high. The Rust change is ~20 lines and mechanically simple, but it lives in Bun.password and encodes a design choice: a best-effort probe rather than patching rust-argon2 (blocked on #33153) or switching to RustCrypto's argon2 (which would change PHC codec/verify semantics). The PR description makes the case for this tradeoff thoroughly, and it also flags interactions with three other open PRs (#33865 memoryCost ceiling, #37015 node:crypto argon2, #32314 same prescan loop). That's exactly the kind of context where a maintainer should sign off on the direction, even though the implementation itself is straightforward and correct.

Other factors

I verified the error-plumbing chain end to end: bun_alloc::AllocError → crate::Error::Alloc (via #[from] at src/runtime/error.rs:419) → name() == "OutOfMemory" (line 782) → password_error_instance builds PASSWORD_OUT_OF_MEMORY. The verify test's m=4194304 sits exactly at MAX_VERIFY_MEMORY_COST so it clears the existing > limit check and reaches the new probe. The checked_mul guards 32-bit overflow. The tests follow harness conventions (bunEnv spread, concurrent pipe drain, exit-code asserted last, skipIf with stated reasons) and each has a plausible CI lane where it runs (ASAN debug for the first, Linux release for the second). No bugs found by the multi-agent hunt or by this pass; deferring purely so a human confirms the probe approach is the interim fix they want.

[github-actions]

If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code

[robobun]

^{Updated 1:44 PM PT - Sep 30th, 2026}

✅ @robobun, your commit ecd4be59c24ff8cf6d1e31b228b27b4fc7b837d7 passed in Build #121955! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 39021

That installs a local version of the PR into your bun-39021 executable, so you can run:

bun-39021 --bun

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

🟡 (optional) Callers verifying a malformed argon2 string on a memory-constrained host now get "OutOfMemory" where the base returned "InvalidEncoding", and every verify now attempts a reservation before the string is validated. At src/runtime/crypto/pwhash.rs:270 the probe runs on the prescanned m= before vendor::verify_encoded at :273 decodes salt, hash and field layout. A garbage string like $argon2id$v=19$m=4194304,t=1,p=1$bad$bad triggers a 4 GiB reservation attempt that the base never made. Fix: validate before allocating — decode the PHC string (or at least confirm it parses) first and probe only for strings that would otherwise reach Memory::new, so InvalidEncoding stays InvalidEncoding.

Why this was flagged

Input: any verify string with a parseable m= at or below MAX_VERIFY_MEMORY_COST (src/runtime/crypto/pwhash.rs:49, 4194304 KiB) but otherwise undecodable (bad base64 salt/hash, wrong segment count), reaching str_verify via PasswordObject.rs:352 from Bun.password.verify/verifySync. The prescan at :262-264 records m, and :270 calls check_memory_is_allocatable before :273 runs the decoder. On the base branch the same string reaches vendor::verify_encoded directly, fails in decode_string before Memory::new, and the caller gets InvalidEncoding with no allocation. After the change, on a host where a 4 GiB reservation fails, the caller instead gets Password verification failed with error "OutOfMemory" with code PASSWORD_OUT_OF_MEMORY, so code that treats InvalidEncoding as a corrupt stored hash misclassifies it as a transient resource error. The comment at :268 ("fail to decode below, before allocating") describes the base ordering, not the new one, since the probe itself is the allocation.

Verification: The prescan records m at src/runtime/crypto/pwhash.rs:262-264, and :269-270 calls check_memory_is_allocatable(memory_cost)? before vendor::verify_encoded at :273. On the base branch rust-argon2's decode_string ran before Memory::new, so a malformed string returned Error::InvalidEncoding without ever allocating. Result: a memory-constrained host now reports OutOfMemory instead of InvalidEncoding.

[claude]

🟣 pre-existing, not blocking: pre-existing: callers of node:crypto's crypto.argon2 / argon2Sync still abort the process with "memory allocation of N bytes failed" when the block matrix cannot be allocated, the exact failure this PR fixes for Bun.password. The sibling site src/runtime/node/node_crypto_binding.rs:1459 drives the same crate's hash_raw infallibly, guarded only by synthetic_allocation_limit (default u32::MAX bytes), so any memory below 4 GiB that mmap refuses still crashes. Fix: call check_memory_is_allocatable(self.memory) before hash_raw at node_crypto_binding.rs:1459 and route failure into the existing failed path. The PR description says this binding is only proposed in #37015, but it is present in this checkout at src/js/node/crypto.ts:368.
A small fix can ride a push you are already making; otherwise a short reply is enough.

Why this was flagged

A user calls crypto.argon2Sync("argon2id", { message, nonce, memory: 4194303, ... }) from node:crypto (src/js/node/crypto.ts:368/389) in a process whose address space or commit is limited, e.g. under ulimit -v 4194304 as in the PR's own repro. node_crypto_binding.rs:1421-1423 only pre-fails when memory*1024 exceeds synthetic_allocation_limit(), which defaults to u32::MAX (src/jsc/VirtualMachine.rs:44-45), so 4 GiB passes the check. node_crypto_binding.rs:1459 then calls rust_argon2::hash_raw, whose Memory::new does vec![Block::zero(); n] infallibly; the mmap fails and Rust's handle_alloc_error aborts the process with "memory allocation of 4294967296 bytes failed". On the base branch this aborts identically, so it is pre-existing; but the PR adds a pub(crate) probe explicitly meant for this binding while stating the binding does not exist yet, leaving the same crate driven by two callers with different failure behavior.

Verification: src/runtime/node/node_crypto_binding.rs:1421-1423 is the only pre-check, and SYNTHETIC_ALLOCATION_LIMIT defaults to u32::MAX as usize (src/jsc/VirtualMachine.rs:44-45). run() then calls rust_argon2::hash_raw (node_crypto_binding.rs:1459), and the file's own comment at 1416-1417 states rust-argon2's vec![Block::zero(); mem_cost] allocates infallibly.

[claude]

🟣 pre-existing, not blocking: pre-existing: on Linux with the default overcommit setting, a memoryCost larger than RAM plus swap still gets the process OOM-killed instead of the promised "OutOfMemory" error. The probe at src/runtime/crypto/pwhash.rs:105-108 goes through the mimalloc global allocator, and upstream mimalloc mmaps with MAP_NORESERVE whenever /proc/sys/vm/overcommit_memory is 0 or 1, which makes the kernel skip the heuristic check, so the reservation succeeds and rust-argon2 then fills the matrix until the OOM killer fires. Fix: make the probe fail for any cost that cannot be backed on Linux, e.g. probe with a direct mmap without MAP_NORESERVE, on both the hash and verify paths.
A small fix can ride a push you are already making; otherwise a short reply is enough.

Why this was flagged

A user on a stock Linux box (vm.overcommit_memory=0, e.g. 16 GiB RAM, no swap) calls Bun.password.hashSync("pw", { algorithm: "argon2id", memoryCost: 67108864 }) meaning 64 MiB but passing bytes, which argon2 reads as 64 GiB. src/runtime/crypto/PasswordObject.rs:137 accepts any integer up to 4294967295, so str_hash reaches check_memory_is_allocatable at src/runtime/crypto/pwhash.rs:168. The probe's try_reserve_exact at pwhash.rs:107 calls bun_alloc::Mimalloc::alloc (src/bun_alloc/lib.rs:536), i.e. mi_malloc; mimalloc's unix prim adds MAP_NORESERVE to every mmap when it detects overcommit_memory 0 or 1, and the kernel only applies the mode-0 heuristic to accountable mappings, so the 64 GiB reservation succeeds and the probe returns Ok. vendor::hash_encoded at pwhash.rs:169 then allocates the same 64 GiB and writes every block, and the process is SIGKILLed by the OOM killer with no JS error and no crash report. This is what the base branch does too, so the change fixes only the RLIMIT_AS and Windows-commit cases.

Verification: pre-existing (the base already OOM-kills by the same route). The trigger is a non-ASAN Linux build with vm.overcommit_memory=0 and a memoryCost larger than RAM+swap. src/runtime/crypto/pwhash.rs:105-108 probes with try_reserve_exact through bun_alloc::Mimalloc, and upstream mimalloc's unix_mmap adds MAP_NORESERVE, so the reservation succeeds and the process is OOM-killed while the blocks are written.

[robobun]

The review comment above is right: the probe is a workaround. It leaves the crate's own allocation infallible, so node:crypto argon2 still aborts, and a concurrent job can take the memory after the probe frees it.

#44360 replaces this PR. It patches the vendored rust-argon2 crate so the allocation itself returns an error, maps that to OutOfMemory in pwhash.rs, and keeps this PR's test block. This PR can be closed in favor of it.

[Jarred-Sumner]

This is Claude (an AI assistant) commenting on Jarred's behalf.

Another fix for the same crash went in with #46021, which is merged. Closing as superseded.