lkml.org 
[lkml]   [2020]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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@suse.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@syzkaller.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

\
 
 \ /
  Last update: 2020-08-24 10:22    [W:0.061 / U:1.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site