CVE-2023-52910

What it actually does

Integer overflow in __alloc_and_insert_iova_range when retry_pfn wraps from anchor.pfn_hi (~0UL) allows low_pfn to reset to 0 and new_pfn < low_pfn checks to incorrectly succeed, granting IOVA allocations that exceed domain limits or reuse invalid ranges.

Why it matters to the business

Systems may experience kernel memory mapping failures, DMA device misbehavior, or crashes; high downstream prevalence in Linux distributions and Android increases exposure across servers, embedded devices, and mobile platforms with delayed patching raising operational risk.

How an attack unfolds

An attacker triggers repeated large IOVA allocation requests that exceed domain size or force cached_node to anchor, causing the overflow path during retry; the resulting invalid allocation succeeds and can be used to map unauthorized physical ranges for subsequent DMA or corruption primitives.

How to fix it

Apply the upstream fix in commit c929a230c84441e400c32e7b7b4ab763711fb63e; for Android update platform/external/libavc to the 2021-07-01 patched revisions in branches 8.1, 9, 10, and 11; rebuild and deploy kernels with the corrected IOVA retry logic.

How to confirm the fix worked

Confirm kernel source contains the retry_pfn + 1 guard before limit_pfn comparison; test allocation sequences that previously overflowed now correctly fail; monitor for absence of the described log patterns showing new_pfn_lo below cached_node after large requests.

Typical attack path

1. Identify IOVA domain with large initial allocation or deleted high-pfn nodes
2. Request IOVA size exceeding remaining domain capacity to enter retry logic
3. Trigger pfn_hi + 1 overflow so low_pfn becomes 0
4. Obtain successful but invalid IOVA mapping
5. Leverage mapping for DMA-based memory access or denial of service

How to detect it

Review kernel logs for __alloc_and_insert_iova_range messages containing retry_pfn:0x0 and new->pfn_lo values below start_pfn; correlate with processes performing repeated large DMA-BUF or IOMMU map operations; inspect for unexpected successful allocations after domain size checks.

• __alloc_and_insert_iova_range start_pfn:.*retry_pfn:0x0
• new->pfn_lo:.*new->pfn_hi:.*success.*size exceeding domain

What your security team should do

• Prioritize kernel updates on all Linux-based hosts and Android devices within 30 days given ecosystem reach
• Audit custom IOVA or IOMMU domain initialization code for similar pfn arithmetic assumptions
• Enable kernel address space layout randomization and IOMMU strict mode where hardware supports it
• Incorporate IOVA allocation stress tests into CI pipelines