is there some thing wrong in KERNEL_FQ void m22400_init (KERN_ATTR_TMPS_ESALT (aescry
in KERNEL_FQ void m22400_init (KERN_ATTR_TMPS_ESALT (aescrypt_tmp_t, aescrypt_t)), I believe the following code is wrong.


  u32 w[80] = { 0 };

  for (u32 i = 0, j = 0; i < pw_len; i += 4, j += 1)
    w[j] = hc_swap32_S (pws[gid].i[j]);

  // sha256:

  sha256_ctx_t ctx;

  sha256_init  (&ctx);
  sha256_update (&ctx, s, 32);
  sha256_update (&ctx, w, pw_len);
  sha256_final  (&ctx);

  // set tmps:

  #ifdef _unroll
  #pragma unroll
  for (int i = 127; i >= 0; i--) // create some space for the first digest without extra buffer
    w[8 + i] = w[i];

  w[0] = ctx.h[0];
  w[1] = ctx.h[1];
  w[2] = ctx.h[2];
  w[3] = ctx.h[3];
  w[4] = ctx.h[4];
  w[5] = ctx.h[5];
  w[6] = ctx.h[6];
  w[7] = ctx.h[7];


The w size is 80, but for w[8 + i] = w[i] the i start from 127, this means i is out of the boundary.
nice find, it really seems so that this commit did change more than just the way we do the "utf16 encoding". The buffer sizes were changed; and you are right it seems that buffers do overflow with the new code. We should ask atom/jsteube if it's enough to just keep the old/correct buffer size also for the updated utf16 encoding.

The original code seems to not have this problem (i.e. any version of the -m 22400 hash module before the urf16 encoding change).

Please open a new issue on github and mention these details (your observation about the buffer overflow and which commit seem to have broken it). Thx
Problem was fixed with commit thanks for reporting. Indeed nice find!

Keeping the buffer size is fine, the UTF16 conversion is done inside the new gpu_utf8_to_utf16() kernel.