Data quality issue with CVE-2021-27219 (ALPINE-CVE-2021-27219: inverted range on every Alpine branch)

Abierto
#6,278 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, json
Área
data, security

Línea de trabajo

Start with findIntroducedVersion in vulnfeeds/cmd/converters/alpine/main.go, which pairs the 2.67.0 CPE start with Alpine's 2.66.6-r0 fix without checking order. Read the linked #5634 and #5980 before changing anything, since the fix is already proposed there. Done means the converter emits introduced "0" when the start sorts after the fix, and the query for glib 2.88.1-r1 in Alpine:v3.24 returns {}.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

The CVE ID

https://osv.dev/vulnerability/ALPINE-CVE-2021-27219 (API: https://api.osv.dev/v1/vulns/ALPINE-CVE-2021-27219; source: https://storage.googleapis.com/cve-osv-conversion/alpine/ALPINE-CVE-2021-27219.json; modified 2026-10-23T17:17:56.165052798Z)

Describe the data quality issue observed

Every Alpine entry, from Alpine:v3.13 to Alpine:v3.24, carries the same inverted range. The Alpine:v3.24 entry is:

{"package": {"ecosystem": "Alpine:v3.24", "name": "glib", "purl": "pkg:apk/alpine/glib?arch=source"},
 "ranges": [{"type": "ECOSYSTEM", "events": [{"introduced": "2.67.0"}, {"fixed": "2.66.6-r0"}]}]}

introduced (2.67.0) sorts above fixed (2.66.6-r0). So every glib from 2.67.0 upward is reported as affected and never fixed. That includes glib 2.88.1-r1, the current Alpine v3.24 build, and 2.90.0-r0, the current edge build. Versions that really are vulnerable, such as 2.66.5-r0, are reported as not affected.

Alpine's secdb has the fix in 2.66.6-r0 (https://secdb.alpinelinux.org/v3.24/main.json; edge is identical):

{"pkg": {"name": "glib", "secfixes": {"2.60.4-r0": ["CVE-2019-12450"], "2.62.5-r0": ["CVE-2020-6750"], "2.66.6-r0": ["CVE-2021-27219 GHSL-2021-045"], "2.80.1-r0": ["CVE-2024-34397"]}}}

NVD lists two separate vulnerable glib branches, "before 2.66.6" and "2.67.x before 2.67.3":

  • cpe:2.3:a:gnome:glib:* with versionEndExcluding: 2.66.6
  • cpe:2.3:a:gnome:glib:* with versionStartIncluding: 2.67.0, versionEndExcluding: 2.67.3

Minimal reproduction

curl -sS https://api.osv.dev/v1/query -H 'Content-Type: application/json' \
  --data '{"package":{"name":"glib","ecosystem":"Alpine:v3.24"},"version":"2.88.1-r1"}'

Observed on 2026-11-01: the response's vulns holds one record, ALPINE-CVE-2021-27219 (modified 2026-10-23T17:17:56.165052798Z).

The same query, with the version changed:

version ALPINE-CVE-2021-27219 returned correct answer
2.66.5-r0 no yes (before the fix)
2.66.6-r0 no no
2.67.3-r0 yes no
2.88.1-r1 yes no
2.90.0-r0 yes no

Expected result: glib 2.88.1-r1 in Alpine:v3.24 does not match ALPINE-CVE-2021-27219. The response for that query is {}.

Actual result: it matches, because the range is unsatisfiable as written and is read as "affected from 2.67.0, never fixed".

Suggested changes to record

For every Alpine branch:

"ranges": [{"type": "ECOSYSTEM", "events": [{"introduced": "0"}, {"fixed": "2.66.6-r0"}]}]

Additional context

This is the converter defect described in #5634. findIntroducedVersion in vulnfeeds/cmd/converters/alpine/main.go returns the first NVD CPE match that has a VersionStartIncluding. It skips the "before 2.66.6" range, which has no start, so it takes 2.67.0 from the 2.67.x branch. It then pairs that with Alpine's fix on the 2.66.x branch, without checking that the introduced version sorts below the fixed one. The logic came in with #5586 (2026-07-05). The fix proposed in #5980 would also correct this record: use an introduced version only when it sorts before Alpine's fixed version, and otherwise fall back to "0".

Lenguaje dominante
Go
Estrellas
3k
Forks
390
Merge medio
1 d 1 h
PR fusionados (30 d)
128

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de google/osv.dev

Todos los issues de google/osv.dev

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.