On 02/29/2016 12:15 PM, Kirill A. Shutemov wrote:
> On Mon, Feb 29, 2016 at 11:11:37AM -0800, Andrey Wagin wrote:
>> > Hello Everyone,
>> >
>> > I found that now we can't write into a vma if it was mapped without PROT_READ:
>> >
>> > mmap(NULL, 4096, PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2ac7eb8000
>> > --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7f2ac7eb8000} ---
>> > +++ killed by SIGSEGV (core dumped) +++
>> > Segmentation fault
>> > [root@linux-next-test ~]# cat test.c
>> > #include <sys/mman.h>
>> > #include <stdlib.h>
>> >
>> > int main()
>> > {
>> > int *p;
>> >
>> > p = mmap(NULL, 4096, PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>> > p[0] = 1;
>> >
>> > return 0;
>> > }
>> >
>> > [root@linux-next-test ~]# uname -a
>> > Linux linux-next-test 4.5.0-rc6-next-20160229 #1 SMP Mon Feb 29
>> > 17:38:25 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > This issue appeared in 4.5.0-rc5-next-20160226.
>> >
>> > https://ci.openvz.org/job/CRIU-linux-next/152/console
> Looks like the regression is caused by change in access_error() by commit
> 62b5f7d013fc ("mm/core, x86/mm/pkeys: Add execute-only protection keys support")
> as per next-20160229.
>
> /*
> * Assume all accesses require either read or execute
> * permissions. This is not an instruction access, so
> * it requires read permissions.
> */
> if (!(vma->vm_flags & VM_READ))
> return 1;
>
> The assumption is false, taking this testcase into account.
I'm taking a look at it. I might just be able to remove that check, but
I need to do a little due diligence with the execute-only support and
make sure I'm not breaking it.
Thanks for reporting this, btw!
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
