{"uuid": "675b3bfa-0f6f-4423-8ed7-264ca3e442a5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-56788", "type": "seen", "source": "https://t.me/cvedetector/15063", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56788 - \"Linux Ethernet oa tc6 Tx Skb Reference Pointer Race Condition Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-56788 \nPublished : Jan. 11, 2025, 1:15 p.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: ethernet: oa_tc6: fix tx skb race condition between reference pointers  \n  \nThere are two skb pointers to manage tx skb's enqueued from n/w stack.  \nwaiting_tx_skb pointer points to the tx skb which needs to be processed  \nand ongoing_tx_skb pointer points to the tx skb which is being processed.  \n  \nSPI thread prepares the tx data chunks from the tx skb pointed by the  \nongoing_tx_skb pointer. When the tx skb pointed by the ongoing_tx_skb is  \nprocessed, the tx skb pointed by the waiting_tx_skb is assigned to  \nongoing_tx_skb and the waiting_tx_skb pointer is assigned with NULL.  \nWhenever there is a new tx skb from n/w stack, it will be assigned to  \nwaiting_tx_skb pointer if it is NULL. Enqueuing and processing of a tx skb  \nhandled in two different threads.  \n  \nConsider a scenario where the SPI thread processed an ongoing_tx_skb and  \nit moves next tx skb from waiting_tx_skb pointer to ongoing_tx_skb pointer  \nwithout doing any NULL check. At this time, if the waiting_tx_skb pointer  \nis NULL then ongoing_tx_skb pointer is also assigned with NULL. After  \nthat, if a new tx skb is assigned to waiting_tx_skb pointer by the n/w  \nstack and there is a chance to overwrite the tx skb pointer with NULL in  \nthe SPI thread. Finally one of the tx skb will be left as unhandled,  \nresulting packet missing and memory leak.  \n  \n- Consider the below scenario where the TXC reported from the previous  \ntransfer is 10 and ongoing_tx_skb holds an tx ethernet frame which can be  \ntransported in 20 TXCs and waiting_tx_skb is still NULL.  \n tx_credits = 10; /* 21 are filled in the previous transfer */  \n ongoing_tx_skb = 20;  \n waiting_tx_skb = NULL; /* Still NULL */  \n- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true.  \n- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs()  \n ongoing_tx_skb = 10;  \n waiting_tx_skb = NULL; /* Still NULL */  \n- Perform SPI transfer.  \n- Process SPI rx buffer to get the TXC from footers.  \n- Now let's assume previously filled 21 TXCs are freed so we are good to  \ntransport the next remaining 10 tx chunks from ongoing_tx_skb.  \n tx_credits = 21;  \n ongoing_tx_skb = 10;  \n waiting_tx_skb = NULL;  \n- So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true again.  \n- In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs()  \n ongoing_tx_skb = NULL;  \n waiting_tx_skb = NULL;  \n  \n- Now the below bad case might happen,  \n  \nThread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler)  \n--------------------------- -----------------------------------  \n- if waiting_tx_skb is NULL  \n    - if ongoing_tx_skb is NULL  \n    - ongoing_tx_skb = waiting_tx_skb  \n- waiting_tx_skb = skb  \n    - waiting_tx_skb = NULL  \n    ...  \n    - ongoing_tx_skb = NULL  \n- if waiting_tx_skb is NULL  \n- waiting_tx_skb = skb  \n  \nTo overcome the above issue, protect the moving of tx skb reference from  \nwaiting_tx_skb pointer to ongoing_tx_skb pointer and assigning new tx skb  \nto waiting_tx_skb pointer, so that the other thread can't access the  \nwaiting_tx_skb pointer until the current thread completes moving the tx  \nskb reference safely. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"11 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-11T14:55:15.000000Z"}