CVE-2022-48801

What it actually does

Incorrect error handling in IIO_BUFFER_GET_FD_IOCTL after anon_inode_getfd() and fd_install() leads to a dangling file descriptor and file->private_data pointer, enabling userland-triggered use-after-free on the partially destructed file object.

Why it matters to the business

Local attackers on affected Linux systems can corrupt kernel memory structures, potentially leading to privilege escalation or system instability; the issue affects numerous Debian and Ubuntu kernel packages with high ecosystem prevalence in cloud and embedded deployments.

How an attack unfolds

An attacker invokes the ioctl to trigger fd creation, forces a copy_to_user failure, then reuses the still-valid fd to operate on the dangling private_data pointer left by the flawed put_unused_fd path; the Android kernel RCE context highlights potential for similar local UAF chaining in mobile and embedded Linux variants.

How to fix it

Upgrade to fixed kernel versions: Debian 11/12/13 to 5.10.103-1 or 5.16.7-1; Ubuntu 20.04/22.04 packages to the listed 5.15.0-*, 5.4.0-1020.24, or 5.15.0-23.23 equivalents; reboot into new kernel after package installation.

How to confirm the fix worked

Verify running kernel version matches or exceeds the per-distro fixed releases; inspect IIO buffer ioctl error paths in source for absence of put_unused_fd after fd_install; run regression tests exercising the ioctl failure case.

Typical attack path

1. Obtain local code execution on affected kernel
2. Call IIO_BUFFER_GET_FD_IOCTL to allocate fd via anon_inode_getfd
3. Induce copy_to_user failure to enter error path
4. Reuse the fd to dereference stale file->private_data
5. Trigger UAF to corrupt kernel structures or escalate privileges

How to detect it

Review kernel audit logs and syscall traces for repeated IIO_BUFFER_GET_FD_IOCTL calls followed by unexpected -EFAULT returns; look for process crashes or oops involving file private_data in dmesg or kdump artifacts around the time of suspicious local activity.

What your security team should do

• Prioritize kernel upgrades on all affected Debian and Ubuntu systems within standard maintenance windows
• Monitor EPSS and threat actor reports for any increase in exploit maturity
• Apply compensating controls such as kernel hardening features (e.g., KASAN, lockdown) where immediate patching is delayed