Description

In the Linux kernel, the following vulnerability has been resolved: crypto: krb5 - use kfree_sensitive() for derived key buffers crypto_krb5_prepare_encryption() and crypto_krb5_prepare_checksum() free the buffer holding the freshly derived keys with plain kfree(), leaving the key material behind in the freed slab object.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-09T17:17:47.653Z",
  "pubdate": "2026-09-09T17:17:47.653Z",
  "executiveSummary": "A sensitive information disclosure vulnerability exists within the Linux kernel's crypto krb5 implementation. The flaw arises from the improper handling of memory buffers containing cryptographic key material during the deallocation process.\nSpecifically, the functions crypto_krb5_prepare_encryption() and crypto_krb5_prepare_checksum() utilize standard kfree() rather than a secure memory wiping function. This results in sensitive derived keys remaining in the slab memory after the buffer has been freed.\nThis vulnerability impacts systems utilizing the KRB5 cryptographic modules within the Linux kernel. An attacker with the capability to perform heap inspection or exploit use-after-free vulnerabilities could potentially extract sensitive key material from freed slab objects.\nThe risk implication is significant as exposure of derived keys facilitates potential decryption or forgery of Kerberos-related traffic, undermining the confidentiality and integrity of secure communications. No specific authentication is required if the attacker can influence kernel memory state or inspect slab allocations, though exploitation typically requires local system access to observe kernel memory structures.",
  "technicalDetails": "The root cause of this vulnerability is the use of the non-secure kfree() function for memory regions designated for sensitive cryptographic material. In the context of kernel development, standard memory deallocation via kfree() returns a slab object to the allocator's free list without overwriting the existing content. If the object previously held sensitive data, such as derived Kerberos keys, that data persists in physical memory until the slab object is reclaimed and overwritten by a subsequent kernel allocation.\nThe vulnerable functions, crypto_krb5_prepare_encryption() and crypto_krb5_prepare_checksum(), handle the derivation of keys required for encryption and integrity checks. During the teardown of these operations, the buffers containing these freshly derived keys are released. Because kfree() performs no sanitization, the memory remains populated with the key material.\nThe attack flow involves an adversary monitoring or probing kernel memory states. By triggering frequent cryptographic operations, an attacker can influence the slab allocator to reuse the freed memory blocks. If the attacker can control or observe the data subsequently allocated in that specific slab region—or perform a direct memory dump if they have achieved kernel-level read primitives—they can recover the residual key material.\nThis vulnerability is classified as an information exposure (CWE-244: Improper Clearing of Heap Memory before Releasing). The absence of a zeroing operation before deallocation enables a side-channel for cryptographic material theft. The exposure is limited to the local system environment, as the leaked data resides within the kernel slab allocator's memory space.\nThe exploitation process typically follows these steps: 1) The attacker initiates an operation that calls crypto_krb5_prepare_encryption or crypto_krb5_prepare_checksum. 2) The kernel executes the cryptographic derivation and stores the keys in a heap buffer. 3) The kernel completes the operation and executes kfree() on the buffer. 4) The sensitive key material persists in the slab object. 5) The attacker leverages a separate primitive, such as a heap-based information leak or a local kernel memory read, to extract the uninitialized/persisted data from the freed slab slot before it is overwritten by legitimate kernel processes."
}