HowToFixMe
● High · CVSS 7.8 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2011-1823: Android vold Root Privilege Escalation (Gingerbreak)

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 7.8 - High (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Attack vectorLocal privilege escalation - a local app gains root
Actively exploited?Yes, listed in CISA KEV (added 2022-09-08); weaponised as Gingerbreak
AffectedAndroid 3.0 and Android 2.x before 2.3.4 (the vold daemon)
Fixed inAndroid 2.3.4 (vold/netd patch commits)
Type (CWE)CWE-190 Integer Overflow or Wraparound (signedness check bypass)

Exploitation status

CVE-2011-1823 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Android OS Privilege Escalation Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: this is the exact flaw weaponised by Gingerbreak, a one-click root tool published in April 2011 and distributed openly through XDA-Developers and the c-skills research blog (both linked in the references below). Working attack code has been in wide circulation for over a decade, which is why CISA lists it as actively exploited. Treat weaponisation as certain and patch on an emergency timeline.

Patch immediately. CISA's Known Exploited Vulnerabilities catalog lists this CVE, which means active exploitation has been confirmed. CISA KEV entry added 2022-09-08, federal due date 2022-09-29.

What is CVE-2011-1823?

CVE-2011-1823 is a local privilege escalation flaw in vold, the volume manager daemon that ships as part of the Android operating system. It affects Android 3.0 and every Android 2.x release before 2.3.4. The daemon listens on a PF_NETLINK socket for kernel uevents that signal storage being added or removed, and it trusts those messages without validating who sent them. Any local process can forge a netlink message and feed it to vold.

The bug lives in DirectVolume::handlePartitionAdded. That method takes the partition minor number from the message and uses it as an array index, but it only checks the value against a maximum, not against zero. Because the index is a signed integer, a crafted negative value slips past the maximum-only check and lets the attacker write outside the intended bounds. That out-of-bounds write corrupts memory inside a process that runs as root, and a carefully chosen payload turns the corruption into arbitrary code execution. The result is a clean jump from an ordinary unprivileged app to full root. NVD classifies the root cause as CWE-190 (integer overflow or wraparound); in practice it is a signedness error in a bounds check.

This is not a theoretical bug. It is the exact vulnerability behind Gingerbreak, the one-click root utility that circulated widely in 2011 for Gingerbread-era phones. Because Gingerbreak shipped as a packaged tool, reliable exploit code has been freely available since disclosure.

Why this CVE matters

A local app that the user installs from a store or a sideloaded APK normally lives in its own sandbox with very limited permissions. CVE-2011-1823 erases that boundary. A malicious app that asks for nothing unusual at install time can quietly escalate to root, then read every other app's private data, disable security controls, install a persistent backdoor, or survive a factory reset by writing to system partitions. Because the attack runs entirely on-device and needs no user interaction beyond running the app, it is an ideal payload to bundle inside a repackaged game or utility.

CISA placed this CVE on its Known Exploited Vulnerabilities catalog in September 2022, which only happens once active exploitation is observed. For any fleet of older Android handsets still in service - kiosks, point-of-sale tablets, industrial handhelds, or BYOD devices on legacy builds - an unpatched device should be treated as a device that can be fully owned by any app running on it.

Am I affected?

You are affected if the device runs Android 3.0 or any Android 2.x build older than 2.3.4. Check the running build directly on the device or over ADB - there is no Linux package or Windows installer to query here, because the flaw is in the Android OS itself.

# On-device: Settings > About phone > Android version
# Over ADB from a workstation:
adb shell getprop ro.build.version.release    # e.g. 2.3.3  -> vulnerable
adb shell getprop ro.build.version.sdk        # API 10 = 2.3.3, API 11 = 3.0

# Any release string below 2.3.4 (and Android 3.0 / Honeycomb) is vulnerable.

If the reported version is 2.3.4 or higher, or the device received an OTA that carried the vold/netd fix commits, you are not affected.

How to fix CVE-2011-1823

The fix is an Android OS update. Google corrected the signedness check in Android 2.3.4; the change lives in the vold, netd, and core repositories (the exact commits are linked in the references). There is no apt, dnf, MSI, or Windows Update path for this - that machinery does not apply to an Android handset. The remediation depends on how the device receives software:

  1. Take the OEM / carrier OTA. On a device that is still supported, open Settings > About phone > System updates and install any pending update that moves the build to 2.3.4 or later. This is the only vendor-blessed fix and the one to prefer.
  2. Sideload the official update package. If the OTA is offered but stalls, download the signed update ZIP for your exact model from the OEM support site and apply it from stock recovery (adb sideload update.zip). Do not flash a package built for a different model.
  3. Move to a maintained ROM built on a patched base. For devices the OEM abandoned below 2.3.4, a community ROM whose Android base is 2.3.4 or newer carries the fixed vold. Verify the ROM's base version before relying on it.
  4. Retire the device from sensitive use. Many handsets in this range can never reach 2.3.4. If that is your situation, the only honest fix is to stop using the device for anything that handles credentials, payments, or personal data.

After the update completes and the device reboots, confirm the build number changed before you trust the fix.

If you can't patch immediately

Patching to Android 2.3.4 is the only thing that removes the flaw. Because this is a local escalation (CVSS vector AV:L), there is no network service to firewall and no WAF rule that helps. The exploit runs from an app already on the device, so every mitigation here is about controlling what code gets to run:

How to verify the fix worked

After the OTA or sideload, re-read the build version and confirm it is at or above the fixed release.

adb shell getprop ro.build.version.release    # expect 2.3.4 or higher
adb shell getprop ro.build.fingerprint         # confirm it matches the patched OEM build

# Sanity-check that an unprivileged shell can no longer escalate:
adb shell id                                   # should report a normal uid, not uid=0(root)

If the device was ever rooted with Gingerbreak or exposed to an untrusted app while unpatched, do not assume the update alone cleans it. A root-level compromise can persist across an OS update. For anything that handled sensitive data, the safe path is a factory reset followed by the update, then re-provisioning from a known-good backup and rotating any account credentials that were stored on or typed into the device.

Frequently asked questions

Which Android versions are vulnerable to CVE-2011-1823?

Android 3.0 and every Android 2.x release before 2.3.4. Google fixed the vold flaw in Android 2.3.4 (Gingerbread). A device reporting 2.3.4 or later is not affected.

Is CVE-2011-1823 remotely exploitable?

No. The CVSS vector is AV:L - a local attack. An attacker needs code already running on the device, normally a malicious or trojanised app the user installed. There is no internet-facing service to firewall; the only fix is the OS update.

Is there a public exploit for CVE-2011-1823?

Yes. This is the flaw weaponised by Gingerbreak, a packaged root tool published in April 2011 and still freely available. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2022-09-08.

How do I fix it if my device cannot reach Android 2.3.4?

For end-of-life hardware, the realistic options are a vendor or carrier firmware update if one exists, a maintained custom ROM built on a patched Android base, or retiring the device from sensitive use. Limiting app installs to trusted sources lowers the odds of a local app triggering the bug but does not remove it.

References

This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

How the Gingerbreak bug works in detail

Understanding the mechanism makes the remediation obvious. Android's vold daemon manages mountable volumes such as the external SD card. When the kernel detects a storage change, it broadcasts a uevent over a netlink socket. vold reads that event and, for an "add" event, calls DirectVolume::handlePartitionAdded with the partition's major and minor device numbers parsed straight from the message text.

The minor number is then used to index an internal array tracking partitions. The validation only asked whether the value exceeded an upper limit. It never asked whether the value was below zero. Because the field is a signed integer, a forged event carrying a negative minor number passes the upper-bound test and is used as a negative array index. Writing through a negative index lands outside the allocated structure and corrupts adjacent memory in the root-owned vold process. Gingerbreak shapes that corruption to redirect execution and hand the calling app a root shell.

Two things make this reliable enough to ship as a consumer root tool. First, the netlink socket is unauthenticated, so any local process can inject the malicious event. Second, vold runs as root by design, so a single memory-corruption primitive there is a direct path to the highest privilege on the device. The Android 2.3.4 fix adds a lower-bound check (rejecting negative and otherwise out-of-range minor numbers) across the vold, netd, and core code so the forged index is discarded before it ever touches the array.

What this means for fleet owners

If you operate Android devices in the affected range at scale, prioritise by exposure to untrusted code rather than by network reachability, because the network does not matter here. A locked-down single-purpose kiosk that can only ever run one signed app is far lower risk than a general-purpose tablet where staff sideload tools. Inventory every device's build number, flag everything below 2.3.4, and route those devices into one of the four remediation paths above. For devices that cannot be updated and cannot be retired, the strongest available control is an MDM policy that blocks unknown-source installs and enforces an app allowlist, paired with the understanding that the control reduces likelihood but does not close the hole.

Keep a written record of which devices reached 2.3.4 and which were retired, because "we patched the fleet" is only true once every device's build number is verified individually. A half-updated fleet leaves the unpatched remainder fully exploitable by any app a user installs.

Nearby vulnerabilities you may as well remediate alongside this fix:

People also ask

Which Android versions are vulnerable to CVE-2011-1823?

Android 3.0 and every Android 2.x release before 2.3.4. Google fixed the vold flaw in Android 2.3.4 (Gingerbread). A device reporting 2.3.4 or later is not affected.

Is CVE-2011-1823 remotely exploitable?

No. The CVSS vector is AV:L, a local attack. An attacker needs code already running on the device, normally a malicious or trojanised app the user installed. There is no internet-facing service to firewall; the only fix is the OS update.

Is there a public exploit for CVE-2011-1823?

Yes. This is the flaw weaponised by Gingerbreak, a packaged root tool published in April 2011 and still freely available. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2022-09-08.