Cloudanix VulnDB

CVE-2026-99063

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A small mistake in how the Linux kernel calculates buffer sizes for its device-mapper tool lets a system administrator accidentally read a few extra bytes of internal memory.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Incorrect calculation of data_start in get_result_buffer() allows an out-of-bounds read when copying results back from a dm_ioctl buffer that is smaller than sizeof(struct dm_ioctl) due to trailing padding; the kernel copies seven extra bytes from adjacent slab memory.

Why it matters to the business

A root user can leak a handful of bytes of adjacent kernel memory; no remote or unprivileged impact exists and the issue was already resolved in the kernel.

How an attack unfolds

An attacker with root privileges issues a DM_LIST_DEVICES ioctl requesting a 305-byte buffer; get_result_buffer() sets data_start past the end of the allocation, ctl_ioctl() adds data_size and copies the resulting length back to userspace, exposing whatever bytes sat next to the buffer.

How to fix it

Upgrade to a kernel containing the clamp of data_start to the actual buffer size; apply the fix that prevents data_start from exceeding the allocation length.

How to confirm the fix worked

Confirm the kernel source contains the added bounds check that forces data_start = min(data_start, buffer_size) before the copy_to_user call; recompile and boot the updated kernel, then verify no KASAN report occurs with the original reproducer.

Typical attack path

  1. Obtain root privileges on the target system
  2. Open /dev/mapper/control
  3. Prepare a dm_ioctl structure with data_size set to 305
  4. Invoke the DM_LIST_DEVICES ioctl
  5. Read the seven leaked bytes returned beyond the requested buffer

How to detect it

Search kernel logs for KASAN slab-out-of-bounds reports mentioning _copy_to_user and dm_ctl_ioctl; inspect audit logs for root processes issuing DM_LIST_DEVICES ioctls with unusually small data_size values.

What your security team should do

  • Patch Linux kernels to the version containing the data_start clamp within the normal update cycle
  • Restrict access to /dev/mapper/control to the minimum set of administrative accounts
  • Monitor kernel update channels for the published fix and include it in the next maintenance window

The record

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.

Affected packages

Ecosystem Package Introduced Fixed