Chrome OsOperating system · Google

CVE-2014-1710

HIGH · 7.5 CVSS v2.0 Published 2014-03-16
Fix available
A fix is available. Upgrade to after 33.0.1750.149 or later.
See remediation →
84/100
Remediation priority · High
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
The AsyncPixelTransfersCompletedQuery::End function in gpu/command_buffer/service/query_manager.cc in Google Chrome, as used in Google Chrome OS before 33.0.1750.152, does not check whether a certain position is within the bounds of a shared-memory segment, which allows remote attackers to cause a denial of service (GPU command-buffer memory corruption) or possibly have unspecified other impact via unknown vectors.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

This is a bounds checking vulnerability in the GPU command buffer service. The AsyncPixelTransfersCompletedQuery::End function in query_manager.cc fails to validate whether a position/index falls within the bounds of a shared-memory segment before accessing it. This allows an attacker to trigger out-of-bounds memory access, leading to GPU command-buffer memory corruption and potential code execution.

MitigationUpgrade Google Chrome/Chrome OS to version 33.0.1750.152 or later, which includes proper bounds checking in the query manager. This is a straightforward fix of adding validation before shared-memory position access.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Chrome OsOperating system
Affected:<= 33.0.1750.149= 33.0.1750.2= 33.0.1750.5= 33.0.1750.16= 33.0.1750.29= 33.0.1750.51= 33.0.1750.58= 33.0.1750.70= 33.0.1750.93= 33.0.1750.112= 33.0.1750.124

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Authentication
None
Confidentiality
Partial
Integrity
Partial
Availability
Partial

AV:N/AC:L/Au:N/C:P/I:P/A:P

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify the operating system product
    Determine if the system is running Google Chrome OS (not the Chrome browser on another OS). On Chrome OS, check the about Chrome OS page or run 'cat /etc/os-release' to confirm the OS.
    Affected if The system is running Chrome OS and not a standard Chrome browser on Windows/Mac/Linux
  2. Check the Chrome OS version
    Navigate to chrome://settings/help or run 'chrome --version' in the terminal to obtain the installed Chrome OS version number.
    Affected if The version is 33.0.1750.149 or earlier, or exactly matches one of these: 33.0.1750.2, 33.0.1750.5, 33.0.1750.16, 33.0.1750.29, 33.0.1750.51, 33.0.1750.58, 33.0.1750.70, 33.0.1750.93, 33.0.1750.112, or 33.0.1750.124
  3. Confirm GPU command buffer is in use
    The vulnerability exists in the GPU command buffer service (query_manager.cc). In Chrome OS, GPU hardware acceleration is typically enabled by default. Visit chrome://gpu to verify the GPU process status.
    Affected if GPU rendering is enabled and the browser is using the hardware GPU command buffer (as opposed to software rendering only)
  4. Verify the specific vulnerable component
    The flaw is in AsyncPixelTransfersCompletedQuery::End function within the query_manager module. This is an internal GPU component. There is no user-facing flag to check this; version-based detection is the primary method.
    Affected if The version is within the affected range and the GPU command buffer service is active

You are affected if you are running Chrome OS version 33.0.1750.149 or earlier, or exactly version 33.0.1750.2, 33.0.1750.5, 33.0.1750.16, 33.0.1750.29, 33.0.1750.51, 33.0.1750.58, 33.0.1750.70, 33.0.1750.93, 33.0.1750.112, or 33.0.1750.124 with GPU acceleration enabled.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

From vendor data
Upgrade available Upgrade to a release after 33.0.1750.149
Interim mitigation

Upgrade Google Chrome/Chrome OS to version 33.0.1750.152 or later, which includes proper bounds checking in the query manager. This is a straightforward fix of adding validation before shared-memory position access.

Fix this in Chrome Os Scoped from the published advisory
  • Consultation3.0 h
  • Implementation6.0 h
  • Testing5.0 h
  • Review / QA3.0 h
17.0 hours of engineering $2,970
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,752.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2014-1710 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2014-1710 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data