[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUvVMBAK-uWR28u4CzJZYo=mKsqoqd+y84L=GdgwAQJVA@mail.gmail.com>
Date: Sat, 29 Aug 2015 09:34:47 -0700
From: Andy Lutomirski <luto@...capital.net>
To: cve-assign@...re.org
Cc: oss security list <oss-security@...ts.openwall.com>
Subject: Re: CVE Request: Linux x86_64 NT flag issue - Linux kernel
On Mon, Aug 24, 2015 at 8:21 PM, <cve-assign@...re.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>> When I fixed Linux's NT flag handling, I added an optimization to
>> Linux 3.19 and up. A malicious 32-bit program might be able to leak
>> NT into an unrelated task. On a CONFIG_PREEMPT=y kernel, this is a
>> straightforward DoS. On a CONFIG_PREEMPT=n kernel, it's probably
>> still exploitable for DoS with some more care.
>>
>> I believe that this could be used for privilege escalation, too, but
>> it won't be easy.
>>
>> The fix is just to revert the optimization:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=512255a2ad2c832ca7d4de9f31245f73781922d0
>>
>> Mitigation: CONFIG_IA32_EMULATION=n
>
> Use CVE-2015-6666.
I think this may be a false alarm. SDM Volume 3 6.12.1.2 says:
On calls to exception and interrupt handlers, the processor also
clears the VM, RF, and NT flags in the EFLAGS register, after
they are saved on the stack.
So if an interrupt or page fault happened while NT was incorrectly
set, the NT flag would still be clear when context switching and would
therefore never leak. (This wouldn't have been the case before 3.19,
when we could context switch by calling schedule() directly while NT
was set, but those kernels manually saved and restored flags across
context switches.)
--Andy
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
