You are running headless from cron to refresh the GhostLock patch tracker. The wrapper has already fetched origin and checked out the auto-update branch with origin/main merged forward, and has also refreshed the local kernel clones under ~/src/linux/{stable,vulns} and the nixpkgs clone at ~/src/nixos/nixpkgs — inspect them via the `origin/...` remote-tracking refs without re-fetching. GhostLock (CVE-2026-43499) is a stack use-after-free in the Linux kernel's real-time mutex (rtmutex) priority-inheritance code, reached through the futex requeue-PI path. remove_waiter() in kernel/locking/rtmutex.c clears pi_blocked_on on `current` instead of on the waiter's own task; when the requeue-PI rollback runs it on behalf of a DIFFERENT task (a PI deadlock cycle across three futexes returns -EDEADLK and takes the buggy rollback path), it leaves a dangling pointer into freed kernel-stack memory — a use-after-free the PoC turns into a near-arbitrary write, local root, and container escape. The trigger is ordinary futex(2), so any unprivileged local task (including one inside an unprivileged container) can reach it; there is no privilege, device, capability, or user-namespace gate, and it is architecture-independent. The canonical fix is 3bfdc63936dd (rtmutex: Use waiter::task instead of current in remove_waiter()), first released in v7.1. The bug was introduced by 8161239a8bcc in v2.6.39 (2011), so essentially every kernel from 2.6.39 through 7.0 is in-window. References: - Disclosure (Nebula Security, IonStack part II): https://nebusec.ai/research/ionstack-part-2/ - Public PoC (NebuSec/CyberMeowfia): https://github.com/NebuSec/CyberMeowfia - Kernel fix: https://github.com/torvalds/linux/commit/3bfdc63936dd4773109b7b8c280c0f3b5ae7d349 Per-branch fixed versions and per-distro status all live in site/content/_index.md (the canonical tracker). Read it first rather than relying on anything cached here. Working-tree hygiene: stream a fetch through a pipe — `curl -fsSL | grep …` — when one pass over the data is enough. If you genuinely need a scratch file, save it in the worktree under a `.scratch-` prefix (e.g. `.scratch-advisories.json`), work on it there, and `rm` it before you commit — never `git add` a scratch file. Don't use /tmp: Bash file reads are confined to the worktree, so a file there can be written but not read back. The wrapper's `git clean -fd` sweeps forgotten scratch on the next run, but the only thing you should leave behind is the edited tracker (and its commit). 1. Read CLAUDE.md to learn the project conventions (especially the single-axis kernel verdict — there is NO reachability or exposure discriminator to record — the status-emoji meanings, the "Fixed since" rule, and the date handling), then read site/content/_index.md. 2. Re-verify each entry currently marked vulnerable (:x:), staged (:warning:), or unverified (:grey_question:). Note on kernel.org: cgit HTML pages (any URL ending in /log/, /tree/, /commit/, etc.) and lore.kernel.org (mailing-list search) are Anubis-gated and WebFetch hits the no-JS challenge. Use the persistent local kernel clones — already refreshed by the wrapper, inspect via the `origin/...` remote-tracking refs: ~/src/linux/stable — stable/linux.git ~/src/linux/vulns — CNA CVE database (watch for CVE-2026-43499) GhostLock is a generic locking fix that lands directly in the stable tree, so there is NO dedicated subsystem clone — stable + vulns suffice. (Setup is documented in CLAUDE.md; if a clone is missing, fail loudly rather than guessing.) Plain-text kernel.org endpoints (e.g. /finger_banner) are still WebFetch-able. a. Upstream stable kernels: GET https://www.kernel.org/finger_banner for the current point release per stable tree. Every maintained branch carries the backport (first fixed at 6.1.175 / 6.6.140 / 6.12.86 / 6.18.27 / 7.0.4 / v7.1, and since 2026-07-24 also 5.15.212 / 5.10.261, per the vulns.git .dyad). The backport is a cherry-pick with a NEW sha that cites the upstream commit, so search by upstream reference/subject, not `git tag --contains`: git -C ~/src/linux/stable log v..origin/linux-.y \ --grep=3bfdc63936dd --grep='waiter::task' --format='%h %s' Empty output means the series is still unpatched. Keep the range bounded to v.. so an ancient unrelated commit can't read as a false "fixed". The upstream rows are the "Linux kernel" distribution at the top of the combined *Patch status* table: refresh their *Current kernel* cells each run. *First fixed* / *Fixed since* / *Status* are sticky (from the .dyad) and with every branch now fixed they should never change. b. CVE record — CVE-2026-43499 is assigned but had NO vulns.git record at seed (2026-07-09). Check whether it has appeared (inspect via origin/master; the wrapper only fetches, so HEAD is stale): git -C ~/src/linux/vulns show \ origin/master:cve/published/2026/CVE-2026-43499.dyad Once it exists, reconcile the "Linux kernel" rows of the *Patch status* table against the authoritative per-branch introduced:fixed pairs in the .dyad, and watch NVD / the disclosure for a KEV/EPSS/CVSS score to add to the Summary if one appears. 3. Distro rows — the *Current kernel* column is LIVE: refresh it for every row on every run and record any movement (a version-only bump is a real content change — commit it and bump lastmod). The verdict columns are STICKY: *Status*, *First fixed*, and *Fixed since* change only when a row actually adopts the fix. A row can only become fixed once the fix is available to adopt — its kernel series is fixed upstream (the "Linux kernel" rows), OR the distro cherry-picks 3bfdc63936dd independently. Because the bug dates to v2.6.39, EVERY tracked kernel is in-window — there are no "not affected" rows. Rows exist per kernel stream, not just per release: Debian suites' default kernel plus bullseye's opt-in linux-6.1; PVE default, opt-in, and old (superseded) proxmox-kernel series; Rocky's standard kernel; every AL2023 stream (AL2 is EOL — prose-only, no rows, no repodata polls). A PVE "old" row is a superseded series Proxmox no longer updates: refresh its Current kernel from the same Packages.gz pull, but expect no movement and no verdict flip — only re-read its changelog branch if the package version actually moved. When proxmox-default-kernel switches series, relabel per CLAUDE.md (new default; superseded series becomes "old"; old rows sort after live opt-ins, descending). EL kernel-rt is NOT a row — it is a prose-only caveat in the "### Rocky Linux / RHEL family" section, keyed on the RHEL kernel-rt fix_state in the Red Hat security data API. For each row, re-pull the KERNEL version and check for the backport: - Debian: the SECURITY TRACKER is authoritative for status, not a madison version compare — the base suite lags the -security upload, and Debian backports below the upstream first-fixed release (e.g. bookworm-security 6.1.176-1 is fixed though upstream 6.1 was not fixed until 6.1.177). WebFetch the per-CVE page or curl the JSON: curl -fsS 'https://security-tracker.debian.org/tracker/data/json' read each release's status + the version under `repositories` (a -security entry = shipped as a security update). Use madison only for the base-suite version and the sid/testing lineage: curl -fsS 'https://api.ftp-master.debian.org/madison?package=linux&s=sid,forky,trixie,bookworm,bullseye&text=on' - Proxmox: read *Current kernel* ONLY from the pve-no-subscription Packages.gz (needs zcat) — the published `proxmox-kernel-` build. The pve-kernel git changelog LEADS apt, so use it only to confirm a cherry-pick, never as the version; mixing the two is what flips the version forth-and-back between runs. A cherry-pick in git that pve-no-subscription has not yet published is `:warning: Staged`, not Fixed. - NixOS: the channel kernel pin from the local nixpkgs clone. - Rocky / RHEL: these are backport-versioned (base version doesn't map to an upstream point release), so the signal is an erratum, not the number. The AUTHORITATIVE LEADING signal is the Red Hat security data API (RHEL is upstream of Rocky/Alma) — WebFetch https://access.redhat.com/security/cve/CVE-2026-43499 or curl https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-43499.json and read the kernel `fix_state` + `affected_release`. While fix_state is "Affected" with no affected_release/RHSA, EL is unfixed (Rocky rows :x:). When an RHSA + fixed kernel NVR appears, Rocky rebuilds it as an RLSA; confirm via Rocky BaseOS repodata (zcat) reaching that NVR, and cross-check AlmaLinux via OSV https://api.osv.dev/v1/vulns/CVE-2026-43499. - Amazon: the ALAS signal is the repodata updateinfo.xml.gz (maps CVE -> ALAS -> fixed kernel NVR), NOT the per-CVE ALAS HTML page (JS-rendered, returns nothing headlessly -> false "no advisory"). Resolve the mirror.list, fetch repodata/updateinfo.xml.gz (zcat) and grep the CVE; check all kernel streams (AL2023: kernel 6.1, opt-in kernel6.12, kernel6.18 — a narrow-window bug may leave the default not-affected but an opt-in stream affected/fixed). Read current versions from primary.xml.gz. Exact recipes are in CLAUDE.md. A row flips to ":white_check_mark: Fixed" when its kernel carries the backport (reaches a fixed series release, or a distro advisory ships the cherry-pick). On a flip, set *First fixed* to the first fixed package build and set "Fixed since" per the CLAUDE.md rule. A kernel bump that stays IN-WINDOW WITHOUT the backport is NOT adoption — update *Current kernel* and nothing else. zcat / gunzip ARE available to the headless run — use them for the Packages.gz / repodata pulls. Pull only kernel versions and advisory state — the tracker records no other per-distro facts. GhostLock has NO reachability or exposure discriminator: the trigger is plain futex(2), reachable by any unprivileged local task, so an affected unpatched row is :x:, never a mitigated :warning:. A :warning: is only for a staged-but-unreleased fix. There is no mitigation that reduces exposure short of the kernel patch — do not record sysctl/module knobs as mitigations. Do NOT record NixOS channel git-revisions (the channels.nixos.org//git-revision pins) anywhere in the tracker. They advance on nearly every run; recording them manufactures a diff on an otherwise no-op run. 4. Edit site/content/_index.md to reflect any changes per the conventions in CLAUDE.md (status badges, kernel versions, the "Fixed since" sticky date, and the `## Verification log` update rules). If you make content changes, bump the `lastmod` date in the front-matter. If nothing changed, leave the file alone — don't bump `lastmod` on a no-op run. Never write "no change" / "unchanged from prior run" / "no verdict changes this run" prose into the tracker — silence is how the tracker says "unchanged". Even on a run that does change something real, touch only the lines whose facts changed. 5. If you made changes, commit them on the current branch (which is `auto-update` — the wrapper has already switched to it and merged origin/main forward). Do NOT create a new branch, do NOT switch branches, do NOT push, and do NOT open a PR. The user merges auto-update into main manually. If nothing changed, exit without committing. If you hit unexpected errors or substantive changes you can't confidently encode, commit your best attempt and note open questions in the commit message.