All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@au1.ibm.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Laurent Dufour <ldufour@linux.vnet.ibm.com>,
	mpe@ellerman.id.au
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] powerpc/pseries: Fix stack corruption in htpe code
Date: Fri, 07 Oct 2016 10:08:06 +1100	[thread overview]
Message-ID: <1475795286.3784.226.camel@au1.ibm.com> (raw)
In-Reply-To: <877f9lo713.fsf@linux.vnet.ibm.com>

On Thu, 2016-10-06 at 20:32 +0530, Aneesh Kumar K.V wrote:
> Laurent Dufour <ldufour@linux.vnet.ibm.com> writes:
> 

(Off-list)

Did that bug make it to RHEL/CentOS/SLES ?

We also need to poke Ubuntu to get the fix ASAP.

> > This commit fixes a stack corruption in the pseries specific code
> > dealing
> > with the huge pages.
> > 
> > In __pSeries_lpar_hugepage_invalidate() the buffer used to pass
> > arguments
> > to the hypervisor is not large enough. This leads to a stack
> > corruption
> > where a previously saved register could be corrupted leading to
> > unexpected
> > result in the caller, like the following panic:
> > 
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > SMP NR_CPUS=2048 NUMA pSeries
> > Modules linked in: virtio_balloon ip_tables x_tables autofs4
> > virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio
> > CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 #76
> > task: c000000005394880 task.stack: c000000005570000
> > NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000
> > REGS: c000000005573820 TRAP: 0300   Not tainted  (4.8.0)
> > MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 84822884  XER:
> > 20000000
> > CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE:
> > 1
> > GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800
> > c000000004447964
> > GPR04: c00000000404de18 c000000004d38810 00000000042100f5
> > 00000000f5002104
> > GPR08: e0000000f5002104 0000000000000001 042100f5000000e0
> > 00000000042100f5
> > GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18
> > 0000000000000000
> > GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0
> > 00003fff63000000
> > GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0
> > 0000000000010000
> > GPR24: c000000004d38810 c000000004447c10 c00000000404de18
> > c000000004447964
> > GPR28: c000000005573b10 c000000004d38810 00003fff62000000
> > 420000000014e5e0
> > NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470
> > LR [c00000000027bf64] zap_huge_pmd+0x44/0x470
> > Call Trace:
> > [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470
> > (unreliable)
> > [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0
> > [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120
> > [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0
> > [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0
> > [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0
> > [c000000005573e30] [c000000000009560] system_call+0x38/0x108
> > Instruction dump:
> > fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378
> > f821ffb1
> > 7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78
> > 7fc4f378
> > 
> > Most of the time, the bug is surfacing in a caller up in the stack
> > from
> > __pSeries_lpar_hugepage_invalidate() which is quite confusing.
> > 
> > This bug is pending since v3.11 but was hidden if a caller of the
> > caller of __pSeries_lpar_hugepage_invalidate() has pushed the
> > corruped
> > register (r18 in this case) in the stack and is not using it until
> > restoring it. GCC 6.2.0 seems to raise it more frequently.
> > 
> > This commit also change the definition of the parameter buffer in
> > pSeries_lpar_flush_hash_range() to rely on the global define
> > PLPAR_HCALL9_BUFSIZE (no functional change here).
> > 
> 
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> 
> > 
> > Fixes: 1a5272866f87 ("powerpc: Optimize hugepage invalidate")
> > Cc: <stable@vger.kernel.org>
> > Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> > ---
> >  arch/powerpc/platforms/pseries/lpar.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/powerpc/platforms/pseries/lpar.c
> > b/arch/powerpc/platforms/pseries/lpar.c
> > index 86707e67843f..aa35245d8d6d 100644
> > --- a/arch/powerpc/platforms/pseries/lpar.c
> > +++ b/arch/powerpc/platforms/pseries/lpar.c
> > @@ -393,7 +393,7 @@ static void
> > __pSeries_lpar_hugepage_invalidate(unsigned long *slot,
> >  					     unsigned long *vpn,
> > int count,
> >  					     int psize, int ssize)
> >  {
> > -	unsigned long param[8];
> > +	unsigned long param[PLPAR_HCALL9_BUFSIZE];
> >  	int i = 0, pix = 0, rc;
> >  	unsigned long flags = 0;
> >  	int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
> > @@ -522,7 +522,7 @@ static void
> > pSeries_lpar_flush_hash_range(unsigned long number, int local)
> >  	unsigned long flags = 0;
> >  	struct ppc64_tlb_batch *batch =
> > this_cpu_ptr(&ppc64_tlb_batch);
> >  	int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
> > -	unsigned long param[9];
> > +	unsigned long param[PLPAR_HCALL9_BUFSIZE];
> >  	unsigned long hash, index, shift, hidx, slot;
> >  	real_pte_t pte;
> >  	int psize, ssize;
> > -- 
> > 2.7.4

  reply	other threads:[~2016-10-06 23:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06 13:33 [PATCH] powerpc/pseries: Fix stack corruption in htpe code Laurent Dufour
2016-10-06 15:02 ` Aneesh Kumar K.V
2016-10-06 23:08   ` Benjamin Herrenschmidt [this message]
2016-10-10  9:36     ` Laurent Dufour
2016-10-09 22:05   ` Balbir Singh
2016-10-06 23:06 ` Benjamin Herrenschmidt
2016-10-19  2:17 ` Michael Ellerman

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=1475795286.3784.226.camel@au1.ibm.com \
    --to=benh@au1.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=stable@vger.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.