CVE-2025-71201

Estado: ModificadaAlta (7.1)—

In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix early read unlock of page with EOF in middle

The read result collection for buffered reads seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the following log snippet:

The 'cto=5fb2' indicates the collected file pos we've collected results to so far - but we still have 0x4e more bytes to go - so we shouldn't have collected folio ix=00005 yet. The 'ZERO' subreq that clears the tail happens after we unlock the folio, allowing the application to see the uncleared tail through mmap.

Leer descripción completaMostrar menos

The problem is that netfs_read_unlock_folios() will unlock a folio in which the amount of read results collected hits EOF position - but the ZERO subreq lies beyond that and so happens after.

Fix this by changing the end check to always be the end of the folio and never the end of the file.

In the future, I should look at clearing to the end of the folio here rather than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can run in parallel with an async READ subreq. Further, the ZERO subreq may still be necessary to, say, handle extents in a ceph file that don't have any backing store and are thus implicitly all zeros.

This can be reproduced by creating a file, the size of which doesn't align to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something like:

The last 0x4e bytes should all be 00, but if the tail hasn't been cleared yet, you may see rubbish there. This can be reproduced with kafs by modifying the kernel to disable the call to netfs_read_subreq_progress() and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD. Reproduction can be made easier by inserting an mdelay(100) in netfs_issue_read() for the ZERO-subreq case.

AFS and CIFS are normally unlikely to show this as they dispatch READ ops asynchronously, which allows the ZERO-subreq to finish first. 9P's READ op is completely synchronous, so the ZERO-subreq will always happen after. It isn't seen all the time, though, because the collection may be done in a worker thread.

Detalles técnicos trazas, registros y código del informe original

    9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0
    ...
    netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0
    ...
    netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2
    netfs_folio: i=157f3 ix=00004-00004 read-done
    netfs_folio: i=157f3 ix=00004-00004 read-unlock
    netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2
    netfs_folio: i=157f3 ix=00005-00005 read-done
    netfs_folio: i=157f3 ix=00005-00005 read-unlock
    ...
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c
    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff
    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8
    ...
    netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0
    netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0

    xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \
           -c "mread -v 0 0x6000" /xfstest.test/x

CVSS

Versión: 3.1
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Puntuación base: 7.1

Probabilidad de explotación (EPSS)

Probabilidad de explotación en los próximos 30 días: 0.12%
Percentil entre todas las CVEs puntuadas: 2
Fecha de la puntuación: 6/10/2026

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

🎯 Técnicas ATT&CK

Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.

ExplotaciónT1068 Exploitation for Privilege Escalationprivilege escalation45 %
Impacto principalT1005 Data from Local Systemcollection60 %

Acceso local (AV:L, PR:L) sin interacción permite escalar privilegios en el kernel; la lectura de datos no inicializados ('rubbish') en memoria sin autorización constituye acceso a información sensible.

Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.

🛡️ Mitigaciones ATT&CK que cubren estas técnicas

Threat Intelligence Program Execution Prevention Application Isolation and Sandboxing Exploit Protection Update Software Data Loss Prevention

Tecnologías afectadas (1)

Linux — Linux Kernel

CWE

CWE-125

Referencias

JSON original (NVD)

Mostrar

