[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1016718: marked as done (binfmt_elf: May fail to load executable with no static data next to BSS)

Your message dated Sat, 12 Jul 2025 17:55:35 +0200
with message-id <305e80d729131d0abdfc47fae0884a25f0d2f1e4.camel@decadent.org.uk>
and subject line Re: Bug#1016718: binfmt_elf: May fail to load executable with no static data next to BSS
has caused the Debian Bug report #1016718,
regarding binfmt_elf: May fail to load executable with no static data next to BSS
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1016718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016718
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Source: linux
Version: 5.19-1~exp1
Severity: normal
Tags: upstream

I'm doing some test builds of klibc
<https://git.kernel.org/pub/scm/libs/klibc/klibc.git> and found a
regression for arm64.  What changed is binutils, and I've reported
bug #1016717 there, but it seems to be triggering an existing bug in
the kernel.

Loading some of klibc's test programs (getoptlong.shared,
malloctest2.shared, setjmptest.shared, sigint.shared) fails, with
execve() returning EFAULT.  This happens past the point of no return,
so the kernel kills the process with SIGSEGV.

The reason for this seems to be that:

1. All of these programs have a BSS section but not a data section.
2. The BSS section is not page-aligned (it now starts at 0xffe8).
3. binfmt_elf assumes that a non-page-aligned BSS section is placed
   immediately after a writable data section in memory, and tries to
   clear memory from the start of the BSS section up to the page
   boundary.
4. In this case, there is no data section and no file mapping before
   the BSS, so this results in an EFAULT.  This happens past the point
   of no return, so the kernel kills the process.

With older versions of binutils, the BSS section was still misaligned
on arm64 but started within the same 4K page as another section.

binfmt_elf should check whether it created a mapping before a non-
aligned BSS section; if not then it should round down the start of the
zero mapping instead of trying to clear part of a mapping that's not
there.

Ben.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--- End Message ---
--- Begin Message --- 
Version: 6.1.140-1

On Thu, 1 May 2025 17:12:16 +0200 Salvatore Bonaccorso <carnil@debian.org> wrote:
[...]
> Is this still an issue?

Simply by waiting 2 months to answer, I am able to reply in the
negative.

This appears to have been fixed by:

commit 585a018627b4d7ed37387211f667916840b5c5ea
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Sep 28 20:24:29 2023 -0700
 
    binfmt_elf: Support segments with 0 filesz and misaligned starts

which went into 6.7 and was backported to 6.1.140.

To check this, I:

- Reverted the workaround in klibc
- Built the test programs on arm64
- Ran the affected test programs on amdahl (which is running 6.1.140-1)

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed
                                                    - Carolyn Scheppner

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: