linux-kernel - Re: KASAN: use-after-free Write in keyspan

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: <Yys5tGHLo4AFcA3E@kroah.com>
Date:   Wed, 21 Sep 2022 18:20:04 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Rondreis <linhaoguo86@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        johan@...nel.org
Subject: Re: KASAN: use-after-free Write in keyspan_close

On Wed, Sep 21, 2022 at 11:45:17PM +0800, Rondreis wrote:
> Thank you for your reply!
> 
> This is a “fake” device. We emulated some functions with the built-in
> gadget module as a virtual device side for fuzzing. It can pass through
> the matching phase and, to some extent the probing phase.
> As you said, the configuration options are correct.

But this fake device does not follow the protocol of the real device,
right?  So how is any fake data sent/received by it to fuzz?

> After a successful attachment, we extracted the file_operations
> of the device files on both sides to find the corresponding system calls.

open/read/write/close?  :)

> Later, by fuzzing the dual-sided device with system calls, it is
> equivalent to considering data threats from both peripheral and user space.

So you are now treating this device as malicious.

If so, wonderful, that means you now need to audit the driver and fix
all of the assumptions that we made when it was written as it was a
trusted device at that point in time.

Not to say that this is a bad thing, just that you are testing something
that the original code was never designed to even consider, so you will
find problems.

Any help you can in fixing them would be appreciated, and then we can
move on to all of the others that we have as all of them were also
written to assume that we trust the hardware, as that was the Linux
security model at the time (also all other operating system's model, we
are not unique here.)

My point being, this is going to be a long slog if you wish to change
the model that Linux was originally designed for.  Perhaps you should
look into some way to "trace" the data paths to find where USB data is
received and acted on before it can be "trusted".  Much like we
currently do today for userspace memory pointers.

That will be a much better solution overall, so that we can then use
that model to fix all drivers, and prevent any future changes from also
causing problems.

Then you can turn that model to other busses, which for now we also
consider trusted, but some people wish to change that.

So don't focus on this one tiny driver, try working on the root issue
here please.

good luck!

greg k-h