All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stas Sergeev <stsp@list.ru>
To: Andy Lutomirski <luto@amacapital.net>, Brian Gerst <brgerst@gmail.com>
Cc: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Borislav Petkov <bp@alien8.de>,
	Stas Sergeev <stsp@users.sourceforge.net>
Subject: Re: 4.3 regression: task_work corruption in vm86 mode?
Date: Sat, 31 Oct 2015 14:50:38 +0300	[thread overview]
Message-ID: <5634AB0E.3060707@list.ru> (raw)
In-Reply-To: <CALCETrWUmL5bPyxR0gvchtn433hdnSqOuRdBjFsqJqa_xbtBnw@mail.gmail.com>

31.10.2015 08:43, Andy Lutomirski пишет:
> On Fri, Oct 30, 2015 at 6:44 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> Hi all-
>>
>> In 4.3-rc7, running dosemu2 (https://github.com/stsp/dosemu2/) oopses
>> the system very quickly, as long as CONFIG_VM86=y.  It blows up
>> because snd_seq_delete_port walks ports_list_head, finds two valid
>> ports, and then starts finding obviously invalid pointers in the list.
>>
>> git bisect blames:
>>
>> commit 5ed92a8ab71f8865ba07811429c988c72299b315
>> Author: Brian Gerst <brgerst@gmail.com>
>> Date:   Wed Jul 29 01:41:19 2015 -0400
>>
>>      x86/vm86: Use the normal pt_regs area for vm86
>>
>> I haven't spotted the problem yet.  It seems to happen when
>> task_work_run fires in get_signal, which happens before
>> save_v86_state.  I'm not entirely sure what causes task work to be
>> scheduled at all while in v86 land.  Could we somehow be processing
>> task_work later than we should?
>>
> Nope, the bug has nothing to do with task_work.  Patches sent.
Andy, thanks for finally fixing this attack surface!
So after all, the comments you put into Kconfig, were justified.
Now I can seriously consider the dosemu2-specific vm86-light.
Having the machine to crash, was not a good starting point for
the clean-ups.
Also there is an interesting thread here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1499089
I wonder if they are affected now by that bug or not...

      reply	other threads:[~2015-10-31 11:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-31  1:44 4.3 regression: task_work corruption in vm86 mode? Andy Lutomirski
2015-10-31  5:43 ` Andy Lutomirski
2015-10-31 11:50   ` Stas Sergeev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5634AB0E.3060707@list.ru \
    --to=stsp@list.ru \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dvlasenk@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=stsp@users.sourceforge.net \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.