lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 23 Mar 2022 12:16:33 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Robin Murphy <robin.murphy@....com> Cc: Oleksandr Natalenko <oleksandr@...alenko.name>, Halil Pasic <pasic@...ux.ibm.com>, Christoph Hellwig <hch@....de>, Marek Szyprowski <m.szyprowski@...sung.com>, Toke Høiland-Jørgensen <toke@...e.dk>, Kalle Valo <kvalo@...nel.org>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Olha Cherevyk <olha.cherevyk@...il.com>, iommu <iommu@...ts.linux-foundation.org>, linux-wireless <linux-wireless@...r.kernel.org>, Netdev <netdev@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, stable <stable@...r.kernel.org> Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP On Wed, Mar 23, 2022 at 12:06 PM Robin Murphy <robin.murphy@....com> wrote: > > On 2022-03-23 17:27, Linus Torvalds wrote: > > > > I'm assuming that the ath9k issue is that it gives DMA mapping a big > > enough area to handle any possible packet size, and just expects - > > quite reasonably - smaller packets to only fill the part they need. > > > > Which that "info leak" patch obviously breaks entirely. > > Except that's the exact case which the new patch is addressing Not "addressing". Breaking. Which is why it will almost certainly get reverted. Not doing DMA to the whole area seems to be quite the sane thing to do for things like network packets, and overwriting the part that didn't get DMA'd with zeroes seems to be exactly the wrong thing here. So the SG_IO - and other random untrusted block command sources - data leak will almost certainly have to be addressed differently. Possibly by simply allocating the area with GFP_ZERO to begin with. Linus
Powered by blists - more mailing lists