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

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] [day] [month] [year] [list]

Date:   Mon, 24 Aug 2020 10:22:16 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jiri Slaby <jirislaby@...nel.org>
Cc:     syzbot <syzbot+ad1f53726c3bd11180cb@...kaller.appspotmail.com>,
        akpm@...ux-foundation.org, jslaby@...e.cz,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, nico@...xnic.net,
        syzkaller-bugs@...glegroups.com
Subject: Re: KASAN: use-after-free Write in vcs_read

On Mon, Aug 24, 2020 at 10:03:54AM +0200, Jiri Slaby wrote:
> On 22. 08. 20, 9:34, Jiri Slaby wrote:
> > On 22. 08. 20, 9:31, syzbot wrote:
> >> syzbot has bisected this issue to:
> >>
> >> commit b1c32fcfadf5593ab7a63261cc8a5747c36e627e
> >> Author: Jiri Slaby <jslaby@...e.cz>
> >> Date:   Tue Aug 18 08:57:05 2020 +0000
> >>
> >>     vc_screen: extract vcs_read_buf_header
> > 
> > It's like 7th e-mail about the very same issue. Can it be
> > suspended/acknowledged somehow?
> > 
> >> Reported-by: syzbot+ad1f53726c3bd11180cb@...kaller.appspotmail.com
> > 
> > I haven't managed to find the root cause on Fri yet, I will chase it on
> > Mon again.
> 
> Ah, I see now. And the easiest way of handling this is simply revert the
> commit now, re-think and redo during the next merge window.
> 
> There are two issues with the patch:
> 1) vcs_read rounds the 'count' up to an even number. So if we read odd
> bytes from the header (3 in the reproducer), the second byte of
> (2-byte/ushort) write to temporary con_buf won't fit. It is because with
> the patch applied, we only subtract the real number read (3 bytes) and
> not the whole header (4 bytes).
> 
> 2) in this scenario, we perform unaligned accesses now. 2-byte/ushort
> writes to odd addresses. Due to the same reason as above.
> 
> So Greg, could you revert with the above reasoning? It reverts cleanly.
> Or do you want me to send a revert?

If you send a revert it is always easier for me to apply that :)

thanks,

greg k-h