Preface: When looking at the systemd Git repository from system250 to system251, there were 79,853 lines of new code and 34,624 lines deleted over the past year.

Background: You are able to use backtrace to track function call stack and locate segment fault under Linux. The (systemd-coredump) collects and displays core core dumps for analyzing application crashes.
By default, systemd-coredump will log the core dump to the journal, furthermore including a backtrace(/usr/lib/systemd/systemd-coredump –backtrace), and store the core dump (an image of the memory contents of the process) itself in an external file in /var/lib/systemd/coredump.
These core dumps are deleted after a few days by default; see /usr/lib/tmpfiles[.]d/systemd.conf for details.

Vulnerability details: systemd 250 and 251 allows local users to achieve a systemd-coredump deadlock by triggering a crash that has a long backtrace. This occurs in parse_elf_object in shared/elf-util[.]c. The exploitation methodology is to crash a binary calling the same function recursively, and put it in a deeply nested directory to make its backtrace large enough to cause the deadlock. This must be done 16 times when MaxConnections=16 is set for the systemd/units/systemd-coredump.socket file.

Remedy: LF is short for Executable and Linkable Format. It’s a format used for storing binaries, libraries, and core dumps on disks in Linux and Unix-based systems. The target remedy file is locate in systemd/src/shared/elf-util[.]c . The elf-util[.]c consists of Iterate over all program headers in that ELF object. These will have been copied by the kernel verbatim when the core file is generated. So this is the reason to modify this file with 31 additions and 6 deletions.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2022-45873

Ref: Technical details are known, but there is no available exploit.