# CVE-2026-99063: dm ioctl: don't let data_start run past the buffer


- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Fix available:** Yes
- **Published:** 23 Oct 2026
- **Updated:** 23 Oct 2026
- **Also known as:** AZL-110954, BELL-CVE-2026-99063, DEBIAN-CVE-2026-99063, GHSA-vqpj-f54g-hrc3, UBUNTU-CVE-2026-99063

## What is CVE-2026-99063?

CVE-2026-99063 is a vulnerability in Linux, published on 23 Oct 2026. 

### Official description

In the Linux kernel, the following vulnerability has been resolved:

dm ioctl: don't let data_start run past the buffer

struct dm_ioctl has seven bytes of trailing padding, so the smallest
buffer userspace is allowed to ask for, offsetof(struct dm_ioctl, data),
is seven bytes shorter than sizeof(struct dm_ioctl).

get_result_buffer() sets data_start to sizeof(struct dm_ioctl) without
looking at how big the buffer actually is. Ask for the minimum and
data_start ends up seven bytes past the end. Callers add it to
data_size, and ctl_ioctl() copies that much back to userspace:

  BUG: KASAN: slab-out-of-bounds in _copy_to_user+0xad/0xd0
  Read of size 312 at addr ffff8880169e4c00 by task repro-dm/140
   ctl_ioctl+0x5e3/0xcb0
   dm_ctl_ioctl+0x25/0x40
  allocated 305-byte region [ffff8880169e4c00, ffff8880169e4d31)

A DM_LIST_DEVICES with data_size set to 305 is enough to hit it, and the
seven bytes that leak are whatever sat next to the allocation.

Clamp data_start to the buffer size.

Note that this is not a security bug because the out-of-bounds read can
only be triggered by root.

## Which versions are affected by CVE-2026-99063?


## How do I fix CVE-2026-99063?

Upgrade to a fixed version.

## Is CVE-2026-99063 being exploited?

There is no known exploitation of CVE-2026-99063 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-99063 and fix it if it is affected.

What it is: CVE-2026-99063 is a vulnerability in Linux, published on 23 Oct 2026. 
Exploitation: There is no known exploitation of CVE-2026-99063 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-99063/ (Markdown: https://insights.sbomify.com/CVE-2026-99063/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-99063
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-99063
- OSV: https://osv.dev/vulnerability/CVE-2026-99063

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-99063/
Summaries are generated and may contain mistakes; the official description above is the record.