CVE-2022-48853

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> swiotlb: fix info leak with DMA_FROM_DEVICE<br /> <br /> The problem I&amp;#39;m addressing was discovered by the LTP test covering<br /> cve-2018-1000204.<br /> <br /> A short description of what happens follows:<br /> 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO<br /> interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV<br /> and a corresponding dxferp. The peculiar thing about this is that TUR<br /> is not reading from the device.<br /> 2) In sg_start_req() the invocation of blk_rq_map_user() effectively<br /> bounces the user-space buffer. As if the device was to transfer into<br /> it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in<br /> sg_build_indirect()") we make sure this first bounce buffer is<br /> allocated with GFP_ZERO.<br /> 3) For the rest of the story we keep ignoring that we have a TUR, so the<br /> device won&amp;#39;t touch the buffer we prepare as if the we had a<br /> DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device<br /> and the buffer allocated by SG is mapped by the function<br /> virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here<br /> scatter-gather and not scsi generics). This mapping involves bouncing<br /> via the swiotlb (we need swiotlb to do virtio in protected guest like<br /> s390 Secure Execution, or AMD SEV).<br /> 4) When the SCSI TUR is done, we first copy back the content of the second<br /> (that is swiotlb) bounce buffer (which most likely contains some<br /> previous IO data), to the first bounce buffer, which contains all<br /> zeros. Then we copy back the content of the first bounce buffer to<br /> the user-space buffer.<br /> 5) The test case detects that the buffer, which it zero-initialized,<br /> ain&amp;#39;t all zeros and fails.<br /> <br /> One can argue that this is an swiotlb problem, because without swiotlb<br /> we leak all zeros, and the swiotlb should be transparent in a sense that<br /> it does not affect the outcome (if all other participants are well<br /> behaved).<br /> <br /> Copying the content of the original buffer into the swiotlb buffer is<br /> the only way I can think of to make swiotlb transparent in such<br /> scenarios. So let&amp;#39;s do just that if in doubt, but allow the driver<br /> to tell us that the whole mapped buffer is going to be overwritten,<br /> in which case we can preserve the old behavior and avoid the performance<br /> impact of the extra bounce.