CVE-2022-48928

What it actually does

Missing iounmap() call in error path after iio_device_register() failure leaves prior ioremap() unbalanced, resulting in a kernel memory mapping leak.

Why it matters to the business

On affected Linux systems, repeated driver load/unload or error conditions can exhaust limited I/O memory resources, causing device registration failures or system instability.

How an attack unfolds

An attacker with local access triggers the men_z188_adc driver error path (e.g., via crafted device registration failure) to induce the unbalanced ioremap, though no public exploitation is known.

How to fix it

Apply the upstream fix from commit 0f88722313645a903f4d420ba61ddc690ec2481d or later stable kernel versions containing this patch; rebuild and deploy updated kernels across all affected systems.

How to confirm the fix worked

Inspect the men_z188_adc error handling path in the source to confirm presence of the iounmap() call immediately before returning from the failed iio_device_register() branch; verify driver loads cleanly under error injection tests.

Typical attack path

1. Obtain local user access on a system using the men_z188_adc driver
2. Force iio_device_register() to fail through resource contention or malformed device data
3. Trigger repeated error paths to accumulate unmapped I/O regions
4. Observe resource exhaustion or denial of service on subsequent operations

How to detect it

Review kernel logs for repeated men_z188_adc probe failures without corresponding iounmap activity; use memory mapping leak detectors or ioremap accounting tools on systems running vulnerable kernels.

What your security team should do

• Prioritize kernel updates on any systems exposing the men_z188_adc ADC driver
• Monitor for resource exhaustion symptoms in I/O memory mappings
• Audit custom or downstream kernel trees for the missing iounmap() pattern