Summary
=======
libkeccak_generalised_sum_fd (used by e.g. the sha3sum utilities) does an unconditional alloca with size equivalent to st_blksize reported by fstat on the file given. This will consistently segfault in conditions where st_blksize is greater than or (approximately) equal to the thread stack size limit.

This bug is present in the most recent libkeccak package, version 1.2-2.

Reproduction
============
The circumstances in which the bug manifests will vary a lot depending on system configuration, choice of filesystem, and so forth.

But an easy way to reliably reproduce the segfault is to shrink down the soft RLIMIT_STACK, create a file on a tmpfs filesystem that has hugepages enabled, and then attempt to run any of the utilities from the sha3sum package on that file.

1. Edit /etc/security/limits.conf or /etc/security/limits.d/<whatever>.conf to reduce soft RLIMIT_STACK to 2 MiB (or smaller):
* soft stack 2048 # <-- limit stack size to 2 MiB
* soft stack 1024 # <-- limit stack size to 1 MiB
2. Mount a fresh tmpfs (or use the one at /tmp), ensuring that its mount options include huge=always or huge=within_size
3. Create a file of any size (even an empty file works) in the tmpfs set up in step 2
4. Verify that e.g. `stat /tmp/file` does indeed report "IO Block: 2097152"
5. Install package sha3sum, if not already present
6. Attempt to run e.g. `sha3-256sum /tmp/file` (or any other sha3sum command for that matter), and it WILL segfault

Upstream Bug Report
===================
I filed a very detailed bug report here:
https://github.com/maandree/libkeccak/issues/13

In theory, you could patch the Arch package to incorporate one of the solutions suggested in the last section of that bug report.

(Not sure if super-important or worth doing; but I figured I would let you guys know in any case.)