{
  "id": "CVE-2025-71201",
  "cveTags": [],
  "metrics": {
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 7.1,
          "attackVector": "LOCAL",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
          "integrityImpact": "NONE",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.2,
        "exploitabilityScore": 1.8
      },
      {
        "type": "Primary",
        "source": "nvd@nist.gov",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 7.1,
          "attackVector": "LOCAL",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
          "integrityImpact": "NONE",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.2,
        "exploitabilityScore": 1.8
      }
    ]
  },
  "affected": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "affectedData": [
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "e2d46f2ec332533816417b60933954173f602121",
              "lessThan": "5b5482c0e5ee740b35a70759d3582477aea8e8e4",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "e2d46f2ec332533816417b60933954173f602121",
              "lessThan": "570ad253a3455a520f03c2136af8714bc780186d",
              "versionType": "git"
            }
          ],
          "programFiles": [
            "fs/netfs/read_collect.c"
          ],
          "defaultStatus": "unaffected"
        },
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.14"
            },
            {
              "status": "unaffected",
              "version": "0",
              "lessThan": "6.14",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "6.18.6",
              "versionType": "semver",
              "lessThanOrEqual": "6.18.*"
            },
            {
              "status": "unaffected",
              "version": "6.19",
              "versionType": "original_commit_for_fix",
              "lessThanOrEqual": "*"
            }
          ],
          "programFiles": [
            "fs/netfs/read_collect.c"
          ],
          "defaultStatus": "affected"
        }
      ]
    }
  ],
  "published": "2026-02-14T16:15:52.647",
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/570ad253a3455a520f03c2136af8714bc780186d",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/5b5482c0e5ee740b35a70759d3582477aea8e8e4",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "type": "Primary",
      "source": "nvd@nist.gov",
      "description": [
        {
          "lang": "en",
          "value": "CWE-125"
        }
      ]
    }
  ],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix early read unlock of page with EOF in middle\n\nThe read result collection for buffered reads seems to run ahead of the\ncompletion of subrequests under some circumstances, as can be seen in the\nfollowing log snippet:\n\n    9p_client_res: client 18446612686390831168 response P9_TREAD tag  0 err 0\n    ...\n    netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0\n    ...\n    netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2\n    netfs_folio: i=157f3 ix=00004-00004 read-done\n    netfs_folio: i=157f3 ix=00004-00004 read-unlock\n    netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2\n    netfs_folio: i=157f3 ix=00005-00005 read-done\n    netfs_folio: i=157f3 ix=00005-00005 read-unlock\n    ...\n    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c\n    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8\n    ...\n    netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0\n    netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0\n\nThe 'cto=5fb2' indicates the collected file pos we've collected results to\nso far - but we still have 0x4e more bytes to go - so we shouldn't have\ncollected folio ix=00005 yet.  The 'ZERO' subreq that clears the tail\nhappens after we unlock the folio, allowing the application to see the\nuncleared tail through mmap.\n\nThe problem is that netfs_read_unlock_folios() will unlock a folio in which\nthe amount of read results collected hits EOF position - but the ZERO\nsubreq lies beyond that and so happens after.\n\nFix this by changing the end check to always be the end of the folio and\nnever the end of the file.\n\nIn the future, I should look at clearing to the end of the folio here rather\nthan adding a ZERO subreq to do this.  On the other hand, the ZERO subreq can\nrun in parallel with an async READ subreq.  Further, the ZERO subreq may still\nbe necessary to, say, handle extents in a ceph file that don't have any\nbacking store and are thus implicitly all zeros.\n\nThis can be reproduced by creating a file, the size of which doesn't align\nto a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something\nlike:\n\n    xfs_io -c \"mmap -r 0 0x6000\" -c \"madvise -d 0 0x6000\" \\\n           -c \"mread -v 0 0x6000\" /xfstest.test/x\n\nThe last 0x4e bytes should all be 00, but if the tail hasn't been cleared\nyet, you may see rubbish there.  This can be reproduced with kafs by\nmodifying the kernel to disable the call to netfs_read_subreq_progress()\nand to stop afs_issue_read() from doing the async call for NETFS_READAHEAD.\nReproduction can be made easier by inserting an mdelay(100) in\nnetfs_issue_read() for the ZERO-subreq case.\n\nAFS and CIFS are normally unlikely to show this as they dispatch READ ops\nasynchronously, which allows the ZERO-subreq to finish first.  9P's READ op is\ncompletely synchronous, so the ZERO-subreq will always happen after.  It isn't\nseen all the time, though, because the collection may be done in a worker\nthread."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nnetfs: Solución para el desbloqueo temprano de lectura de página con EOF en el medio\n\nLa recopilación de resultados de lectura para lecturas en búfer parece adelantarse a la finalización de las subpeticiones bajo algunas circunstancias, como se puede ver en el siguiente fragmento de registro:\n\n    9p_client_res: cliente 18446612686390831168 response P9_TREAD tag  0 err 0\n    ...\n    netfs_sreq: R=00001b55[1] DOWN TERM  f=192 s=0 5fb2/5fb2 s=5 e=0\n    ...\n    netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2\n    netfs_folio: i=157f3 ix=00004-00004 read-done\n    netfs_folio: i=157f3 ix=00004-00004 read-unlock\n    netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2\n    netfs_folio: i=157f3 ix=00005-00005 read-done\n    netfs_folio: i=157f3 ix=00005-00005 read-unlock\n    ...\n    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c\n    netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff\n    netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8\n    ...\n    netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0\n    netfs_sreq: R=00001b55[2] ZERO TERM  f=102 s=5fb2 4e/4e s=5 e=0\n\nEl 'cto=5fb2' indica la posición de archivo recopilada a la que hemos recogido resultados hasta ahora, pero aún nos quedan 0x4e bytes más, por lo que no deberíamos haber recopilado el folio ix=00005 todavía. La subpetición 'ZERO' que borra la cola ocurre después de que desbloqueamos el folio, permitiendo que la aplicación vea la cola no borrada a través de mmap.\n\nEl problema es que netfs_read_unlock_folios() desbloqueará un folio en el que la cantidad de resultados de lectura recopilados alcanza la posición EOF, pero la subpetición ZERO se encuentra más allá de eso y, por lo tanto, ocurre después.\n\nSolucione esto cambiando la comprobación de fin para que siempre sea el fin del folio y nunca el fin del archivo.\n\nEn el futuro, debería considerar borrar hasta el final del folio aquí en lugar de añadir una subpetición ZERO para hacer esto. Por otro lado, la subpetición ZERO puede ejecutarse en paralelo con una subpetición READ asíncrona. Además, la subpetición ZERO aún puede ser necesaria para, por ejemplo, manejar extensiones en un archivo ceph que no tienen ningún almacenamiento de respaldo y, por lo tanto, son implícitamente todo ceros.\n\nEsto se puede reproducir creando un archivo cuyo tamaño no se alinea con un límite de página, por ejemplo, 24998 (0x5fb2) bytes, y luego haciendo algo como:\n\n    xfs_io -c \"mmap -r 0 0x6000\" -c \"madvise -d 0 0x6000\" \\\n           -c \"mread -v 0 0x6000\" /xfstest.test/x\n\nLos últimos 0x4e bytes deberían ser todos 00, pero si la cola no ha sido borrada todavía, es posible que vea basura allí. Esto se puede reproducir con kafs modificando el kernel para deshabilitar la llamada a netfs_read_subreq_progress() y para evitar que afs_issue_read() realice la llamada asíncrona para NETFS_READAHEAD. La reproducción se puede facilitar insertando un mdelay(100) en netfs_issue_read() para el caso de la subpetición ZERO.\n\nAFS y CIFS normalmente no suelen mostrar esto, ya que despachan operaciones READ de forma asíncrona, lo que permite que la subpetición ZERO termine primero. La operación READ de 9P es completamente síncrona, por lo que la subpetición ZERO siempre ocurrirá después. Sin embargo, no se ve todo el tiempo, porque la recopilación puede realizarse en un hilo de trabajo."
    }
  ],
  "lastModified": "2026-07-30T06:24:55.750",
  "configurations": [
    {
      "nodes": [
        {
          "negate": false,
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "C9623E9E-5166-4938-913C-3B293E162B35",
              "versionEndExcluding": "6.18.6",
              "versionStartIncluding": "6.14"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "17B67AA7-40D6-4AFA-8459-F200F3D7CFD1"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "C47E4CC9-C826-4FA9-B014-7FE3D9B318B2"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "F71D92C0-C023-48BD-B3B6-70B638EEE298"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "13580667-0A98-40CC-B29F-D12790B91BDB"
            }
          ],
          "operator": "OR"
        }
      ]
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}