| Message ID | 1525464111-1096-1-git-send-email-linuxram@us.ibm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | eabdb8ca8690eedd461e61ea7780595fbbae8132 |
| Headers | show |
| Series | powerpc/pkeys: Detach execute_only key on !PROT_EXEC | expand |
Ram Pai <linuxram@us.ibm.com> writes: > Disassociate the exec_key from a VMA if the VMA permission is not > PROT_EXEC anymore. Otherwise the exec_only key continues to be > associated with the vma, causing unexpected behavior. > > The problem was reported on x86 by Shakeel Butt, > which is also applicable on powerpc. > > cc: Shakeel Butt <shakeelb@google.com> > Reported-by: Shakeel Butt <shakeelb@google.com> > Fixes 5586cf6 ("powerpc: introduce execute-only pkey") ^ Missing a colon here. > Signed-off-by: Ram Pai <linuxram@us.ibm.com> > --- > arch/powerpc/mm/pkeys.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c > index e81d59e..fdeb9f5 100644 > --- a/arch/powerpc/mm/pkeys.c > +++ b/arch/powerpc/mm/pkeys.c > @@ -425,9 +425,9 @@ int __arch_override_mprotect_pkey(struct vm_area_struct *vma, int prot, > { > /* > * If the currently associated pkey is execute-only, but the requested > - * protection requires read or write, move it back to the default pkey. > + * protection is not execute-only, move it back to the default pkey. > */ > - if (vma_is_pkey_exec_only(vma) && (prot & (PROT_READ | PROT_WRITE))) > + if (vma_is_pkey_exec_only(vma) && (prot != PROT_EXEC)) > return 0; > > /* I think I'm slow today. It took me a while to figure out why this is buggy. It will leave the VMA with the execute-only pkey if prot = 0. Other bit combinations work fine IIUC. Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> -- Thiago Jung Bauermann IBM Linux Technology Center
On Fri, 2018-05-04 at 20:01:51 UTC, Ram Pai wrote: > Disassociate the exec_key from a VMA if the VMA permission is not > PROT_EXEC anymore. Otherwise the exec_only key continues to be > associated with the vma, causing unexpected behavior. > > The problem was reported on x86 by Shakeel Butt, > which is also applicable on powerpc. > > cc: Shakeel Butt <shakeelb@google.com> > Reported-by: Shakeel Butt <shakeelb@google.com> > Fixes 5586cf6 ("powerpc: introduce execute-only pkey") > Signed-off-by: Ram Pai <linuxram@us.ibm.com> > Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/eabdb8ca8690eedd461e61ea778059 cheers
diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c index e81d59e..fdeb9f5 100644 --- a/arch/powerpc/mm/pkeys.c +++ b/arch/powerpc/mm/pkeys.c @@ -425,9 +425,9 @@ int __arch_override_mprotect_pkey(struct vm_area_struct *vma, int prot, { /* * If the currently associated pkey is execute-only, but the requested - * protection requires read or write, move it back to the default pkey. + * protection is not execute-only, move it back to the default pkey. */ - if (vma_is_pkey_exec_only(vma) && (prot & (PROT_READ | PROT_WRITE))) + if (vma_is_pkey_exec_only(vma) && (prot != PROT_EXEC)) return 0; /*
Disassociate the exec_key from a VMA if the VMA permission is not PROT_EXEC anymore. Otherwise the exec_only key continues to be associated with the vma, causing unexpected behavior. The problem was reported on x86 by Shakeel Butt, which is also applicable on powerpc. cc: Shakeel Butt <shakeelb@google.com> Reported-by: Shakeel Butt <shakeelb@google.com> Fixes 5586cf6 ("powerpc: introduce execute-only pkey") Signed-off-by: Ram Pai <linuxram@us.ibm.com> --- arch/powerpc/mm/pkeys.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)