linux-kernel - Re: BUG at drivers/iommu/amd

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Nov 2016 09:45:22 +0100
From:   Joerg Roedel <joro@...tes.org>
To:     Mark Hounschell <markh@...pro.net>
Cc:     iommu@...ts.linux-foundation.org,
        Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: BUG at drivers/iommu/amd_iommu.c:1436!

On Mon, Nov 21, 2016 at 04:47:59PM -0500, Mark Hounschell wrote:
> OK, I did get this message before the reported BUG message.
> 
> gpiohsd gpiohsd: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0xffffffffffee8000] [size=8192 bytes]
> 
> But I've verified that the dma_addr_t that I get for the alloc, and
> also use for the free is 0x00000000ffee8000 in this case? Is device
> "address=0xffffffffffee8000" in that message a bug in the message or
> do we have a sign extended address problem? It seems strange to me,
> I've never seen a dma_addr_t given, when using the iommu, that
> high. In the past I've seen them as usually 0x00xxxxxx?
> 
> I have also verified that simply changing from
> pci_alloc/free_consistent to the newer DMA API fixes my issue and I
> get no such messages.

Yes, this looks like a sign-extension bug somewhere. But its not in the
amd-iommu driver, because dma-debug also sees it. And from what I can
tell the dma-api interface seems to be fine. It consistently uses
dma_addr_t to pass these values around.

Where can I find the source of the failing code? I need exactly the code
version that triggers the problem.



	Joerg