---
id: CVE-2022-49963
title: |-
  In the Linux kernel, the following vulnerability has been resolved:

  drm/i915/ttm: fix CCS handling

  Crucible + recent Mesa seems to sometimes hit:

  GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER)

  And it looks like we can also trigger …
summary: |-
  In the Linux kernel, the following vulnerability has been resolved:

  drm/i915/ttm: fix CCS handling

  Crucible + recent Mesa seems to sometimes hit:

  GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER)

  And it looks like we can also trigger …
severity: high
cvss: 7.8
cvssVector: 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'
vendor: linux
product: linux_kernel
affected:
  - 'linux_kernel >= 5.19, < 5.19.8'
  - linux_kernel = 6.0
patched:
  - linux_kernel 5.19.8
published: '2025-06-18'
updated: '2026-10-15'
sourceUpdated: '2026-10-15T22:17:26.260'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2022-49963'
references:
  - url: 'https://git.kernel.org/stable/c/8d905254162965c8e6be697d82c7dbf5d08f574d'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/97434cb55bd884bd268626ec41489f79b261b2d4'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
epss: 0.0022
epssPercentile: 0.12495
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: total
  timestamp: '2026-10-15T21:29:52.414458Z'
ingestedAt: '2026-10-15T21:45:11.285Z'
---

## Overview

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

drm/i915/ttm: fix CCS handling

Crucible + recent Mesa seems to sometimes hit:

GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER)

And it looks like we can also trigger this with gem_lmem_swapping, if we
modify the test to use slightly larger object sizes.

Looking closer it looks like we have the following issues in
migrate_copy():

  - We are using plain integer in various places, which we can easily
    overflow with a large object.

  - We pass the entire object size (when the src is lmem) into
    emit_pte() and then try to copy it, which doesn't work, since we
    only have a few fixed sized windows in which to map the pages and
    perform the copy. With an object > 8M we therefore aren't properly
    copying the pages. And then with an object > 64M we trigger the
    GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER).

So it looks like our copy handling for any object > 8M (which is our
CHUNK_SZ) is currently broken on DG2.

Testcase: igt@gem_lmem_swapping
(cherry picked from commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)

## Affected

- `linux_kernel >= 5.19, < 5.19.8`
- `linux_kernel = 6.0`

## Remediation

Upgrade past the affected range:

- `linux_kernel 5.19.8`