Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Security Advisories

Security advisories are a first-class deliverable in InterGenOS, not an afterthought. When a vulnerability affects the kernel or packages we ship, we document it in full: what it is, whether InterGenOS was exposed, exactly how it is mitigated, and how you can verify the mitigation on your own machine. This reflects the project’s posture directly.

This page summarizes the published advisories and the format they follow. The canonical advisory documents live in the source tree under docs/security/advisories/.

How to read an advisory

Advisories come in two shapes, and both share the same goal: give you enough detail to understand, audit, and if you choose, change the mitigation yourself. A machine you understand, can modify, and can trust is the whole point.

A typical advisory contains:

  • Identification. A CVE number and/or an InterGenOS advisory ID (for example IGOS-SA-2026-002), the disclosure date, and a CVSS score with its vector string where one is published.
  • Summary. A plain-language description of the vulnerability and its root cause.
  • InterGenOS status. Whether builds were exposed, and the explicit verdict (for example NOT AFFECTED, or fully vulnerable pre-fix). Advisories state honestly when a built kernel image was vulnerable as compiled, even if no public installation was ever affected.
  • Mitigation. The concrete fixes applied, named down to the patch file and the script that installs them. InterGenOS favors layered defense: an upstream or backported kernel patch as the primary fix, plus a defense-in-depth measure such as a module blacklist.
  • User impact and opt-out. What changes for you, what does not, and how to reverse a default if your workflow needs it. Mitigations that change defaults are always plainly visible and user-editable.
  • Verification. Copy-pasteable commands so you can confirm the mitigation is present on your own system rather than taking our word for it.
  • Timeline, composition, and sources. Disclosure-to-fix dates, how the advisory relates to other security work, and links to upstream commits and third-party write-ups.

A core principle runs through every advisory: defaults that change behavior for security reasons remain transparent and reversible. If a mitigation blacklists a kernel module, the configuration file is visible on disk, documented, and removable by an administrator who genuinely needs the affected functionality.

Published advisories

CVE-2026-31431 — Copy Fail (algif_aead local privilege escalation)

A logic flaw in the Linux kernel algif_aead subsystem allowed an unprivileged local user to escalate to root. The flaw was introduced upstream in 2017 and affected mainstream Linux distributions shipped since then.

InterGenOS status: NOT AFFECTED. Mitigated on the day of public disclosure (2026-04-29) with two independent layers:

  • Kernel patch. The upstream fix is applied as a patch in packages/core/linux-kernel/patches/, reverting the vulnerable in-place optimization across the af_alg and algif_* crypto sources.
  • Module blacklist (defense-in-depth). The algif_aead module is additionally blacklisted via /etc/modprobe.d/disable-algif.conf, guarding against an unpatched fallback boot, a future regression in the same subsystem, or unintended module loading.

User impact is zero. dm-crypt/LUKS, kTLS, IPsec, OpenSSL/GnuTLS/NSS, SSH, and kernel keyring crypto all use the in-kernel crypto API directly and do not route through AF_ALG. The only affected workloads are userspace applications explicitly configured to use AF_ALG AEAD sockets, which is rare outside embedded crypto-offload scenarios.

To verify the mitigation on your own install, the advisory provides commands to inspect the blacklist file, confirm the module is not loaded, and check the running kernel version. See the full advisory at docs/security/advisories/CVE-2026-31431-copy-fail.md.

IGOS-SA-2026-002 — Dirty Frag + Fragnesia (kernel socket-buffer cluster)

A cluster of three upstream Linux kernel CVEs disclosed in May 2026 (CVE-2026-43284, CVE-2026-43500, and CVE-2026-46300), all local privilege escalation to root. They share a root cause: socket-buffer code paths that fail to set or propagate the marker indicating that paged fragments are externally owned, which can lead to in-place decryption writing into page-cache pages an unprivileged process can observe.

InterGenOS status: the kernel shipped with this release line was vulnerable as built before the mitigation commit. Because no public ISO had been shipped during the exposure window, no public installations were affected. The advisory documents the cluster and the fix in full regardless.

Mitigation again uses two layers:

  • In-tree kernel patches. Three patches in packages/core/linux-kernel/patches/ address the cluster. Two apply the upstream mainline commits cleanly; the third (CVE-2026-43500, rxrpc) is an InterGenOS-authored backport, because the upstream patch targets a refactored file layout that does not exist in this release’s pinned kernel. The structurally equivalent fix is applied at the corresponding site in the pinned source, and the patch file header documents the provenance and full reasoning. The release line keeps its pinned kernel version and backports fixes rather than bumping the kernel.
  • Defense-in-depth module blacklist. A configuration file under /etc/modprobe.d/ refuses to load the esp4, esp6, and rxrpc modules. This is the explicit lesson of the cluster: a later CVE in the same fragile area proved that patches alone may not cover every related path, so the blacklist holds the line if a similar bug drops before a fresh kernel ships.

User impact is minimal for typical desktop use. Modern consumer VPNs such as WireGuard and OpenVPN do not use the esp4/esp6 modules, and rxrpc is OpenAFS-only. The blacklist file is plainly visible and editable: users who depend on traditional IPsec ESP or OpenAFS can remove the file (or unblock a single module) and reload the module dependency cache, as documented in the advisory’s opt-out section. The kernel patches remain in effect even with the blacklist removed; opting out loses only the defense-in-depth layer.

These mitigations take effect on a kernel rebuild, since the kernel image and the signed boot image both change. See the full advisory at docs/security/advisories/dirty-frag-fragnesia.md.

Where mitigations land in the build

Kernel-level fixes are delivered as patches under packages/core/linux-kernel/patches/ and applied automatically during the kernel build phase; the build applies every patch in the directory in alphabetical order at configure time. Defense-in-depth configuration files (such as module blacklists) are installed during the system’s chroot configuration step. Because a kernel-image change also changes the signed Unified Kernel Image, kernel-level advisories require a kernel rebuild and a new UKI to take full effect. For background on the signed boot chain and integrity model, see Verified Boot & Secure Boot and the Kernel Hardening page.

Reporting a vulnerability

Security reports for InterGenOS go to security@intergenstudios.com.