release v0.9.3: CVE metadata refresh (KEV 10→12) + dirtydecrypt bug fix
build / build (clang / debug) (push) Waiting to run
build / build (clang / default) (push) Waiting to run
build / build (gcc / debug) (push) Waiting to run
build / build (gcc / default) (push) Waiting to run
build / sanitizers (ASan + UBSan) (push) Waiting to run
build / clang-tidy (push) Waiting to run
build / drift-check (CISA KEV + Debian tracker) (push) Waiting to run
build / static-build (push) Waiting to run
release / build (arm64) (push) Waiting to run
release / build (x86_64) (push) Waiting to run
release / build (x86_64-static / musl) (push) Waiting to run
release / build (arm64-static / musl) (push) Waiting to run
release / release (push) Blocked by required conditions

CVE metadata refresh:
- Added 8 entries to core/cve_metadata.c for the v0.8.0 + v0.9.0 module
  CVEs. Two are CISA-KEV-listed:
  - CVE-2018-14634 mutagen_astronomy (2026-01-26, CWE-190)
  - CVE-2025-32463 sudo_chwoot       (2025-09-29, CWE-829)
- Populated via direct curl when refresh-cve-metadata.py's Python urlopen
  hung on CISA's HTTP/2 endpoint for ~55 min — same data, different
  transport.

dirtydecrypt module bug fix:
- dd_detect() was wrongly gating 'predates the bug' on kernel < 7.0
- Per NVD CVE-2026-31635: bug entered at 6.16.1 stable; vulnerable
  through 6.18.22 / 6.19.12 / 7.0-rc7; fixed at 6.18.23 / 6.19.13 / 7.0
- Fix: predates-gate now uses 6.16.1; patched_branches[] adds {6,18,23}
- Re-verified: dirtydecrypt now correctly returns VULNERABLE on mainline
  6.19.7 instead of OK. Previously a false negative on real vulnerable
  kernels.

Footer goes from '10 in CISA KEV' to '12 in CISA KEV'. Verified count
stays at 28 but dirtydecrypt's record is now a TRUE VULNERABLE match
(was OK match).
This commit is contained in:
2026-05-24 01:17:58 -04:00
parent d52fcd5512
commit fa0228df9b
12 changed files with 134 additions and 31 deletions
@@ -667,14 +667,18 @@ static int dd_active_probe(void)
* RESPONSE authenticator length check"), shipped in Linux 7.0.
*
* The detect logic therefore is:
* - kernel < 7.0 → SKELETONKEY_OK (predates the bug)
* - kernel ≥ 7.0 → consult kernel_range; 7.0+ has the fix
* - --active → empirical override (catches pre-fix 7.0-rc kernels
* or weird distro rebuilds the version check missed)
* - kernel < 6.16.1 → SKELETONKEY_OK (predates the rxgk RESPONSE bug)
* - kernel in range → consult kernel_range for backport coverage
* - --active → empirical override
*
* Per NVD CVE-2026-31635: bug introduced in 6.16.1 stable; vulnerable
* range is 6.16.16.18.22 + 6.19.06.19.12 + 7.0-rc1..rc7. Fixed at
* 6.18.23 backport, 6.19.13 backport, 7.0 stable.
*/
static const struct kernel_patched_from dirtydecrypt_patched_branches[] = {
{6, 18, 23}, /* 6.18.x stable backport */
{6, 19, 13}, /* 6.19.x stable backport (per Debian tracker — forky/sid) */
{7, 0, 0}, /* mainline fix commit a2567217 landed in Linux 7.0 */
{7, 0, 0}, /* mainline fix landed before 7.0 stable */
};
static const struct kernel_range dirtydecrypt_range = {
.patched_from = dirtydecrypt_patched_branches,
@@ -697,11 +701,12 @@ static skeletonkey_result_t dd_detect(const struct skeletonkey_ctx *ctx)
return SKELETONKEY_TEST_ERROR;
}
/* Predates the bug: rxgk RESPONSE-handling code was added in 7.0. */
if (!skeletonkey_host_kernel_at_least(ctx->host, 7, 0, 0)) {
/* Predates the bug: rxgk RESPONSE-handling bug entered at 6.16.1
* stable per NVD. Earlier 6.x kernels don't have the buggy code. */
if (!skeletonkey_host_kernel_at_least(ctx->host, 6, 16, 1)) {
if (!ctx->json)
fprintf(stderr, "[i] dirtydecrypt: kernel %s predates the rxgk "
"RESPONSE-handling code added in 7.0 — not applicable\n",
"RESPONSE bug introduced in 6.16.1 — not applicable\n",
v->release);
return SKELETONKEY_OK;
}