CVE-2022-42533 - Unpacking the Android Kernel SharedMetadata.cpp Integer Overflow

In late 2022, a kernel vulnerability surfaced in Android that can allow an attacker with app-level access to escalate their privileges locally—without needing further user interaction or extra permissions. The issue, tracked as CVE-2022-42533, was uncovered in the SharedMetadata.cpp file, specifically in the shared_metadata_init function.

This write-up breaks down what went wrong, shows what the vulnerable code looks like, demonstrates how the bug can be exploited, and shares what you should know as a developer, security researcher, or Android user.

Interaction: None required (can be exploited without user help)

- Product/Targets: Android Kernel (all versions till patched)
- Google Android ID: A-239415718
- References/Advisories: Official Android Security Bulletin - November 2022

Vulnerable Code Details

The root cause is an integer overflow during memory allocation calculations in the shared_metadata_init function. When untrusted input is used to set the number of metadata entries, a large (often negative) value can wrap around, causing the allocation to be smaller than needed. Subsequent writes then exceed allocated memory boundaries.

Here’s what the vulnerable code could look like in simplified form

// Vulnerable snippet from SharedMetadata.cpp

int shared_metadata_init(int entry_count) {
    size_t alloc_size = entry_count * sizeof(metadata_entry); // Can overflow!
    struct metadata_entry* entries = (struct metadata_entry*)malloc(alloc_size);
    
    if (!entries) return -ENOMEM;
    
    for (int i = ; i < entry_count; i++) {
        // ... initialize entries[i] ...
        entries[i].field = ...; // Potential OOB write!
    }

    // ... other code ...
    return ;
}

Problem:
If entry_count is very large, say x40000000, then entry_count * sizeof(metadata_entry) can wrap around and produce a small value due to integer overflow. This causes the allocation to be insufficient, and the for-loop writes past the allocated buffer.

Exploitation Flow

1. Craft code or input to shared_metadata_init (directly or indirectly), passing a very large number for entry_count.
2. Trigger the function, causing the integer multiplication to wrap around due to exceeding the size_t max value.

Corruption of memory structures (kernel heap, critical meta-data).

6. Use-after-free or privilege escalation: with precise targeting, attacker can overwrite adjacent kernel structures such as process credentials—leading to a local privilege escalation (LPE).

Below is a pseudocode (not functional Android exploit!) for illustration

int fake_entry_count = x40000000;  // Large enough to cause overflow

// Call the vulnerable function
shared_metadata_init(fake_entry_count);

// After overflow, memory past "entries" is now corrupted
// Attacker may target kernel structures for privilege escalation!

What Could Happen?

If the attacker can control what memory lies adjacent to the under-allocated block, they may overwrite sensitive kernel data like task pointers, process credentials, or other security-critical structures—granting themselves higher privileges or disabling security policies.

References

- Android Security Bulletin - November 2022
- Google Android ID: A-239415718
- CWE-190: Integer Overflow or Wraparound
- Android CVE-2022-42533 NVD Entry

Example Patch

size_t alloc_size;
if (__builtin_mul_overflow(entry_count, sizeof(metadata_entry), &alloc_size)) {
    return -EINVAL; // Refuse dangerous values!
}

Update Android devices: Ensure your phone is updated to the November 2022 patch or later.

- Developers: Never trust input-derived arithmetic for buffer allocations. Always check for overflows!

Conclusion

CVE-2022-42533 is a real-world example of how a straightforward coding oversight—missing integer overflow—can lead to severe kernel-level security holes in Android. Because the bug allows local escalation without any extra permissions or user interaction, it’s critical for both users and developers to understand these risks and keep systems up to date.

Stay secure, verify your code, and always patch early!

Timeline

Published on: 11/17/2022 23:15:00 UTC
Last modified on: 11/22/2022 00:34:00 UTC