linux-kernel - Re: ARM FDPIC_FUNCPTRS personality flag handling looks broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 25 Mar 2021 15:55:40 -0400 (EDT)
From:   Nicolas Pitre <nico@...xnic.net>
To:     Jann Horn <jannh@...gle.com>
cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        Tavis Ormandy <taviso@...gle.com>
Subject: Re: ARM FDPIC_FUNCPTRS personality flag handling looks broken

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