Hi Herbert,
there is an apparent regression in recent 6.16-rc2.
I can easily crash the kernel on 32bit machine with this OOPS:
: 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 points to
commit 8cf4c341f1931c20c564ab2ee0f9eb990a606cac
Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Fri Apr 18 10:59:04 2025 +0800
crypto: md5-generic - Use API partial block handling
Use the Crypto API partial block handling.
I think there is a buffer overflow in crypto_shash_export, it does not crash on 64bit perhaps
because of different alignment, but I can be mistaken.
As plen is blocksize + 1, this line in crypto_shash_export seems write out of m5 state:
unsigned int plen = crypto_shash_blocksize(tfm) + 1;
...
memcpy(out + ss - plen, buf + descsize - plen, plen);
It is easily reproducible with cryptsetup testuite script tests/loopaes-test (on 32bit system).
Let me know if you need more info.
Milan
