9.8
CVE-2026-64439
- EPSS 0.43%
- Veröffentlicht 25.07.2026 08:51:12
- Zuletzt bearbeitet 03.09.2026 17:50:14
- Erkennungen
crypto: krb5 - filter out async aead implementations at alloc
In the Linux kernel, the following vulnerability has been resolved:
crypto: krb5 - filter out async aead implementations at alloc
krb5_aead_encrypt(), krb5_aead_decrypt() in rfc3961_simplified.c and
rfc8009_encrypt(), rfc8009_decrypt() in rfc8009_aes2.c set a NULL
completion callback and treat any negative return from
crypto_aead_{encrypt,decrypt}() as terminal, falling through to
kfree_sensitive(buffer). When the encrypt_name resolves to an
async AEAD instance the request returns -EINPROGRESS, the buffer
is freed while the backend's worker still holds a pointer, and the
worker dereferences the freed slab on completion.
KASAN report under UML+SLUB with a synthetic async aead backend
bound to krb5->encrypt_name:
BUG: KASAN: slab-use-after-free in t5_stub_complete+0x7d/0xc7
The helpers were written synchronously, so filter the async
instances out at allocation time instead of plumbing
crypto_wait_req() through every call site.
Reachable via net/rxrpc/rxgk.c, fs/afs/cm_security.c and
net/ceph/crypto.c on systems with an async AEAD provider bound to
the krb5 enctype name.Daten sind bereitgestellt durch National Vulnerability Database (NVD)
Linux ≫ Linux Kernel Version >= 6.15 < 6.18.39
Linux ≫ Linux Kernel Version >= 6.19 < 7.1.4
VulnDex Vulnerability Enrichment
| Typ | Quelle | Score | Percentile |
|---|---|---|---|
| EPSS | FIRST.org | 0.43% | 0.352 |
| Quelle | Base Score | Exploit Score | Impact Score | Vector String |
|---|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.8 | 3.9 | 5.9 |
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
|
CWE-416 Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
https://git.kernel.org/stable/c/ef6feb77e2d91761427c5b773edc9c97e1b706ad
https://git.kernel.org/stable/c/2b7bd6dccff14b8b632c5244f1fd506918077221
https://git.kernel.org/stable/c/6c9dddeb582fde005360f4fe02c760d45ca05fb5