The systemd component that collects and stores core dumps — systemd‑coredump — was found in January 2023 to
ignore the kernel’s fs.suid_dumpable setting, allowing core files for setuid/setgid (privileged) processes to be produced and, under some configurations, read by non‑privileged users. That defect is tracked as CVE‑2022‑4415 and has been assigned a
medium severity rating (CVSS v3.1 5.5). Microsoft’s public advisory for this CVE names
Azure Linux as a product that “includes this open‑source library and is therefore potentially affected,” but that statement is a product‑scoped attestation — not an exclusivity guarantee that other Microsoft artifacts cannot contain the vulnerable component.
Background / Overview
systemd ships a userspace helper called
systemd‑coredump that receives core dumps from the kernel and stores or forwards them according to the system's configuration. The Linux kernel exposes the sysctl setting
/proc/sys/fs/suid_dumpable, which governs whether core dumps for setuid/setgid programs are permitted and, when allowed, who may read them. The secure default on many distributions prevents core dumps from privileged programs to avoid leaking secrets (passwords, private keys, tokens) that privileged processes may hold in memory.
CVE‑2022‑4415 was introduced when systemd‑coredump
did not respect the kernel’s fs.suid_dumpable decision. In certain builds and configurations systemd‑coredump continued to store and (depending on ACLs/permissions) made core files accessible in ways that circumvented the intended kernel control. The consequence: a local, low‑privilege account on a multi‑user host could obtain core data from a privileged process and extract secrets. Multiple maintainer and distribution trackers documented the flaw and issued fixes and rollups.
Key technical facts (verified)
- The flaw specifically involves systemd‑coredump and its handling of the fs.suid_dumpable kernel setting.
- Exploitation requires local access; this is a confidentiality (information‑leak) issue, not a remote code execution bug. The common CVSS vector reflects a local attack with high confidentiality impact but no integrity or availability impact.
- Distributions and vendors have released patched systemd packages; downstream advisories list fixed package versions for Ubuntu, Debian, Amazon Linux and others. Administrators should apply vendor updates as the primary remediation.
Why Microsoft named Azure Linux — and what that wording actually means
Microsoft’s MSRC advisory for this class of Linux‑component CVEs (including the specific FAQ wording for many Linux CVEs) states:
- “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability.”
- Microsoft also notes it has begun publishing machine‑readable CSAF/VEX attestations (beginning October 2025) and will update CVE mappings if additional Microsoft products are found to ship the affected component. (archive.vn)
That language is precise: it is an
inventory attestation for Azure Linux — a statement that Microsoft has scanned and confirmed Azure Linux images contain the implicated upstream component. It is
not a categorical statement that no other Microsoft product could ever contain the same software. In plain terms:
- If you run Azure Linux images, treat Microsoft’s attestation as an authoritaiate attention (patching/upgrading) is required for those images.
- If you run other Microsoft artifacts (appliances, containers, WSL distributions, IoT images, platform images, or custom Azure marketplace images), do not assume they are unaffected simply because they were not named; absence of an attestation is not proof of absence. Treat other Microsoft images as “not yet verified” until Microsoft’s VEX/CSAF dataset or your own SBOM/image inspection proves otherwise.
The practical takeaway:
Azure Linux is the only Microsoft product Microsoft has publicly attested to include the affected component for many Linux CVEs, but that attestation narrows the immediate scope, it does not exclude accidental or deliberate inclusion of the same upstream code in other Microsoft artifacts.
Cross‑checked evidence and timeline
Multiple independent trackers and vendor advisories confirm the vulnerability, the attack vector, and the available mitigations:
- The official CVE trackers (NVD / Mitre) record the vulnerability description and link to downstream advisories.
- Distribution advisories (Ubuntu, Debian, Amazon Linux, Red Hat security pages, vendor security trackers) list patched package versions and mitigation recommendations; Ubuntu’s security page lists fixed package revisions for affected releases.
- Vendor advisories (for example Amazon Linux ALAS) capture the CVSSv3 score of 5.5 and note the platform‑specific updates that shipped in March 2023 for Amazon Linux 2023.
These independent confirmations allow us to be confident about the technical nature of the bug and the correct operational mitigations: update systemd to a patched package, or apply kernel/sysctl mitigations temporarily.
Impact analysis — what operators should worry about
This vulnerability is a local information‑leak risk that is most meaningful in these scenarios:
- Multi‑user hosting (shared servers, university labs, multi‑tenant VMs): local users can abuse a crash to obtain a core and read privileged memory.
- Containers and multi‑tenant platforms where a privileged container process might crash and a container‑adjacent user could see resulting core files.
- Systems that process secrets in privileged helpers — for example, daemons handling keys or credentials with elevated privilege — are particularly sensitive.
What an attacker can extract depends on whether the crashed process held secrets in memory and whether the system’s file‑ACLs or global permissions permit reading the stored core. Because systemd‑coredump historically attempted to be helpful by saving core files with ACLs or ownership that enabled the real user to read them, the worst case produces high confidentiality exposure. See the distribution advisories and threat analyses for reproduction examples and exploit scripts used in responsible disclosure tests.
Is Azure Linux the only Microsoft product affected?
Short, evidence‑based answer:
No — Azure Linux is not necessarily the only Microsoft product that could include the vulnerable systemd component. Ming names Azure Linux because the company has scanned and attested that specific product family; it explicitly promises to expand VEX/CSAF attestations if additional Microsoft products are discovered to ship the same component.
Why that distinction matters:
- Microsoft ships and maintains multiple Linux‑based artifacts and images (Azure VM images, container/Marketplace images, device or appliance images, WSL distri images). Any of these artifacts that include a systemd package built from the vulnerable upstream versions could carry the flaw until updated. The MSRC attestation is product‑scoped and time‑boxed — it is a snapshot of what Microsoft has verified so far.
- In practice, many Microsoft customers and third parties should treat the Azure Linux attestation as the immediate signal for Azure Linux images, then proactively verify other Microsoft artifacts they consume. This typically means checking the SBOM or installed package versions in each image, scanning images for vulnerable systemd versions, or asking Microsoft for explicit VEX/CSAF attestations for specific SKUs.
How to check if your systems are vulnerable (practical steps)
Administrators and security engineers can follow concrete steps to detect and mitigate exposure in their environment.
- Inventory images and hosts
- Check every Linux image you run (VMs, containers, WSL, marketplace images) and record the installed systemd version.
- Example command to check systemd version on a host:
- systemctl --version
- dpkg -l systemd # Debian/Ubuntu
- rpm -q systemd # RHEL/CentOS/Fedora
- Check the kernel sysctl value:
- cat /proc/sys/fs/suid_dumpable
- Values: 0 (no setuid core dumps), 1 (core dumps allowed, but restricted), 2 (core dumps allowed and accessible) — distributions vary in defaults.
- Look for existing core dumps:
- ls -l /var/lib/systemd/coredump or journalctl --directory /var/lib/systemd/coredump
- If core dumps exist for privileged binaries, evaluate their permissions and determine whether non‑privileged accounts could read them.
- Test for the specific behavior (lab only; do not run on production systems):
- Build a small setuid test binary that writes a deterministic secret to memory, crash it, then examine any generated core in /var/lib/systemd/coredump to see if the secret is present and readable.
- Scan images and registries:
- Use image scanning tools (commercial or open source) to detect vulnerable systemd versions in container registries and VM images.
These steps let you answer two operational questions: (a) which artifacts include vulnerable systemd builds, and (b) whether stored core dumps are readable by unintended accounts.
Immediate mitigations and long‑term remediation
Primary remediation is to apply vendor patches for systemd. Secondary mitigations are available while patches are being validated and deployed.
- Patch first, mitigate second:
- Install the patched systemd package from your distribution vendor (Ubuntu, Debian, Amazon Linux, etc.). The Ubuntu security tracker lists fixed package revisions per release; vendor advisories show published updates.
- Temporary mitigations (until you patch):
- Set fs.suid_dumpable to 0 to disable core dumps for setuid/setgid processes at the kernel level:
- echo 0 | sudo tee /proc/sys/fs/suid_dumpable
- Restrict or monitor /var/lib/systemd/coredump permissions and ownership; consider disabling systemd‑coredump if you do not require it for debugging.
- Use filesystem ACLs and monitoring to ensure core dumps are not world‑readable.
- For cloud images and containers, rebuild/replace images with patched packages; do not rely solely on live host changes where images are immutable artifacts.
- Validate remediation:
- After patching, re‑run your detection steps: confirm the systemd version is the fixed one, verify fs.suid_dumpable behavior, and ensure any previously generated core files that could contain secrets are rotated securely (deleted or archived under root control).
Vendor advisories and security trackers explicitly recommend patching as the primary fix and note fs.suid_dumpable=0 as a practical mitigation where immediate patching is not possible.
For Microsoft customers: what to do next
If you operate in a Microsoft ecosystem, follow a prioritized list:
- Azure Linux images (customer‑managed VMs)
- Apply Microsoft’s security updates for Azure Linux images as published in the MSRC update guide and Azure image update channels. Microsoft’s attestation makes Azure Linux an immediate priority.
- Other Microsoft artifacts (WSL, Marketplace VMs, appliances, managed images, IoT/edge)
- Do not assume “not mentioned” == “not affected.” Instead:
- Query Microsoft’s VEX/CSAF dataset (where available) for product‑by‑CVE mappings that expand beyond Azure Linux. Microsoft promised to publish CSAF/VEX attestations starting October 2025 and said it will update CVE records when additional products are identified.
- If you rely on a specific Microsoft image, check that image’s installed package list or SBOM. If the image is not easily inspectable, contact Microsoft support or your account team and request a formal attestation.
- Managed services and PaaS offerings
- If you use managed services that abstract the OS (platform‑provided VM images, fully managed contaior security notices and incident bulletins relevant to those services. Treat tenant isolation and multi‑tenant attack surfaces with caution until you have assurance that images were updated.
- For security teams: update detection and IR playbooks
- Add checks to your asset inventory and image‑scanning pipeline to detect systemd versions in the vulnerable raat include them.
- Add a forensics step to examine pre‑patch core dump artifacts for evidence of secret leakage.
Supply‑chain and attestation: why Azure Linux naming matters beyond the immediate CVE
Microsoft’s use of product‑scoped attestations (VEX/CSAF) is an important supply‑chain transparency measure: it gives customers a deterministic mapping between CVEs and specific Microsoft artifacts. However, the pragmatic limits are clear:
- Attestations are only as comprehensive as the scanning program that produced them; Microsoft has started with Azure Linux as the initial attestable scope and continues to expand coverage. Customers must not treat the present absence of a product from Microsoft’s list as definitive proof that the product is safe.
- Until coverage is complete across Microsoft’s entire image portfolio, customers who require high assurance should perform artifact‑level verification (SBOM checks, image scanning, package inventory) for eac consume. Tools and processes exist to automate this but require integration into CI/CD pipelines and image provisioning flows.
Critical analysis — strengths and risks in Microsoft’s approach
Strengths
- Microsoft’s practice of publishing targeted attestations for Azure Linux and committing to VEX/CSAF is an operational improvement over opaque vendor practices. Named attestations give immediate, actionable signals for customers running those products.
- Centralizing product‑level mapping reduces the time customers spend chasing whether a given distribution image includes a particular upstream library; this accelerates mitigation for hiamilies.
Risks and limitations
- Scope bias: Naming one product as “potentially affected” risks false reassurance for other Microsoft artifacts. Customers may interpret a single attestation incorrectly as a comprehensive inventory statement across all Microsoft products. That reading is mistaken; the attestation is explicit about being product‑scoped and promises updates if more products are identified.
- Time lag: Vendors and distributors frequently ship bespoke or forked images or package snapshots that differ from canonical distributions. These variants can carry old, vulnerable code even after the vendor announces a fix upstream; until Microsoft scans and attests each SKU, some artifacts may remain blind spots.
- Operational overhead: Customers that mix many Microsoft images (marketplace, brought‑your‑own images, managed services) must invest in artifact verification tooling and process changes to close the verification gap — not all customers are staffed or budgeted for that work.
Bottom line: Microsoft’s attestation program is a useful improvement, but it is
complementary to — not a substitute for — per‑artifact verification and standard patch management practices.
Practical checklist for administrators (quick, actionable)
- Immediate (hours)
- Identify all hosts/images running systemd. Run systemctl --version and package manager queries across images.
- Apply vendor/OS updates for systemd where patches are available. Prioritize Azure Linux based on MSRC attestation.
- If you cannot patch immediately, set fs.suid_dumpable to 0 as a temporary mitigation and ensure /var/lib/systemd/coredump is not world‑readable.
- Short term (days)
- Rebuild container/VM images with patched systemd packages and re‑deploy immutable images.
- Scan registries and artifact stores for vulnerable systemd versions and quarantine images until fixed.
- Longer term (weeks)
- Integrate image scanning / SBOM verification into CI/CD to block deployments with vulnerable packages.
- Request explicit VEX/CSAF attestations from Microsoft for critical Microsoft SKUs you run; maintain a mapping of CVE → image → patch status.
- Update incident response playbooks to include checks for leaked secrets and core‑dump artifacts.
Conclusion
CVE‑2022‑4415 is a
local information‑leak issue in systemd‑coredump that can expose privileged in‑memory secrets when core dumps are produced for setuid/setgid processes. Multiple independent trackers and vendor advisories confirm the vulnerability and provide patches; the reliable operational response is to patch systemd packages and, until you can, set fs.suid_dumpable=0 and tighten access to core dump storage.
Microsoft’s MSRC naming of
Azure Linux as a product that “includes this open‑source library and is therefore potentially affected” is accurate for Azure Linux and gives Azure customers the prioritized signal they need, but it should not be read as an exclusive list of Microsoft products that might carry the vulnerable code. Treat Microsoft’s attestation as an authoritative
yes for Azure Linux, and treat other Microsoft artifacts as
unverified until proven safe by VEX/CSAF attestations or artifact inspection. In short: patch, verify your artifacts, and ask your vendors (including Microsoft) for per‑artifact attestations where you need them.
Source: MSRC
Security Update Guide - Microsoft Security Response Center