linux-kernel - Re: [PATCH] um: Fix overlapping ELF segments when statically linked

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 10 Mar 2020 14:24:22 -0700
From:   Brendan Higgins <brendanhiggins@...gle.com>
To:     David Gow <davidgow@...gle.com>
Cc:     Jeff Dike <jdike@...toit.com>, Richard Weinberger <richard@....at>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        Patricia Alfonso <trishalfonso@...gle.com>,
        linux-um <linux-um@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] um: Fix overlapping ELF segments when statically linked

On Thu, Mar 5, 2020 at 10:39 AM David Gow <davidgow@...gle.com> wrote:
>
> When statically linked, the .text section in UML kernels is not page
> aligned, causing it to share a page with the executable headers. As
> .text and the executable headers have different permissions, this causes
> the kernel to wish to map the same page twice (once as headers with r--
> permissions, once as .text with r-x permissions), causing a segfault,
> and a nasty message printed to the host kernel's dmesg:
>
> "Uhuuh, elf segment at 0000000060000000 requested but the memory is
> mapped already"
>
> By aligning the .text to a page boundary (as in the dynamically linked
> version in dyn.lds.S), there is no such overlap, and the kernel runs
> correctly.
>
> Signed-off-by: David Gow <davidgow@...gle.com>

I can confirm that I am seeing this problem as well. (I know we run
the same Linux distro; nevertheless, this is a real problem for some
population of users.)

Reviewed-by: Brendan Higgins <brendanhiggins@...gle.com>