FKIE_CVE-2026-23189

Vulnerability from fkie_nvd - Published: 2026-02-14 17:15 - Updated: 2026-03-18 17:18
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 ]

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "ACE64C6D-2601-447E-8A2B-0D932A7C5C60",
              "versionEndExcluding": "6.12.70",
              "versionStartIncluding": "6.12.58",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "6B6161FA-39A8-4DBD-9D3F-130200A2D241",
              "versionEndExcluding": "6.18.10",
              "versionStartIncluding": "6.17.8",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*",
              "matchCriteriaId": "17B67AA7-40D6-4AFA-8459-F200F3D7CFD1",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*",
              "matchCriteriaId": "C47E4CC9-C826-4FA9-B014-7FE3D9B318B2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*",
              "matchCriteriaId": "F71D92C0-C023-48BD-B3B6-70B638EEE298",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*",
              "matchCriteriaId": "13580667-0A98-40CC-B29F-D12790B91BDB",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*",
              "matchCriteriaId": "CAD1FED7-CF48-47BF-AC7D-7B6FA3C065FC",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc6:*:*:*:*:*:*",
              "matchCriteriaId": "3EF854A1-ABB1-4E93-BE9A-44569EC76C0D",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc7:*:*:*:*:*:*",
              "matchCriteriaId": "F5DC0CA6-F0AF-4DDF-A882-3DADB9A886A7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc8:*:*:*:*:*:*",
              "matchCriteriaId": "EB5B7DFC-C36B-45D8-922C-877569FDDF43",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "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-03-18T17:18:58.633",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2026-02-14T17:15:56.703",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/57b36ffc8881dd455d875f85c105901974af2130"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/7987cce375ac8ce98e170a77aa2399f2cf6eb99f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/c6f8326f26bd20d648d9a55afd68148d1b6afe28"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-476"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}


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…