Description

In the Linux kernel, the following vulnerability has been resolved: can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer Zero the allocated buffer in j1939_session_fresh_new() to ensure it contains no residual data. While there is a potential performance impact if users allocate maximum sized ETP buffers, most real-world use cases are not noticeably affected since the maximum known buffer size is typically around 65K. [mkl: add Message-ID]

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-28T08:16:56.277Z",
  "pubdate": "2026-08-28T08:16:56.277Z",
  "executiveSummary": "This vulnerability involves an information disclosure flaw within the Linux kernel CAN (Controller Area Network) J1939 protocol implementation.\nThe issue stems from the j1939_session_fresh_new() function failing to zero-initialize newly allocated receive buffers.\nThis behavior allows residual data residing in kernel memory to be exposed to user-space applications or other kernel components interacting with the J1939 transport layer.\nThe vulnerability poses an information leak risk, potentially exposing sensitive kernel memory structures or data from previous operations.\nExploitation does not require elevated privileges beyond the ability to interact with the CAN J1939 socket interface.\nThe impact is categorized as an information disclosure vulnerability, potentially facilitating bypasses of kernel-space security protections (e.g., KASLR) or unauthorized data access.",
  "technicalDetails": "The vulnerability resides within the transport layer of the Linux kernel's J1939 protocol implementation, specifically in the j1939_session_fresh_new() function.\nIn the Linux kernel, memory allocated for dynamic objects is not guaranteed to be zeroed unless explicitly requested (e.g., using __GFP_ZERO or kzalloc). The j1939_session_fresh_new() function failed to sanitize the memory allocated for J1939 ETP (Extended Transport Protocol) buffers upon session initialization.\nThe attack flow proceeds as follows: 1) An attacker initiates a J1939 transport session, triggering an allocation via j1939_session_fresh_new(). 2) Because the kernel provides raw, non-zeroed memory pages from the slab allocator, the newly created receive buffer contains 'stale' or 'residual' data left over from previous kernel operations or processes that utilized that specific memory segment. 3) The attacker then reads the contents of the receive buffer through the J1939 socket interface. 4) By examining the contents of this buffer, the attacker can extract potentially sensitive information that resided in that memory space prior to the allocation, such as pointers, stack fragments, or data from other system operations.\nThis is a classic 'use of uninitialized memory' or 'information exposure' flaw. The affected component is the j1939 transport layer (net/can/j1939/transport.c). The vulnerability affects kernel versions supporting the CAN J1939 protocol that lack the explicit zeroing patch.\nThe primary risk is the leakage of sensitive kernel information which could be leveraged to gain insights into kernel memory layout, thereby undermining security mitigations like Kernel Address Space Layout Randomization (KASLR). Although the maximum buffer size is capped at approximately 65KB, this is sufficient to capture meaningful data chunks, including credential structures or critical kernel memory pointers.\nThe exploit requirement is minimal: the attacker simply needs the ability to open a CAN socket and initiate a transport session, which is typically accessible to any process with CAP_NET_RAW capability or via standard user access to CAN interfaces in many embedded configurations."
}