Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

github логотип

GHSA-59vp-pw3x-2g3w

Опубликовано: 16 авг. 2025
Источник: github
Github: Не прошло ревью

Описание

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

drm/xe/pf: Clear all LMTT pages on alloc

Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages.

Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap.

While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle.

(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

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

drm/xe/pf: Clear all LMTT pages on alloc

Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages.

Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap.

While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle.

(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

EPSS

Процентиль: 4%
0.00022
Низкий

Связанные уязвимости

ubuntu
25 дней назад

In the Linux kernel, the following vulnerability has been resolved: drm/xe/pf: Clear all LMTT pages on alloc Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages. Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap. While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle. (cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

CVSS3: 7
redhat
26 дней назад

In the Linux kernel, the following vulnerability has been resolved: drm/xe/pf: Clear all LMTT pages on alloc Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages. Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap. While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle. (cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

nvd
25 дней назад

In the Linux kernel, the following vulnerability has been resolved: drm/xe/pf: Clear all LMTT pages on alloc Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages. Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap. While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle. (cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

debian
25 дней назад

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

oracle-oval
3 дня назад

ELSA-2025-20551: Unbreakable Enterprise kernel security update (IMPORTANT)

EPSS

Процентиль: 4%
0.00022
Низкий