Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 25 Mar 2021 15:55:40 -0400 (EDT)
From:   Nicolas Pitre <nico@fluxnic.net>
To:     Jann Horn <jannh@google.com>
cc:     Russell King - ARM Linux admin <linux@armlinux.org.uk>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        kernel list <linux-kernel@vger.kernel.org>,
        Tavis Ormandy <taviso@google.com>
Subject: Re: ARM FDPIC_FUNCPTRS personality flag handling looks broken
In-Reply-To: <CAG48ez1wLkMCiyY+bWVonXZr2TjzhwKZjNZLD3Ads=Rds8YJSw@mail.gmail.com>
Message-ID: <72pn55r-r95-9ns6-7p9r-4940r6834nq9@syhkavp.arg>
References: <CAG48ez1wLkMCiyY+bWVonXZr2TjzhwKZjNZLD3Ads=Rds8YJSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Thu, 25 Mar 2021, Jann Horn wrote:

> Hi!
> 
> Tavis noticed that on ARM kernels with CONFIG_BINFMT_ELF_FDPIC, it
> looks like the FDPIC_FUNCPTRS personality flag is not reset on
> execve(). This would mean that if a process first executes an ELF
> FDPIC binary (which forces the personality to PER_LINUX_FDPIC), and
> then executes a non-FDPIC binary, the signal handling code
> (setup_return()) will have bogus behavior (interpreting a normal
> function pointer as an FDPIC function handle).
> 
> I think FDPIC_FUNCPTRS should probably either be reset on every
> execve() or not be a personality flag at all (since AFAIU pretty much
> the whole point of personality flags is that they control behavior
> even across execve()).

I think you're right. This is probably true for SH as well.
I'd recommend the former solution as being the least intrusive one.


Nicolas