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@xxxxxxx> > >> 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@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > 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
