Re: [PATCH] firmware_loader: use SHA-256 library API instead of crypto_shash API

[Eric Biggers]

On Fri, Mar 06, 2026 at 05:37:43PM +0100, Youssef Samir wrote:
> On 4/28/2025 8:09 PM, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@xxxxxxxxxx>
> > 
> > This user of SHA-256 does not support any other algorithm, so the
> > crypto_shash abstraction provides no value.  Just use the SHA-256
> > library API instead, which is much simpler and easier to use.
> > 
> > Also take advantage of printk's built-in hex conversion using %*phN.
> > 
> > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
> > ---
> > 
> > This patch is targeting the firmware_loader tree for 6.16.
> Hi Eric,
> 
> An issue has been found on kernel versions older than v6.16, where a firmware
> file larger than 2GB and is not divisible by SHA256_BLOCK_SIZE (64b) will always lead to a page fault. The first size that fits this criteria is 2147483649b. It is also worth noting that any subsequent loads regardless of the size or divisibility by 64, will lead to another page fault.
> I've mainly tested this with drivers/accel/qaic on 6.8.0-62-generic, but technically this should affect any code that uses the firmware loader on a kernel version older than v6.16 with CONFIG_FW_LOADER_DEBUG enabled, including the stable kernels.
> 
> This can be reproduced by creating a dummy binary file of a size that fits the criteria listed above, then compress it using zstd to allow _request_firmware() to open it.
> 
> This patch appears to have fixed the issue so I suggest backporting it, but
> I also noticed that it relies on changes that were introduced in this series:
> https://lore.kernel.org/lkml/cover.1745734678.git.herbert@xxxxxxxxxxxxxxxxxxx/

I guess this further shows that the upgrade to size_t lengths was a good
idea...

There was recently a similar bug report where on old kernels kexec
crashed in crypto_sha256_update when loading a file larger than ~2 GB.
It had already been fixed upstream by the upgrade to size_t lengths.
However, due to the large number of backports that would have been
needed, for the 6.1, 6.6, and 6.12 LTS kernels we just went with the
one-line fix "crypto: sha256 - fix crash at kexec"
(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-6.12.y&id=70165dc3ec8cff702da7b8b122c44575ee3111d6).

That increased the supported length in 6.1, and 6.6, and 6.12 from ~2 GB
to ~4 GB.  Your "6.8.0-62-generic" distro kernel must be missing that
commit.  You should first ask your distro to cherry-pick that commit
from 6.12, and it will fix the problem for sizes < ~4 GB.

Do you need support for sizes > ~4 GB?  If so, then we can come up with
a solution for that in the LTS kernels.  (Besides just doing a lot of
backports, one option would be to replace the call to
crypto_shash_digest() with a multi-step incremental computation.)

- Eric