FKIE_CVE-2026-23189

Vulnerability from fkie_nvd - Published: 2026-02-14 17:15 - Updated: 2026-02-18 17:52
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: ceph: fix NULL pointer dereference in ceph_mds_auth_match() The CephFS kernel client has regression starting from 6.18-rc1. We have issue in ceph_mds_auth_match() if fs_name == NULL: const char fs_name = mdsc->fsc->mount_options->mds_namespace; ... if (auth->match.fs_name && strcmp(auth->match.fs_name, fs_name)) { / fsname mismatch, try next one */ return 0; } Patrick Donnelly suggested that: In summary, we should definitely start decoding `fs_name` from the MDSMap and do strict authorizations checks against it. Note that the `-o mds_namespace=foo` should only be used for selecting the file system to mount and nothing else. It's possible no mds_namespace is specified but the kernel will mount the only file system that exists which may have name "foo". This patch reworks ceph_mdsmap_decode() and namespace_equals() with the goal of supporting the suggested concept. Now struct ceph_mdsmap contains m_fs_name field that receives copy of extracted FS name by ceph_extract_encoded_string(). For the case of "old" CephFS file systems, it is used "cephfs" name. [ idryomov: replace redundant %*pE with %s in ceph_mdsmap_decode(), get rid of a series of strlen() calls in ceph_namespace_match(), drop changes to namespace_equals() body to avoid treating empty mds_namespace as equal, drop changes to ceph_mdsc_handle_fsmap() as namespace_equals() isn't an equivalent substitution there ]
Impacted products
Vendor Product Version

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix NULL pointer dereference in ceph_mds_auth_match()\n\nThe CephFS kernel client has regression starting from 6.18-rc1.\nWe have issue in ceph_mds_auth_match() if fs_name == NULL:\n\n    const char fs_name = mdsc-\u003efsc-\u003emount_options-\u003emds_namespace;\n    ...\n    if (auth-\u003ematch.fs_name \u0026\u0026 strcmp(auth-\u003ematch.fs_name, fs_name)) {\n            / fsname mismatch, try next one */\n            return 0;\n    }\n\nPatrick Donnelly suggested that: In summary, we should definitely start\ndecoding `fs_name` from the MDSMap and do strict authorizations checks\nagainst it. Note that the `-o mds_namespace=foo` should only be used for\nselecting the file system to mount and nothing else. It\u0027s possible\nno mds_namespace is specified but the kernel will mount the only\nfile system that exists which may have name \"foo\".\n\nThis patch reworks ceph_mdsmap_decode() and namespace_equals() with\nthe goal of supporting the suggested concept. Now struct ceph_mdsmap\ncontains m_fs_name field that receives copy of extracted FS name\nby ceph_extract_encoded_string(). For the case of \"old\" CephFS file\nsystems, it is used \"cephfs\" name.\n\n[ idryomov: replace redundant %*pE with %s in ceph_mdsmap_decode(),\n  get rid of a series of strlen() calls in ceph_namespace_match(),\n  drop changes to namespace_equals() body to avoid treating empty\n  mds_namespace as equal, drop changes to ceph_mdsc_handle_fsmap()\n  as namespace_equals() isn\u0027t an equivalent substitution there ]"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nceph: soluciona la desreferencia de puntero NULL en ceph_mds_auth_match()\n\nEl cliente del kernel de CephFS tiene una regresi\u00f3n a partir de 6.18-rc1.\nTenemos un problema en ceph_mds_auth_match() si fs_name == NULL:\n\n    const char fs_name = mdsc-\u0026gt;fsc-\u0026gt;mount_options-\u0026gt;mds_namespace;\n    ...\n    if (auth-\u0026gt;match.fs_name \u0026amp;\u0026amp; strcmp(auth-\u0026gt;match.fs_name, fs_name)) {\n            / el nombre de sistema de archivos no coincide, intentar el siguiente */\n            return 0;\n    }\n\nPatrick Donnelly sugiri\u00f3 que: En resumen, definitivamente deber\u00edamos empezar a decodificar \u0027fs_name\u0027 del MDSMap y realizar controles de autorizaci\u00f3n estrictos contra \u00e9l. Tenga en cuenta que \u0027-o mds_namespace=foo\u0027 solo debe usarse para seleccionar el sistema de archivos a montar y nada m\u00e1s. Es posible que no se especifique ning\u00fan mds_namespace, pero el kernel montar\u00e1 el \u00fanico sistema de archivos que existe, el cual puede tener el nombre \u0027foo\u0027.\n\nEste parche reelabora ceph_mdsmap_decode() y namespace_equals() con el objetivo de apoyar el concepto sugerido. Ahora la estructura ceph_mdsmap contiene el campo m_fs_name que recibe una copia del nombre de FS extra\u00eddo por ceph_extract_encoded_string(). Para el caso de sistemas de archivos CephFS \u0027antiguos\u0027, se utiliza el nombre \u0027cephfs\u0027.\n\n[ idryomov: reemplazar el redundante %*pE con %s en ceph_mdsmap_decode(), eliminar una serie de llamadas a strlen() en ceph_namespace_match(), descartar cambios en el cuerpo de namespace_equals() para evitar tratar un mds_namespace vac\u00edo como igual, descartar cambios en ceph_mdsc_handle_fsmap() ya que namespace_equals() no es una sustituci\u00f3n equivalente all\u00ed ]"
    }
  ],
  "id": "CVE-2026-23189",
  "lastModified": "2026-02-18T17:52:22.253",
  "metrics": {},
  "published": "2026-02-14T17:15:56.703",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/57b36ffc8881dd455d875f85c105901974af2130"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7987cce375ac8ce98e170a77aa2399f2cf6eb99f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c6f8326f26bd20d648d9a55afd68148d1b6afe28"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…