net: ethernet: oa_tc6: fix tx skb race condition between reference pointers
Key facts
- Attack vector
- Network
- Privileges required
- None
- User interaction
- None
- Attack complexity
- Low
- Impact type
- —
- Confidentiality · integrity · availability
- None · None · High
- Fix status
- Fixed
Attack profile from CVSS 3.1 · CNA. Fix status from CNA.
Summary
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.
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| Linux | Linux | 6.12 and later | 6.12.7, 6.13 | Patch available | CNA |
- Linux VendorLinux Affected 6.12 and later Fixed in 6.12.7, 6.13 Patch available CNA
CPE configurations NVD · 4
| CPE | Versions | Role | Vendor |
|---|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.12 to before 6.12.7 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:* | 6.13 rc1 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:* | 6.13 rc2 | Vulnerable | Linux |
| cpe:2.3:o:linux:linux_kernel:6.13:rc3:*:*:*:*:*:* | 6.13 rc3 | Vulnerable | Linux |
- cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* Versions 6.12 to before 6.12.7 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:* Versions 6.13 rc1 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:* Versions 6.13 rc2 Vulnerable ·Linux
- cpe:2.3:o:linux:linux_kernel:6.13:rc3:*:*:*:*:*:* Versions 6.13 rc3 Vulnerable ·Linux
Remediation
- Fix · CNA Linux (Linux) Fixed in 6.12.7, 6.13
Vendor assessments
Red Hat
Red Hat rating: Low. Red Hat's page for this CVE →
Not affected: 4 products
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 9
Timeline
- 2026-10-02 Threatist record created from CVE-2024-56788
- 2026-10-03 Alias added: GHSA-4fpg-2m6r-6cc4
- 2026-11-07 Affected versions changed · Red Hat
References
More Linux Kernel vulnerabilities
- TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
- TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
- TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
- TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
- TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
- TI-2021-05514 Heap Out-Of-Bounds Write in Netfilter IP6T_SO_SET_REPLACE KEVCVSS 3.1HIGH 8.3
Sources
- CVE-2024-56788 · CVE Program
- CVE-2024-56788 · NVD
- FIRST EPSS
- GHSA-4fpg-2m6r-6cc4 · GitHub Advisory Database · CC BY 4.0
- CVE-2024-56788 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences