GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-5XF5-GQ7P-JFX7

Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-04-02 12:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

spi: tegra210-quad: Protect curr_xfer check in IRQ handler

Now that all other accesses to curr_xfer are done under the lock, protect the curr_xfer NULL check in tegra_qspi_isr_thread() with the spinlock. Without this protection, the following race can occur:

CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->curr_xfer) // sees non-NULL spin_lock() tqspi->curr_xfer = NULL spin_unlock() handle_*_xfer() spin_lock() t = tqspi->curr_xfer // NULL! ... t->len ... // NULL dereference!

With this patch, all curr_xfer accesses are now properly synchronized.

Although all accesses to curr_xfer are done under the lock, in tegra_qspi_isr_thread() it checks for NULL, releases the lock and reacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer(). There is a potential for an update in between, which could cause a NULL pointer dereference.

To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared curr_xfer, the handler will safely return without dereferencing the NULL pointer.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-23207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-14T17:15:58Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: tegra210-quad: Protect curr_xfer check in IRQ handler\n\nNow that all other accesses to curr_xfer are done under the lock,\nprotect the curr_xfer NULL check in tegra_qspi_isr_thread() with the\nspinlock. Without this protection, the following race can occur:\n\n  CPU0 (ISR thread)              CPU1 (timeout path)\n  ----------------               -------------------\n  if (!tqspi-\u003ecurr_xfer)\n    // sees non-NULL\n                                 spin_lock()\n                                 tqspi-\u003ecurr_xfer = NULL\n                                 spin_unlock()\n  handle_*_xfer()\n    spin_lock()\n    t = tqspi-\u003ecurr_xfer  // NULL!\n    ... t-\u003elen ...        // NULL dereference!\n\nWith this patch, all curr_xfer accesses are now properly synchronized.\n\nAlthough all accesses to curr_xfer are done under the lock, in\ntegra_qspi_isr_thread() it checks for NULL, releases the lock and\nreacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer().\nThere is a potential for an update in between, which could cause a NULL\npointer dereference.\n\nTo handle this, add a NULL check inside the handlers after acquiring\nthe lock. This ensures that if the timeout path has already cleared\ncurr_xfer, the handler will safely return without dereferencing the\nNULL pointer.",
  "id": "GHSA-5xf5-gq7p-jfx7",
  "modified": "2026-04-02T12:31:04Z",
  "published": "2026-02-14T18:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23207"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2ac3a105e51496147c0e44e49466eecfcc532d57"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/84e926c1c272a35ddb9b86842d32fa833a60dfc7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/edf9088b6e1d6d88982db7eb5e736a0e4fbcc09e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…