FKIE_CVE-2026-23249

Vulnerability from fkie_nvd - Published: 2026-03-18 18:16 - Updated: 2026-03-19 13:25
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: xfs: check for deleted cursors when revalidating two btrees The free space and inode btree repair functions will rebuild both btrees at the same time, after which it needs to evaluate both btrees to confirm that the corruptions are gone. However, Jiaming Zhang ran syzbot and produced a crash in the second xchk_allocbt call. His root-cause analysis is as follows (with minor corrections): In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first for BNOBT, second for CNTBT). The cause of this issue is that the first call nullified the cursor required by the second call. Let's first enter xrep_revalidate_allocbt() via following call chain: xfs_file_ioctl() -> xfs_ioc_scrubv_metadata() -> xfs_scrub_metadata() -> `sc->ops->repair_eval(sc)` -> xrep_revalidate_allocbt() xchk_allocbt() is called twice in this function. In the first call: /* Note that sc->sm->sm_type is XFS_SCRUB_TYPE_BNOPT now */ xchk_allocbt() -> xchk_btree() -> `bs->scrub_rec(bs, recp)` -> xchk_allocbt_rec() -> xchk_allocbt_xref() -> xchk_allocbt_xref_other() since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to &sc->sa.cnt_cur. Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call chain: xfs_alloc_get_rec() -> xfs_btree_get_rec() -> xfs_btree_check_block() -> (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter is true, return -EFSCORRUPTED. This should be caused by ioctl$XFS_IOC_ERROR_INJECTION I guess. Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this function, *curpp (points to sc->sa.cnt_cur) is nullified. Back to xrep_revalidate_allocbt(), since sc->sa.cnt_cur has been nullified, it then triggered null-ptr-deref via xchk_allocbt() (second call) -> xchk_btree(). So. The bnobt revalidation failed on a cross-reference attempt, so we deleted the cntbt cursor, and then crashed when we tried to revalidate the cntbt. Therefore, check for a null cntbt cursor before that revalidation, and mark the repair incomplete. Also we can ignore the second tree entirely if the first tree was rebuilt but is already corrupt. Apply the same fix to xrep_revalidate_iallocbt because it has the same problem.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/55e03b8cbe2783ec9acfb88e8adb946ed504e117
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5991e96f2ae82df60a3e4ed00f3432d9f3502a99
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b04baa848c0543b240b1bd8aecff470382f6f154
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/d69de525bc7ab27713342080bf50826df3f6a68f
Impacted products
Vendor Product Version
To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfs: check for deleted cursors when revalidating two btrees\n\nThe free space and inode btree repair functions will rebuild both btrees\nat the same time, after which it needs to evaluate both btrees to\nconfirm that the corruptions are gone.\n\nHowever, Jiaming Zhang ran syzbot and produced a crash in the second\nxchk_allocbt call.  His root-cause analysis is as follows (with minor\ncorrections):\n\n In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first\n for BNOBT, second for CNTBT). The cause of this issue is that the\n first call nullified the cursor required by the second call.\n\n Let\u0027s first enter xrep_revalidate_allocbt() via following call chain:\n\n xfs_file_ioctl() -\u003e\n xfs_ioc_scrubv_metadata() -\u003e\n xfs_scrub_metadata() -\u003e\n `sc-\u003eops-\u003erepair_eval(sc)` -\u003e\n xrep_revalidate_allocbt()\n\n xchk_allocbt() is called twice in this function. In the first call:\n\n /* Note that sc-\u003esm-\u003esm_type is XFS_SCRUB_TYPE_BNOPT now */\n xchk_allocbt() -\u003e\n xchk_btree() -\u003e\n `bs-\u003escrub_rec(bs, recp)` -\u003e\n xchk_allocbt_rec() -\u003e\n xchk_allocbt_xref() -\u003e\n xchk_allocbt_xref_other()\n\n since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to \u0026sc-\u003esa.cnt_cur.\n Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call\n chain:\n\n xfs_alloc_get_rec() -\u003e\n xfs_btree_get_rec() -\u003e\n xfs_btree_check_block() -\u003e\n (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter\n is true, return -EFSCORRUPTED. This should be caused by\n ioctl$XFS_IOC_ERROR_INJECTION I guess.\n\n Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from\n xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this\n function, *curpp (points to sc-\u003esa.cnt_cur) is nullified.\n\n Back to xrep_revalidate_allocbt(), since sc-\u003esa.cnt_cur has been\n nullified, it then triggered null-ptr-deref via xchk_allocbt() (second\n call) -\u003e xchk_btree().\n\nSo.  The bnobt revalidation failed on a cross-reference attempt, so we\ndeleted the cntbt cursor, and then crashed when we tried to revalidate\nthe cntbt.  Therefore, check for a null cntbt cursor before that\nrevalidation, and mark the repair incomplete.  Also we can ignore the\nsecond tree entirely if the first tree was rebuilt but is already\ncorrupt.\n\nApply the same fix to xrep_revalidate_iallocbt because it has the same\nproblem."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nxfs: verificar cursores eliminados al revalidar dos btrees\n\nLas funciones de reparaci\u00f3n de btree de espacio libre e inodo reconstruir\u00e1n ambos btrees al mismo tiempo, despu\u00e9s de lo cual necesita evaluar ambos btrees para confirmar que las corrupciones han desaparecido.\n\nSin embargo, Jiaming Zhang ejecut\u00f3 syzbot y produjo un fallo en la segunda llamada a xchk_allocbt. Su an\u00e1lisis de causa ra\u00edz es el siguiente (con correcciones menores):\n\nEn xrep_revalidate_allocbt(), se llama a xchk_allocbt() dos veces (primero para BNOBT, segundo para CNTBT). La causa de este problema es que la primera llamada anul\u00f3 el cursor requerido por la segunda llamada.\n\nPrimero entremos en xrep_revalidate_allocbt() a trav\u00e9s de la siguiente cadena de llamadas:\n\nxfs_file_ioctl() -\u0026gt;\nxfs_ioc_scrubv_metadata() -\u0026gt;\nxfs_scrub_metadata() -\u0026gt;\n\u0027sc-\u0026gt;ops-\u0026gt;repair_eval(sc)\u0027 -\u0026gt;\nxrep_revalidate_allocbt()\n\nSe llama a xchk_allocbt() dos veces en esta funci\u00f3n. En la primera llamada:\n\n/* Tenga en cuenta que sc-\u0026gt;sm-\u0026gt;sm_type es XFS_SCRUB_TYPE_BNOPT ahora */\nxchk_allocbt() -\u0026gt;\nxchk_btree() -\u0026gt;\n\u0027bs-\u0026gt;scrub_rec(bs, recp)\u0027 -\u0026gt;\nxchk_allocbt_rec() -\u0026gt;\nxchk_allocbt_xref() -\u0026gt;\nxchk_allocbt_xref_other()\n\ndado que sm_type es XFS_SCRUB_TYPE_BNOBT, pur se establece en \u0026amp;sc-\u0026gt;sa.cnt_cur. El kernel llam\u00f3 a xfs_alloc_get_rec() y devolvi\u00f3 -EFSCORRUPTED. Cadena de llamadas:\n\nxfs_alloc_get_rec() -\u0026gt;\nxfs_btree_get_rec() -\u0026gt;\nxfs_btree_check_block() -\u0026gt;\n(XFS_IS_CORRUPT || XFS_TEST_ERROR), el primero es falso y el segundo es verdadero, devuelve -EFSCORRUPTED. Esto deber\u00eda ser causado por ioctl$XFS_IOC_ERROR_INJECTION, supongo.\n\nVolviendo a xchk_allocbt_xref_other(), despu\u00e9s de recibir -EFSCORRUPTED de xfs_alloc_get_rec(), el kernel llam\u00f3 a xchk_should_check_xref(). En esta funci\u00f3n, *curpp (que apunta a sc-\u0026gt;sa.cnt_cur) es anulado.\n\nVolviendo a xrep_revalidate_allocbt(), dado que sc-\u0026gt;sa.cnt_cur ha sido anulado, entonces activ\u00f3 una desreferencia de puntero nulo a trav\u00e9s de xchk_allocbt() (segunda llamada) -\u0026gt; xchk_btree().\n\nAs\u00ed que. La revalidaci\u00f3n de bnobt fall\u00f3 en un intento de referencia cruzada, por lo que eliminamos el cursor cntbt, y luego fallamos cuando intentamos revalidar el cntbt. Por lo tanto, verifique si hay un cursor cntbt nulo antes de esa revalidaci\u00f3n, y marque la reparaci\u00f3n como incompleta. Tambi\u00e9n podemos ignorar el segundo \u00e1rbol por completo si el primer \u00e1rbol fue reconstruido pero ya est\u00e1 corrupto.\n\nAplique la misma correcci\u00f3n a xrep_revalidate_iallocbt porque tiene el mismo problema."
    }
  ],
  "id": "CVE-2026-23249",
  "lastModified": "2026-03-19T13:25:00.570",
  "metrics": {},
  "published": "2026-03-18T18:16:22.787",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/55e03b8cbe2783ec9acfb88e8adb946ed504e117"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5991e96f2ae82df60a3e4ed00f3432d9f3502a99"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b04baa848c0543b240b1bd8aecff470382f6f154"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/d69de525bc7ab27713342080bf50826df3f6a68f"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.