[Bug 2112272] Re: Apport refuses to generate core dumps inside containers

Launchpad Bug Tracker 2112272 at bugs.launchpad.net
Fri Jun 6 22:08:47 UTC 2025


This bug was fixed in the package apport - 2.33.0-0ubuntu1

---------------
apport (2.33.0-0ubuntu1) questing; urgency=medium

  * New upstream release
    - SECURITY UPDATE: Report file insecure permissions (LP: #2106338)
      + Do not change report group to report owner's primary group.
      + CVE-2025-5467
    - SECURITY UPDATE: Race condition when forwarding core files to containers
      (LP: #2107472)
      + apport: move consistency_checks call further up
      + apport: do not override options.pid
      + apport: open /proc/<pid> as early as possible
      + fileutils: respect proc_pid_fd in get_core_path
      + apport: use opened /proc/<pid> everywhere
      + apport: do consistency check before forwarding crashes
      + apport: require --dump-mode to be specified
      + apport: determine report owner by dump_mode
      + apport: do not forward crash for dump_mode == 2
      + apport: support pidfd (%F) parameter from kernel
      + CVE-2025-5054
    - test: support coreutils rename to gnu-coreutils (LP: #2111595)
    - setuptools/java: use snakecase for option name (LP: #2111595)
    - apport: look for the exe within the proc root mount (LP: #2112272)
  * Depend on gnu-coreutils for integration/system tests
  * Depend on python3-pytest-cov in addition to python3-pytest
  * Drop patches applied upstream and refresh remaining patches
  * Address some Pyright complaints in ubuntu general hook

 -- Benjamin Drung <bdrung at ubuntu.com>  Fri, 06 Jun 2025 13:53:15 +0200

** Changed in: apport (Ubuntu)
       Status: In Progress => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2025-5054

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2025-5467

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/2112272

Title:
  Apport refuses to generate core dumps inside containers

Status in Apport:
  Fix Released
Status in apport package in Ubuntu:
  Fix Released

Bug description:
  lsb_release -rd
  Description:	Ubuntu 22.04.5 LTS
  Release:	22.04

  
  apport:
    Installed: 2.20.11-0ubuntu82
    Candidate: 2.20.11-0ubuntu82.7
    Version table:
       2.20.11-0ubuntu82.7 500
          500 http://us-west-1.ec2.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
          500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
   *** 2.20.11-0ubuntu82 500
          500 http://us-west-1.ec2.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
          100 /var/lib/dpkg/status


  
  What happened: 

  Version 2.20.11-0ubuntu82.7 introduced a new function called
  consistency_checks that now refuses to generate core dumps and logging
  the message "executable was modified after program start, ignoring."

  However, this check fails in container environments because the binary
  resides inside container-specific directories, not directly on the
  host OS.

  "if not os.path.exists(os.readlink('exe', dir_fd=proc_pid_fd))"

  As a result, core dumps from containers are being discarded. Prior to
  this update, core dumps were generated correctly.

  
  What you expected to happen:

  When a process inside the container crashes, the apport running on the
  host OS should forward the core dump via a UNIX socket instead of
  exiting because the binary is not present on the host OS.

  
  Changes: 

  https://launchpadlibrarian.net/796123959/apport_2.20.11-0ubuntu82.6_2.20.11-0ubuntu82.7.diff.gz

  +process_start = get_process_starttime()
  +if not consistency_checks(options, process_start):
  +    sys.exit(0)
  +
   # Check if we received a valid global PID (kernel >= 3.12). If we do,
   # then compare it with the local PID. If they don't match, it's an
   # indication that the crash originated from another PID namespace.
  @@ -540,21 +617,24 @@
   if options.global_pid is not None:


  consistency_checks should be after checking if the crash originated
  from another PID namespace.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/2112272/+subscriptions




More information about the foundations-bugs mailing list