CVE-2024-56788
Vulnerability from cvelistv5
Published
2025-01-11 12:35
Modified
2025-01-20 06:28
Severity ?
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/1f2eb6c32bae04b375bb7a0aedbeefb6dbbcb775
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e592b5110b3e9393881b0a019d86832bbf71a47f
Impacted products
Vendor Product Version
Linux Linux Version: 53fbde8ab21e8c2c6187159cc17fc10cbf20900a
Version: 53fbde8ab21e8c2c6187159cc17fc10cbf20900a
 Create a notification for this product.
   Linux Linux Version: 6.12
 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"
            }
          ]
        }
      ],
      "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."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-01-20T06:28:11.456Z",
        "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-5f407fcff5a0"
      }
    }
  },
  "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": "2025-01-20T06:28:11.456Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-56788\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-01-11T13:15:29.090\",\"lastModified\":\"2025-01-11T13:15:29.090\",\"vulnStatus\":\"Received\",\"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.\"}],\"metrics\":{},\"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\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.