CVE-2022-48853 in Linux
Summary
by MITRE • 07/16/2024
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: fix info leak with DMA_FROM_DEVICE
The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204.
A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV). 4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer. 5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails.
One can argue that this is an swiotlb problem, because without swiotlb we leak all zeros, and the swiotlb should be transparent in a sense that it does not affect the outcome (if all other participants are well behaved).
Copying the content of the original buffer into the swiotlb buffer is the only way I can think of to make swiotlb transparent in such scenarios. So let's do just that if in doubt, but allow the driver to tell us that the whole mapped buffer is going to be overwritten, in which case we can preserve the old behavior and avoid the performance impact of the extra bounce.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2024
The vulnerability CVE-2022-48853 addresses a sensitive information disclosure issue within the Linux kernel's scatter-gather DMA implementation, specifically affecting the software I/O translation buffer (swiotlb) mechanism. This flaw manifests when handling DMA operations with the DMA_FROM_DEVICE direction flag, creating a potential information leak that could expose previously stored data from kernel memory regions. The vulnerability stems from improper handling of bounce buffer operations during SCSI command processing, where data from previous I/O operations inadvertently leaks into user-space buffers through the swiotlb mechanism. The issue was identified through the Linux Test Project (LTP) test suite, specifically covering the CVE-2018-1000204 test case, which exercises the SCSI TEST UNIT READY (TUR) command with specific transfer parameters that trigger the problematic code path.
The technical implementation flaw occurs within the SCSI generic (sg) subsystem where the sg_start_req() function processes commands using the SG_IO interface with specific parameters including dxfer_len set to 524288 bytes and dxdfer_dir set to SG_DXFER_FROM_DEV. During this process, blk_rq_map_user() creates a bounce buffer for user-space memory mapping, but the system incorrectly handles the DMA direction assumption for the TUR command which should not actually read from the device. The virtio-scsi device mapping through virtqueue_add_split() employs DMA_FROM_DEVICE for input scatter-gather operations, which triggers swiotlb bouncing. When the SCSI operation completes, the system copies data from the swiotlb bounce buffer (containing potentially stale data) back to the original bounce buffer, and subsequently to the user-space buffer, resulting in information leakage from previous operations. This behavior violates the fundamental principle that swiotlb should remain transparent to the system's operation, as defined in the Linux kernel's DMA mapping subsystem design.
The operational impact of this vulnerability extends beyond simple information disclosure, as it represents a potential security risk that could expose sensitive data from kernel memory regions to unprivileged userspace processes. The flaw specifically affects systems utilizing virtualized environments with virtio-scsi devices, particularly those requiring secure execution contexts such as s390 Secure Execution or AMD SEV environments where swiotlb is mandatory for memory protection. Attackers could potentially exploit this vulnerability to extract kernel memory contents, including potentially sensitive data from previous I/O operations, by crafting specific SCSI commands that trigger the problematic code path. The vulnerability affects the broader Linux kernel ecosystem through the swiotlb subsystem, which is used across multiple device drivers and virtualization platforms, making it a critical security concern for enterprise and cloud environments. The performance implications are also significant since the fix requires additional memory copying operations to ensure data integrity, though this is necessary to maintain the security properties of the DMA subsystem.
The recommended mitigation strategy involves implementing a conditional data copying mechanism within the swiotlb implementation that preserves the original buffer content when the driver indicates that the entire mapped buffer will be overwritten, thus avoiding unnecessary performance overhead while maintaining security. This approach aligns with the Common Weakness Enumeration (CWE) category CWE-200, which addresses improper information disclosure, and follows the ATT&CK framework's technique T1005 for Data from Local System, where attackers could potentially extract sensitive information from kernel memory regions. The fix should be applied to all Linux kernel versions that support the affected swiotlb functionality, particularly those running virtualized environments or systems requiring secure DMA operations. Organizations should prioritize patching this vulnerability as part of their regular security maintenance procedures, especially in environments where kernel memory exposure could lead to privilege escalation or data breach scenarios. The solution maintains the security properties of the swiotlb subsystem while ensuring that the transparent behavior expected of DMA operations is preserved, thus preventing information leakage without compromising system functionality or performance in legitimate use cases.