Описание
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: use the adjusted address for the highmem page lookup
swiotlb_bounce() reads the page frame number from the slot's recorded
orig_addr, then advances orig_addr by tlb_offset to reach the address
the caller asked about. The highmem branch mixes the two: the offset
within the page comes from the adjusted address, the page from the value
before it.
Once the adjustment crosses a page boundary the pair no longer describes
one location, and the whole copy lands one page below the intended one
for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE
writes the device data over the wrong page and leaves the intended one
stale, DMA_TO_DEVICE feeds the device from a page the mapping may not
cover. Partial syncs through dma_sync_single_range_for_*() are what make
tlb_offset non-zero.
The branch test is picked the same way, so a slot recorded in lowmem can
be adjusted into highmem and the lowmem path then hands a highmem
address to phys_to_virt().
Take both from orig_addr once it is final and keep pfn in the branch
that uses it. PhysHighMem() asks the question straight from the address,
as dma-debug already does.
A flaw was found in the Linux kernel's Software I/O Translation Lookaside Buffer (swiotlb). During Direct Memory Access (DMA) bounce operations involving high memory, an incorrect address calculation occurs when an offset crosses a page boundary. This error causes data transfers to read from or overwrite unintended memory pages instead of the targeted buffer. Consequently, this flaw can lead to memory corruption, data leakage, or a denial of service via a system crash.
Отчет
A page calculation error in swiotlb_bounce can combine the page frame from the original DMA address with the offset from the adjusted address. When a partial DMA synchronization uses a nonzero tlb_offset and crosses a page boundary, DMA_FROM_DEVICE can overwrite the wrong highmem page while DMA_TO_DEVICE can expose data from a page outside the intended mapping to the device. This is a concrete wrong page read and write primitive with potential memory corruption rather than a warning only condition. For the CVSS the PR:L is selected because a local user or process must access an affected device interface and initiate driver operations that reach the partial DMA synchronization path. AC:H reflects the required SWIOTLB and highmem configuration, a suitable driver path, and a range adjustment that crosses a page boundary. The issue is not classified as directly network reachable because the generic SWIOTLB code does not establish a remote trigger without a specific network driver path. Impact is at least denial of service and limited confidentiality or integrity impact.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Affected | ||
| Red Hat Enterprise Linux 6 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel | Affected | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Affected | ||
| Red Hat Enterprise Linux 9 | kernel | Affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Affected |
Показывать по
Дополнительная информация
Статус:
7 High
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: swiotlb: use the adjusted address for the highmem page lookup swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it. Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero. The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then...
In the Linux kernel, the following vulnerability has been resolved: swiotlb: use the adjusted address for the highmem page lookup swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it. Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero. The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path the
swiotlb: use the adjusted address for the highmem page lookup
In the Linux kernel, the following vulnerability has been resolved: s ...
In the Linux kernel, the following vulnerability has been resolved: swiotlb: use the adjusted address for the highmem page lookup swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it. Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero. The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path ...
7 High
CVSS3