On 6/23/25 1:11 PM, Herbert Xu wrote:
On Mon, Jun 23, 2025 at 11:40:39AM +0200, Mikulas Patocka wrote:
345 bytes on the stack - I think it's too much, given the fact that it
already uses 345 bytes (from SHASH_DESC_ON_STACK) and it may be called in
a tasklet context. I'd prefer a solution that allocates less bytes.
I don't see the beginning of this thread, so I'd like to ask what's the
problem here, what algorithm other than md5 is used here that causes the
buffer overflow?
The md5 export size has increased due to the partial block API
thus triggering the overflow.
How about this patch?
For v2:
Tested-by: Milan Broz <gmazyl...@gmail.com>
Just for the context, the patch fixes OOPS on 32bit (but 64bit should overflow
struct too):
: Oops: Oops: 0000 [#1] SMP
: CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.16.0-rc2+ #993
PREEMPT(full)
: Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference
Platform, BIOS 6.00 11/12/2020
: Workqueue: kcryptd-254:0-1 kcryptd_crypt [dm_crypt]
: EIP: __crypto_shash_export+0xf/0x90
: Code: 4a c1 c7 40 20 a0 b4 4a c1 81 cf 0e 00 04 08 89 78 50 e9 2b ff ff ff 8d 74 26
00 55 89 e5 57 56 53 89 c3 89 d6 8b 00 8b 40 14 <8b> 50 fc f6 40 13 01 74 04 4a
2b 50 14 85 c9 74 10 89 f2 89 d8 ff
: EAX: 303a3435 EBX: c3007c90 ECX: 00000000 EDX: c3007c38
: ESI: c3007c38 EDI: c3007c90 EBP: c3007bfc ESP: c3007bf0
: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010216
: CR0: 80050033 CR2: 303a3431 CR3: 04fbe000 CR4: 00350e90
: Call Trace:
: crypto_shash_export+0x65/0xc0
: crypt_iv_lmk_one+0x106/0x1a0 [dm_crypt]
...
The bisect was
efd62c85525e212705368b24eb90ef10778190f5 is the first bad commit
commit efd62c85525e212705368b24eb90ef10778190f5 (HEAD)
Author: Herbert Xu <herb...@gondor.apana.org.au>
Date: Fri Apr 18 10:59:04 2025 +0800
crypto: md5-generic - Use API partial block handling
Use the Crypto API partial block handling.
Milan
