CVE-2024-56788 (GCVE-0-2024-56788)

Vulnerability from cvelistv5 – Published: 2025-01-11 12:35 – Updated: 2026-08-05 11:46
VLAI
Title
net: ethernet: oa_tc6: fix tx skb race condition between reference pointers
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.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 53fbde8ab21e8c2c6187159cc17fc10cbf20900a , < 1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775 (git)
Affected: 53fbde8ab21e8c2c6187159cc17fc10cbf20900a , < e592b5110b3e9393881b0a019d86832bbf71a47f (git)
Create a notification for this product.
Linux Linux Affected: 6.12
Unaffected: 0 , < 6.12 (semver)
Unaffected: 6.12.7 , ≤ 6.12.* (semver)
Unaffected: 6.13 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/oa_tc6.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775",
              "status": "affected",
              "version": "53fbde8ab21e8c2c6187159cc17fc10cbf20900a",
              "versionType": "git"
            },
            {
              "lessThan": "e592b5110b3e9393881b0a019d86832bbf71a47f",
              "status": "affected",
              "version": "53fbde8ab21e8c2c6187159cc17fc10cbf20900a",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/oa_tc6.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.12"
            },
            {
              "lessThan": "6.12",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.13",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.7",
                  "versionStartIncluding": "6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13",
                  "versionStartIncluding": "6.12",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s 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\ttx_credits = 10; /* 21 are filled in the previous transfer */\n\tongoing_tx_skb = 20;\n\twaiting_tx_skb = NULL; /* Still NULL */\n- So, (tc6-\u003eongoing_tx_skb || tc6-\u003ewaiting_tx_skb) becomes true.\n- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\n\tongoing_tx_skb = 10;\n\twaiting_tx_skb = NULL; /* Still NULL */\n- Perform SPI transfer.\n- Process SPI rx buffer to get the TXC from footers.\n- Now let\u0027s assume previously filled 21 TXCs are freed so we are good to\ntransport the next remaining 10 tx chunks from ongoing_tx_skb.\n\ttx_credits = 21;\n\tongoing_tx_skb = 10;\n\twaiting_tx_skb = NULL;\n- So, (tc6-\u003eongoing_tx_skb || tc6-\u003ewaiting_tx_skb) becomes true again.\n- In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\n\tongoing_tx_skb = NULL;\n\twaiting_tx_skb = NULL;\n\n- Now the below bad case might happen,\n\nThread1 (oa_tc6_start_xmit)\tThread2 (oa_tc6_spi_thread_handler)\n---------------------------\t-----------------------------------\n- if waiting_tx_skb is NULL\n\t\t\t\t- if ongoing_tx_skb is NULL\n\t\t\t\t- ongoing_tx_skb = waiting_tx_skb\n- waiting_tx_skb = skb\n\t\t\t\t- waiting_tx_skb = NULL\n\t\t\t\t...\n\t\t\t\t- 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\u0027t access the\nwaiting_tx_skb pointer until the current thread completes moving the tx\nskb reference safely."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The race is driven by the interface transmit path, which an unauthenticated remote host drives by sending traffic that this device replies to, routes, or bridges out the 10BASE-T1S port \u2014 a common role for LAN865x gateways in automotive and industrial deployments.\nAC:L - The attacker controls both sides of the race: their packet flood drives `oa_tc6_start_xmit()` and simultaneously wakes the SPI kthread that races it, so sustained traffic hits the unsynchronized window repeatedly rather than depending on any condition outside the attacker\u0027s influence.\nPR:N - There is no capability check, authentication gate, or privileged interface anywhere on the path \u2014 merely causing frames to be transmitted out the interface is enough, which a remote unauthenticated peer accomplishes with ordinary traffic.\nUI:N - No victim action is required; the race triggers on normal packet transmission driven entirely by the attacker.\nS:U - The lost skb and the resulting memory exhaustion stay within the kernel\u0027s own security authority, with no crossing of a VM, IOMMU, or sandbox boundary.\nC:N - The defect destroys a pointer rather than dereferencing an invalid one; no freed, out-of-bounds, or uninitialized memory is ever read, and no kernel address is disclosed to userspace or the wire.\nI:N - No memory is corrupted and no attacker-controlled write primitive exists \u2014 I confirmed the two pointers can never alias, so there is no double-free or use-after-free; the dropped frame is data loss, which counts under availability.\nA:H - Every occurrence permanently leaks a full skb with no reclaim path, and a remote attacker can drive it indefinitely, exhausting memory on the RAM-constrained embedded targets this driver ships on and leading to OOM; frames are also silently dropped without even a `tx_dropped` accounting bump."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:46:29.921Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775"
        },
        {
          "url": "https://git.kernel.org/stable/c/e592b5110b3e9393881b0a019d86832bbf71a47f"
        }
      ],
      "title": "net: ethernet: oa_tc6: fix tx skb race condition between reference pointers",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-56788",
    "datePublished": "2025-01-11T12:35:47.985Z",
    "dateReserved": "2024-12-29T11:26:39.770Z",
    "dateUpdated": "2026-08-05T11:46:29.921Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-56788",
      "date": "2026-08-05",
      "epss": "0.00236",
      "percentile": "0.1462"
    },
    "fkie_nvd": {
      "descriptions": "[{\"lang\": \"en\", \"value\": \"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\u0027s 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\\ttx_credits = 10; /* 21 are filled in the previous transfer */\\n\\tongoing_tx_skb = 20;\\n\\twaiting_tx_skb = NULL; /* Still NULL */\\n- So, (tc6-\u003eongoing_tx_skb || tc6-\u003ewaiting_tx_skb) becomes true.\\n- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\\n\\tongoing_tx_skb = 10;\\n\\twaiting_tx_skb = NULL; /* Still NULL */\\n- Perform SPI transfer.\\n- Process SPI rx buffer to get the TXC from footers.\\n- Now let\u0027s assume previously filled 21 TXCs are freed so we are good to\\ntransport the next remaining 10 tx chunks from ongoing_tx_skb.\\n\\ttx_credits = 21;\\n\\tongoing_tx_skb = 10;\\n\\twaiting_tx_skb = NULL;\\n- So, (tc6-\u003eongoing_tx_skb || tc6-\u003ewaiting_tx_skb) becomes true again.\\n- In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\\n\\tongoing_tx_skb = NULL;\\n\\twaiting_tx_skb = NULL;\\n\\n- Now the below bad case might happen,\\n\\nThread1 (oa_tc6_start_xmit)\\tThread2 (oa_tc6_spi_thread_handler)\\n---------------------------\\t-----------------------------------\\n- if waiting_tx_skb is NULL\\n\\t\\t\\t\\t- if ongoing_tx_skb is NULL\\n\\t\\t\\t\\t- ongoing_tx_skb = waiting_tx_skb\\n- waiting_tx_skb = skb\\n\\t\\t\\t\\t- waiting_tx_skb = NULL\\n\\t\\t\\t\\t...\\n\\t\\t\\t\\t- 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\u0027t access the\\nwaiting_tx_skb pointer until the current thread completes moving the tx\\nskb reference safely.\"}]",
      "id": "CVE-2024-56788",
      "lastModified": "2025-01-11T13:15:29.090",
      "published": "2025-01-11T13:15:29.090",
      "references": "[{\"url\": \"https://git.kernel.org/stable/c/1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}, {\"url\": \"https://git.kernel.org/stable/c/e592b5110b3e9393881b0a019d86832bbf71a47f\", \"source\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]",
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Received"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-56788\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-01-11T13:15:29.090\",\"lastModified\":\"2026-08-04T11:22:27.453\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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\u0027s 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\\ttx_credits = 10; /* 21 are filled in the previous transfer */\\n\\tongoing_tx_skb = 20;\\n\\twaiting_tx_skb = NULL; /* Still NULL */\\n- So, (tc6-\u003eongoing_tx_skb || tc6-\u003ewaiting_tx_skb) becomes true.\\n- After oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\\n\\tongoing_tx_skb = 10;\\n\\twaiting_tx_skb = NULL; /* Still NULL */\\n- Perform SPI transfer.\\n- Process SPI rx buffer to get the TXC from footers.\\n- Now let\u0027s assume previously filled 21 TXCs are freed so we are good to\\ntransport the next remaining 10 tx chunks from ongoing_tx_skb.\\n\\ttx_credits = 21;\\n\\tongoing_tx_skb = 10;\\n\\twaiting_tx_skb = NULL;\\n- So, (tc6-\u003eongoing_tx_skb || tc6-\u003ewaiting_tx_skb) becomes true again.\\n- In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs()\\n\\tongoing_tx_skb = NULL;\\n\\twaiting_tx_skb = NULL;\\n\\n- Now the below bad case might happen,\\n\\nThread1 (oa_tc6_start_xmit)\\tThread2 (oa_tc6_spi_thread_handler)\\n---------------------------\\t-----------------------------------\\n- if waiting_tx_skb is NULL\\n\\t\\t\\t\\t- if ongoing_tx_skb is NULL\\n\\t\\t\\t\\t- ongoing_tx_skb = waiting_tx_skb\\n- waiting_tx_skb = skb\\n\\t\\t\\t\\t- waiting_tx_skb = NULL\\n\\t\\t\\t\\t...\\n\\t\\t\\t\\t- 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\u0027t access the\\nwaiting_tx_skb pointer until the current thread completes moving the tx\\nskb reference safely.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: oa_tc6: arregla la condici\u00f3n de ejecuci\u00f3n de tx skb entre punteros de referencia Hay dos punteros skb para administrar los tx skb en cola desde la pila n/w. El puntero waiting_tx_skb apunta al tx skb que necesita ser procesado y el puntero progress_tx_skb apunta al tx skb que est\u00e1 siendo procesado. El hilo SPI prepara los fragmentos de datos de tx desde el tx skb apuntado por el puntero progress_tx_skb. Cuando se procesa el tx skb apuntado por progress_tx_skb, el tx skb apuntado por progress_tx_skb se asigna a progress_tx_skb y el puntero waiting_tx_skb se asigna con NULL. Siempre que haya un nuevo skb tx de la pila n/w, se asignar\u00e1 al puntero waiting_tx_skb si es NULL. Puesta en cola y procesamiento de un skb tx gestionado en dos subprocesos diferentes. Considere un escenario donde el subproceso SPI proces\u00f3 un going_tx_skb y mueve el siguiente skb tx del puntero waiting_tx_skb al puntero going_tx_skb sin hacer ninguna comprobaci\u00f3n NULL. En este momento, si el puntero waiting_tx_skb es NULL, entonces el puntero going_tx_skb tambi\u00e9n se asigna con NULL. Despu\u00e9s de eso, si un nuevo skb tx se asigna al puntero waiting_tx_skb por la pila n/w y existe la posibilidad de sobrescribir el puntero skb tx con NULL en el subproceso SPI. Finalmente, uno de los skb tx quedar\u00e1 como sin gestionar, lo que resultar\u00e1 en la p\u00e9rdida de paquetes y p\u00e9rdida de memoria. - Considere el siguiente escenario donde el TXC informado de la transferencia anterior es 10 y progress_tx_skb contiene una trama Ethernet de transmisi\u00f3n que se puede transportar en 20 TXC y waiting_tx_skb sigue siendo NULL. tx_credits = 10; /* 21 se completan en la transferencia anterior */ progress_tx_skb = 20; waiting_tx_skb = NULL; /* Sigue siendo NULL */ - Entonces, (tc6-\u0026gt;ongoing_tx_skb || tc6-\u0026gt;waiting_tx_skb) se vuelve verdadero. - Despu\u00e9s de oa_tc6_prepare_spi_tx_buf_for_tx_skbs() progress_tx_skb = 10; waiting_tx_skb = NULL; /* Sigue siendo NULL */ - Realizar transferencia SPI. - Procesar el b\u00fafer de recepci\u00f3n SPI para obtener el TXC de los pies de p\u00e1gina. - Ahora supongamos que los 21 TXC previamente completados se liberan, por lo que estamos listos para transportar los siguientes 10 fragmentos de tx restantes desde progress_tx_skb. tx_credits = 21; progress_tx_skb = 10; waiting_tx_skb = NULL; - Entonces, (tc6-\u0026gt;ongoing_tx_skb || tc6-\u0026gt;waiting_tx_skb) se vuelve verdadero nuevamente. - En oa_tc6_prepare_spi_tx_buf_for_tx_skbs() progress_tx_skb = NULL; waiting_tx_skb = NULL; - Ahora, el siguiente caso malo podr\u00eda ocurrir, Thread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler) --------------------------- ----------------------------------- - si waiting_tx_skb es NULL - si going_tx_skb es NULL - going_tx_skb = waiting_tx_skb - waiting_tx_skb = skb - waiting_tx_skb = NULL ... - going_tx_skb = NULL - si waiting_tx_skb es NULL - waiting_tx_skb = skb Para superar el problema anterior, proteja el movimiento de la referencia tx skb del puntero waiting_tx_skb al puntero going_tx_skb y asigne el nuevo tx skb al puntero waiting_tx_skb, de modo que el otro hilo no pueda acceder al puntero waiting_tx_skb hasta que el hilo actual complete el movimiento de la referencia tx skb de manera segura.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/net/ethernet/oa_tc6.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"53fbde8ab21e8c2c6187159cc17fc10cbf20900a\",\"lessThan\":\"1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"53fbde8ab21e8c2c6187159cc17fc10cbf20900a\",\"lessThan\":\"e592b5110b3e9393881b0a019d86832bbf71a47f\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/net/ethernet/oa_tc6.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"6.12\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"6.12\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.7\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.13\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":7.5,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":3.9,\"impactScore\":3.6},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":4.7,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.0,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-362\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.12\",\"versionEndExcluding\":\"6.12.7\",\"matchCriteriaId\":\"BB2B083D-CB9D-4D06-9284-5BCF6F66A34C\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"62567B3C-6CEE-46D0-BC2E-B3717FBF7D13\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"5A073481-106D-4B15-B4C7-FB0213B8E1D4\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"DE491969-75AE-4A6B-9A58-8FC5AF98798F\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e592b5110b3e9393881b0a019d86832bbf71a47f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "None",
      "current_release_date": "2025-11-25T09:01:18+00:00",
      "cve": "CVE-2024-56788",
      "id": "CVE-2024-56788",
      "initial_release_date": "2024-01-01T00:00:00+00:00",
      "product_status:known_not_affected": "198",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: net: ethernet: oa_tc6: fix tx skb race condition between reference pointers",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-56788.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-07-17T13:20:10Z",
      "cve": "CVE-2024-56788",
      "id": "CVE-2024-56788",
      "initial_release_date": "2025-01-12T00:14:20Z",
      "product_status:known_not_affected": "344",
      "product_status:recommended": "53",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2024-56788",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-56788.json",
      "version": "20"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.