Kestrel
대시보드로 돌아가기
CVE-2026-90047UNKNOWNMITRENVD대응게시일: 2026. 09. 16.수정일: 2026. 09. 16.CNA: 416baaa9-dc9f-4396-8d5f-8c081fb06d67Received

In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't hand out the flat CCS storage as usable VRAM get_flat_cc

위협 신호 · CVSS · EPSS · KEV

정기 패치· 높은 악용 신호 없음
CVSS
unknown

이론적 심각도 점수

EPSS

예측 데이터 없음

KEV
미등재

실측 악용 기록 없음

권장 대응 기한60일 이내CISA SSVC 기준

계획된 패치 주기 내 조치(60일 이내)

외부 노출· KEV 미등재 · 자동화 어려움 · 부분 영향 · 외부 노출

CVSS 벡터 · 메트릭

CVSS 벡터 정보 없음

상세 설명

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

drm/xe: Don't hand out the flat CCS storage as usable VRAM

get_flat_ccs_offset() reads the base of the flat CCS storage from the
hardware, scales it by the number of enabled L3 nodes, and rounds the
result up to 128K. Everything below that offset is then handed to the
VRAM allocator as usable memory.

Rounding a limit that means "usable memory ends here" upwards publishes
whatever lies between the real base and the rounded one as free memory,
and that memory belongs to the compression hardware. The scaled value
has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it
is not:

text
1flat CCS base: raw 0x3fafff800, rounded 0x3fb000000

so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator's
pool. Whatever is allocated there gets that tail overwritten by the
compression hardware, which needs no page-table entry, no buffer object
and no GPU submission to do it, and does it before userspace exists.

On this machine a Mesa VM's level-3 page table landed on that page on
every cold boot. It lost the entry covering the compositor's
batch-buffer heap, so the compositor's first submission faulted fetching
its batch and gdm restarted it forever: a black screen on an otherwise
working machine. Restarting gdm cleared it because the next VM's page
tables were allocated somewhere else.

Round down instead, to the page size the allocator works in. On this
machine that excludes exactly one page.

Reading the reserved page afterwards shows what had been writing it:

text
1[369] 0xcccc000000000000
2[371] 0xcc77000000000000
3[373] 0xcccc000000000000
4[375] 0xcc77000000000000

compression metadata, two bytes per sixteen, sitting where the driver
used to hand out memory.

The assertion that should have caught this compares the offset against
GSMBASE - ccs_size for equality. That value is 128K aligned, so it
agrees with the rounded-up offset precisely when the base is not
aligned - the check cannot fail in the case it exists to catch, and is
compiled out unless CONFIG_DRM_XE_DEBUG is set. Replace it with one
that can fail: CCS storage must not run into GSM.

[ And this was a debug session from hell, enormously helped by an AI
doing much of the grunt-work.

I'd like to call it my tireless helper, but the AI several times
stated flat out that this was impossible and unsolvable and that we
should just write a report about it.

I suspect those things have been trained by people who may not be
quite as stubborn as I am.

But while the AI was ready to give up several times, it did keep
adding debug code and analyzing it faithfully when I pushed. So credit
where credit is due and I let the AI write the commit message above.

This is basically a one-liner fixing a bogus "round_up()" to a
"round_down()", but there were 24 patches adding more and more debug
information to this, and 18 kernel boot to finally narrow it down to
this. - Linus ]

AI 심층 분석

공격 시나리오 · 재현 가능한 PoC 페이로드 · 즉시 적용 가능한 차단 패치를 한 번에 받아 보세요. 보안 운영팀이 그대로 점검·티켓팅에 쓸 수 있는 형태로 정리해 드립니다.