In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: oa_tc6: fix tx skb race condition between reference pointers
There are two skb pointers to manage tx skb's enqueued from n/w stack.
waiting_tx_skb pointer points to the tx skb which needs to be processed
and ongoing_tx_skb pointer points to the tx skb which is being processed.
SPI thread prepares the tx data chunks from the tx skb pointed by the
ongoing_tx_skb pointer. When the tx skb pointed by the ongoing_tx_skb is
processed, the tx skb pointed by the waiting_tx_skb is assigned to
ongoing_tx_skb and the waiting_tx_skb pointer is assigned with NULL.
Whenever there is a new tx skb from n/w stack, it will be assigned to
waiting_tx_skb pointer if it is NULL. Enqueuing and processing of a tx skb
handled in two different threads.
Consider a scenario where the SPI thread processed an ongoing_tx_skb and
it moves next tx skb from waiting_tx_skb pointer to ongoing_tx_skb pointer
without doing any NULL check. At this time, if the waiting_tx_skb pointer
is NULL then ongoing_tx_skb pointer is also assigned with NULL. After
that, if a new tx skb is assigned to waiting_tx_skb pointer by the n/w
stack and there is a chance to overwrite the tx skb pointer with NULL in
the SPI thread. Finally one of the tx skb will be left as unhandled,
resulting packet missing and memory leak.
- Consider the below scenario where the TXC reported from the previous
transfer is 10 and ongoing_tx_skb holds an tx ethernet frame which can be
transported in 20 TXCs and waiting_tx_skb is still NULL.
tx_credits = 10; /* 21 are filled in the previous transfer */
ongoing_tx_skb = 20;
waiting_tx_skb = NULL; /* Still NULL */
- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true.
- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs()
ongoing_tx_skb = 10;
waiting_tx_skb = NULL; /* Still NULL */
- Perform SPI transfer.
- Process SPI rx buffer to get the TXC from footers.
- Now let's assume previously filled 21 TXCs are freed so we are good to
transport the next remaining 10 tx chunks from ongoing_tx_skb.
tx_credits = 21;
ongoing_tx_skb = 10;
waiting_tx_skb = NULL;
- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true again.
- In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs()
ongoing_tx_skb = NULL;
waiting_tx_skb = NULL;
- Now the below bad case might happen,
Thread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler)
--------------------------- -----------------------------------
- if waiting_tx_skb is NULL
- if ongoing_tx_skb is NULL
- ongoing_tx_skb = waiting_tx_skb
- waiting_tx_skb = skb
- waiting_tx_skb = NULL
...
- ongoing_tx_skb = NULL
- if waiting_tx_skb is NULL
- waiting_tx_skb = skb
To overcome the above issue, protect the moving of tx skb reference from
waiting_tx_skb pointer to ongoing_tx_skb pointer and assigning new tx skb
to waiting_tx_skb pointer, so that the other thread can't access the
waiting_tx_skb pointer until the current thread completes moving the tx
skb reference safely.
Security readout for executives and security teams
Plain-English summary
A race condition in the Linux OA-TC6 Ethernet driver can lose outbound packets and leak memory when two kernel threads update transmit-buffer pointers concurrently. The documented impact is availability degradation, not data theft or modification. Risk is concentrated in systems that actually use this driver.
Executive priority
Treat as a prompt, targeted availability fix for OA-TC6-dependent systems, especially embedded or operational devices where packet loss or memory exhaustion disrupts service. Broad emergency action is not supported for systems that do not use this driver, and no active exploitation is documented.
Technical view
The network transmit path and SPI handler can concurrently modify waiting_tx_skb and ongoing_tx_skb. An unsafe pointer transfer may overwrite a newly queued buffer reference with NULL, leaving the packet unprocessed and its memory unreleased. The kernel fix synchronizes these pointer operations. The supplied CVSS 3.1 score is 7.5, reflecting high availability impact.
Likely exposure
The supplied record identifies Linux kernel 6.12-related versions and 6.13, but its version formatting is ambiguous. Practical exposure requires the vulnerable OA-TC6 Ethernet driver code to be present and used. Systems without this driver in operation are unlikely to encounter the documented race.
Exploitation context
CISA KEV status is false, and the supplied sources provide no evidence of active exploitation or a public exploit. Triggering occurs during concurrent packet queuing and SPI transmit processing. Although the CVSS vector uses network attack complexity, the evidence does not establish direct Internet-wide exploitability.
Researcher notes
The core defect is a time-of-check/time-of-use race across two transmit-buffer reference pointers. The supplied record does not identify a CWE, exploitation proof, or precise distribution package boundaries. Review the cited stable-kernel commits and vendor backports because kernel version strings alone may not establish vulnerability status.
Mitigation direction
Update to a vendor-supported kernel release containing the applicable cited fix.
Prioritize systems actively using the OA-TC6 Ethernet driver.
Consult Linux distribution advisories for exact affected and fixed package versions.
Monitor affected systems for packet loss and abnormal memory growth until updated.
Validation and detection
Inventory kernels and determine whether the OA-TC6 Ethernet driver is actively used.
Check whether the installed kernel contains either applicable cited fix commit.
Confirm affected-version status against the system vendor's security advisory.
After updating, test sustained transmission and monitor packet loss and memory consumption.
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-2024-56788 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.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.