Skip to content
Heist/ feed
Back to feed
HighFix available

iommupt: Fix short gather if the unmap goes into a large mapping

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: iommupt: Fix short gather if the unmap goes into a large mapping unmap has the odd behavior that it can unmap more than requested if the ending point lands within the middle of a large or contiguous IOPTE. In this case the gather should flush everything unmapped which can be larger than what was requested to be unmapped. The gather was only flushing the range requested to be unmapped, not extending to the extra range, resulting in a short invalidation if the caller hits this special condition. This was found by the new invalidation/gather test I am adding in preparation for ARMv8. Claude deduced the root cause. As far as I remember nothing relies on unmapping a large entry, so this is likely not a triggerable bug.

Products
Kernel
Affected versions
Not specified
Fixed versions
6.19.12
CVEs
CVE-2026-31735
Confirmed fixed CVEs
Not specified
Updated in this feed
2 Nov 2026, 16:17 UTC · Revision 1

Source evidence

iommupt: Fix short gather if the unmap goes into a large mapping

core-osv · Original source

Published 1 May 2026, 14:14 UTC

In the Linux kernel, the following vulnerability has been resolved: iommupt: Fix short gather if the unmap goes into a large mapping unmap has the odd behavior that it can unmap more than requested if the ending point lands within the middle of a large or contiguous IOPTE. In this case the gather should flush everything unmapped which can be larger than what was requested to be unmapped. The gather was only flushing the range requested to be unmapped, not extending to the extra range, resulting in a short invalidation if the caller hits this special condition. This was found by the new invalidation/gather test I am adding in preparation for ARMv8. Claude deduced the root cause. As far as I remember nothing relies on unmapping a large entry, so this is likely not a triggerable bug.

osv:CVE-2026-31735

Kernel

Fixed versions: 6.19.12

Complete source record
{
  "id": "2329dd433da32c7fb6de4e999db0ef3f07d51c9b4f932cc795b7dc138665144f",
  "url": "https://osv.dev/vulnerability/CVE-2026-31735",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "iommupt: Fix short gather if the unmap goes into a large mapping",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: iommupt: Fix short gather if the unmap goes into a large mapping unmap has the odd behavior that it can unmap more than requested if the ending point lands within the middle of a large or contiguous IOPTE. In this case the gather should flush everything unmapped which can be larger than what was requested to be unmapped. The gather was only flushing the range requested to be unmapped, not extending to the extra range, resulting in a short invalidation if the caller hits this special condition. This was found by the new invalidation/gather test I am adding in preparation for ARMv8. Claude deduced the root cause. As far as I remember nothing relies on unmapping a large entry, so this is likely not a triggerable bug.",
    "evidence": "osv:CVE-2026-31735",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.19.12",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-31735",
      "aliases": [
        "CVE-2026-31735"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "7c53f4238aa8bfb476e177263133ead2eeb8d55d"
                },
                {
                  "fixed": "50ecd96a28f712f8b682c0441f4cb9b086d28816"
                },
                {
                  "fixed": "ee6e69d032550687a3422504bfca3f834c7b5061"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31735.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "6.19.12"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31735.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:20.894808409Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/50ecd96a28f712f8b682c0441f4cb9b086d28816",
        "https://git.kernel.org/stable/c/ee6e69d032550687a3422504bfca3f834c7b5061",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31735.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-31735",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31735.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-31735",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 487028,
  "published_at": "2026-05-01T14:14:32.923+00:00"
}