LiveActive security incident?Get immediate response
CVE Record

CVE-2024-35818: LoongArch: Define the __io_aw() hook as mmiowb()

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Define the __io_aw() hook as mmiowb() Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says: "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation." The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio. So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). And we no longer need to override queued_spin_unlock() so use the generic definition. Without this, we get such an error when run 'glxgears' on weak ordering architectures such as LoongArch: radeon 0000:04:00.0: ring 0 stalled for more than 10324msec radeon 0000:04:00.0: ring 3 stalled for more than 10240msec radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3) radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysisunknown

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue affects LoongArch systems where hardware I/O writes may occur out of order. The cited failure mode is Radeon GPU lockups during normal graphics use, causing operational instability rather than a documented remote compromise path.

Executive priority

Treat as targeted operational risk for affected LoongArch Linux systems, not a broad internet-exposed emergency. Prioritize remediation where GPU stability or specialized hardware workloads matter.

Technical view

The fix defines the LoongArch __io_aw() hook as mmiowb() to preserve MMIO write ordering after earlier driver-level mmiowb() removals. The source specifically describes mutex-protected MMIO in radeon_ring_commit(), with possible relevance to other mutex-protected MMIO paths.

Likely exposure

Exposure appears limited to Linux on LoongArch or similarly weakly ordered MMIO contexts, especially systems using affected kernel versions and Radeon graphics. The source does not identify cloud, network, or userland attack surfaces.

Exploitation context

No active exploitation is cited, and KEV is false in the provided bundle. The public description shows a reliability failure observed by running glxgears, not a weaponized exploit scenario.

Researcher notes

The evidence is narrow: LoongArch architecture code, MMIO ordering, and Radeon symptoms. The source says Radeon is not the only possible mutex-protected MMIO example, but it does not enumerate additional affected drivers.

Mitigation direction

  • Check vendor kernel advisories for CVE-2024-35818 guidance.
  • Update to a kernel build containing the referenced stable commits.
  • Prioritize LoongArch hosts with Radeon or MMIO-heavy device drivers.
  • Avoid inventing driver workarounds unless vendor guidance supports them.

Validation and detection

  • Inventory LoongArch Linux systems and running kernel versions.
  • Compare installed kernels against vendor-fixed releases or referenced stable commits.
  • Review kernel logs for Radeon ring stalls or GPU lockup messages.
  • Regression-test normal graphics workloads after kernel updates.
Prepared
Confidence
medium
Sources
7

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2024-35818 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
2ADP providers
6Source links

SSVC decision data

CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: partial

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
CVECVE Program Container

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxfa96b57c149061f71a70bd6582d995f6424fbbf4, fa96b57c149061f71a70bd6582d995f6424fbbf4, fa96b57c149061f71a70bd6582d995f6424fbbf4, fa96b57c149061f71a70bd6582d995f6424fbbf4, fa96b57c149061f71a70bd6582d995f6424fbbf4unaffected
LinuxLinux5.19, 0, 6.1.84, 6.6.24, 6.7.12, 6.8.3, 6.9affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.