Re: Re: Partial SMAP bypass on 64-bit Linux kernels

[Steve Grubb <sgrubb () redhat com>]

On Thursday, March 31, 2016 04:31:25 PM cve-assign () mitre org wrote:
> > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/urg
> > ent&id=3d44d51bd339766f0178f0cf2e8d048b4a4872aa
> >
> > That patch fixes a bug that exposed a fairly large kernel code surface
> > to a straightforward SMAP bypass.
> >
> > > From: Salvatore Bonaccorso <carnil () debian org>
> > > Date: Tue, 29 Mar 2016 17:00:03 +0200
> > >
> > > @MITRE CVE assignment team: Would it make sense to have a CVE id
> > > assigned for this issue for better trackability?
>
> We're going to approach this one in the same way as the issue that was
> later assigned CVE-2016-2847.
>
> Specifically, is there anyone who believes
> 3d44d51bd339766f0178f0cf2e8d048b4a4872aa must not have a CVE ID?
>
> The situation, very roughly, seems to be that the upstream vendor has
> announced that the behavior is a bug. CLAC occurs at a correct place
> for some types of entries, but accidentally did not occur at a correct
> place in the case of entries through the int80 gate. Consequently,
> exploits of kernel vulnerabilities can cause more damage in some
> cases.
>
> However, it seems to be a bug in how the kernel responds to a
> post-exploitation attack pattern. This is not a topic area that
> commonly has CVE ID assignments. Access by the kernel to a user space
> page is not an action that "crosses a privilege boundary" in a
> traditional sense.

What if an unprivileged application triggered a NULL pointer dereference that 
was supposed to be accessing a data structure in the kernel for a policy 
decision but instead used an attacker controlled structure mapped at address 
0?

-Steve