linux-kernel - Validating dma_mmap_coherent() parameters before calling (was Re: WARNING in memtype

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]

Message-ID: <20200514062750.GA1488715@kroah.com>
Date:   Thu, 14 May 2020 08:27:50 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Hillf Danton <hdanton@...a.com>,
        syzbot <syzbot+353be47c9ce21b68b7ed@...kaller.appspotmail.com>,
        Thomas Gleixner <tglx@...utronix.de>, jeremy.linton@....com,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        syzkaller-bugs@...glegroups.com, x86@...nel.org
Subject: Validating dma_mmap_coherent() parameters before calling (was Re:
 WARNING in memtype_reserve)

On Thu, May 14, 2020 at 08:14:17AM +0200, Christoph Hellwig wrote:
> Guys, can you please start formal thread on this?  I have no
> idea where this came from and what the rationale is.  Btw, if the
> pfn is crap in dma_direct_mmap then the dma_addr_t passed in is
> crap, as it is derived from that.  What is the caller, and how is
> this triggered?

Ok, to summarize, commit 2bef9aed6f0e ("usb: usbfs: correct kernel->user
page attribute mismatch") changed a call from remap_pfn_range() to
dma_mmap_coherent() for usb data buffers being sent from userspace.

Details on why this was changed is in the commit changelog, but this has
triggered a WARN_ON() in memtype_reserve when I think some odd data
buffers were sent to it by syzbot fuzzing.

The warning caught the wrong data, but triggered syzbot.

So, the question is, should all callers of dma_mmap_coherent() validate
the parms better before it is called, or should the call chain here
properly sanitize things on their own.

Note, usbfs is not the only direct-from-userspace caller of
dma_mmap_coherent(), it's also used in other userspace apis (frame
buffer drivers, fastrpc, some SoC drivers) but it looks like nothing has
fuzzed those apis before to trigger this.

Does that help explain things better?

thanks,

greg k-h