In the Linux kernel, the following vulnerability has been resolved:
can: j1939: j1939_tp_tx_dat_new(): fix out-of-bounds memory access
In the j1939_tp_tx_dat_new() function, an out-of-bounds memory access
could occur during the memcpy() operation if the size of skb->cb is
larger than the size of struct j1939_sk_buff_cb. This is because the
memcpy() operation uses the size of skb->cb, leading to a read beyond
the struct j1939_sk_buff_cb.
Updated the memcpy() operation to use the size of struct
j1939_sk_buff_cb instead of the size of skb->cb. This ensures that the
memcpy() operation only reads the memory within the bounds of struct
j1939_sk_buff_cb, preventing out-of-bounds memory access.
Additionally, add a BUILD_BUG_ON() to check that the size of skb->cb
is greater than or equal to the size of struct j1939_sk_buff_cb. This
ensures that the skb->cb buffer is large enough to hold the
j1939_sk_buff_cb structure.
[mkl: rephrase commit message]
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel memory-safety flaw in the CAN J1939 networking code. A kernel copy operation could read past the intended control-buffer structure. Business exposure is most relevant for embedded, vehicle, industrial, or fleet systems using J1939/CAN networking. Public sources do not provide CVSS, confirmed exploitation, or impact details.
Executive priority
Treat as a targeted kernel maintenance issue. Prioritize patching in vehicle, industrial, and embedded environments using J1939/CAN. For general server fleets without CAN/J1939 use, urgency is lower pending vendor severity guidance.
Technical view
In j1939_tp_tx_dat_new(), memcpy() used sizeof(skb->cb) instead of sizeof(struct j1939_sk_buff_cb). If skb->cb is larger, the copy can read beyond the j1939_sk_buff_cb object. Stable fixes change the copy size and add BUILD_BUG_ON() to enforce buffer capacity at build time.
Likely exposure
Likely limited to Linux systems with the CAN J1939 stack present and reachable through relevant CAN/J1939 workloads. Exposure is higher in automotive, heavy equipment, industrial control, and embedded environments than in typical servers.
Exploitation context
The source bundle shows no KEV listing and provides no cited evidence of active exploitation. It also does not describe exploit prerequisites, attacker position, privileges, or practical impact beyond out-of-bounds memory access.
Researcher notes
Evidence is limited to the CVE record and Linux stable commit references. No CVSS, CWE, proof of exploitation, or detailed impact assessment is provided. Avoid extrapolating beyond an out-of-bounds read in kernel J1939 transmit-path handling.
Mitigation direction
Apply vendor kernel updates containing the referenced stable fixes.
Prioritize systems using CAN J1939 or exposed to CAN traffic.
If patching is delayed, check vendor guidance for supported mitigations.
Reduce unnecessary CAN/J1939 functionality where operationally safe.
Validation and detection
Inventory Linux kernel versions on CAN/J1939-capable systems.
Confirm whether J1939 kernel support is enabled or loaded.
Map deployed kernels against vendor advisories and stable fix commits.
Verify patched builds include the corrected memcpy size change.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-54039 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
7Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Dec 24, 2025, 10:56 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.