Argon2 parallelism overflow creates a zero divisor

Argon2 rejects literal zero parallelism but scales a nonzero caller value in 32-bit unsigned arithmetic before division. parallelism = 0x40000000 makes parallelism * 4 wrap to zero, so a public gcry_kdf_open call faults before allocation and reliably terminates applications that forward untrusted KDF work parameters.

Vulnerable code

cipher/kdf.c, argon2_init:

c
  memory_blocks = m_cost;
  if (memory_blocks < 8 * parallelism)
    memory_blocks = 8 * parallelism;

  segment_length = memory_blocks / (parallelism * 4);
  memory_blocks = segment_length * parallelism * 4;

The only relevant validation in argon2_open is:

c
  if (parallelism == 0)
    return GPG_ERR_INV_VALUE;

  if (U64_C(1024) * m_cost > SIZE_MAX)
    return GPG_ERR_INV_VALUE;

Why it matters

The concrete public parameter array {32, 1, 8, 0x40000000} reaches the zero divisor before any large allocation can fail safely. The audit's UBSan harness reported runtime error: division by zero at cipher/kdf.c:507 through gcry_kdf_open. Exploitation requires an application to accept and forward this unusual parallelism value, for example from an imported password record or protocol; the established impact is deterministic denial of service, not memory corruption.

Proposed fix

Enforce the supported/specification lane limit before calling argon2_init. Compute 4 * parallelism and 8 * parallelism with checked arithmetic or in a wider type followed by representability checks, and explicitly reject a zero divisor before division. Add a public-API regression for 0x40000000 that expects GPG_ERR_INV_VALUE, plus boundary cases around the accepted maximum under UBSan.