CVE-2024-56788 Affecting kernel-uek-modules-extra-netfilter package, versions <0:6.12.0-101.33.4.3.el9uek

Note: Versions mentioned in the description apply only to the upstream kernel-uek-modules-extra-netfilter package and not the kernel-uek-modules-extra-netfilter package as distributed by Oracle. See How to fix? for Oracle:9 relevant fixed versions and status.

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.

• https://linux.oracle.com/cve/CVE-2024-56788.html
• https://linux.oracle.com/errata/ELSA-2025-20480.html
• https://git.kernel.org/stable/c/1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775
• https://git.kernel.org/stable/c/e592b5110b3e9393881b0a019d86832bbf71a47f