CVE-2026-68082 (GCVE-0-2026-68082)

Vulnerability from cvelistv5 – Published: 2026-08-08 09:17 – Updated: 2026-08-17 04:58
VLAI
Title
libceph: fix two unsafe bare decodes in decode_lockers()
Summary
In the Linux kernel, the following vulnerability has been resolved: libceph: fix two unsafe bare decodes in decode_lockers() decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads: 1. ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count. The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant. 2. ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field. Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers) The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers(). err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed. ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error. -EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths. Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition). [ idryomov: trim changelog, formatting ]
Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: d4ed4a530562881cc5225050e42d96034f405aae , < a54be593d0b749161b08a1e56189b2cb9114267a (git)
Affected: d4ed4a530562881cc5225050e42d96034f405aae , < a109a556115271ca7896dcda7b4b7e45e156c227 (git)
guessed Create a notification for this product.
Linux Linux Affected: 4.9
Unaffected: 0 , < 4.9 (semver)
Unaffected: 7.1.6 , ≤ 7.1.* (semver)
Unaffected: 7.2 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/ceph/cls_lock_client.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "a54be593d0b749161b08a1e56189b2cb9114267a",
              "status": "affected",
              "version": "d4ed4a530562881cc5225050e42d96034f405aae",
              "versionType": "git"
            },
            {
              "lessThan": "a109a556115271ca7896dcda7b4b7e45e156c227",
              "status": "affected",
              "version": "d4ed4a530562881cc5225050e42d96034f405aae",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/ceph/cls_lock_client.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.9"
            },
            {
              "lessThan": "4.9",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1.6",
                  "versionStartIncluding": "4.9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "4.9",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix two unsafe bare decodes in decode_lockers()\n\ndecode_lockers() in cls_lock_client.c contains two bare decode operations\nthat allow a malicious or compromised OSD to trigger slab-out-of-bounds\nreads:\n\n1. ceph_decode_32(p) at the num_lockers field has no preceding bounds\n   check. ceph_start_decoding() accepts struct_len=0 as valid -- the\n   internal ceph_decode_need(p, end, 0, bad) always passes -- so when an\n   OSD sends struct_len=0, ceph_start_decoding() returns success with\n   p == end. The immediately following bare ceph_decode_32(p) then reads\n   4 bytes past the validated buffer boundary. The garbage value is\n   passed directly to kzalloc_objs() as the locker count.\n\n   The sibling function decode_watchers() in osd_client.c already uses\n   ceph_decode_32_safe() after its own ceph_start_decoding() call.\n   decode_lockers() was the only site using the bare variant.\n\n2. ceph_decode_8(p) after the decode_locker() loop has no preceding\n   bounds check. If an OSD crafts num_lockers such that the loop\n   advances p exactly to end, the subsequent bare ceph_decode_8(p) reads\n   one byte past the validated buffer boundary. The result is passed\n   directly into *type, which is used as a lock type discriminator by\n   callers, giving an OSD-controlled one-byte OOB read with direct\n   influence over the lock type field.\n\nFix both by replacing bare operations with their safe variants:\n  ceph_decode_32(p) -\u003e ceph_decode_32_safe(p, end, *num_lockers,\n                                           err_inval)\n  ceph_decode_8(p)  -\u003e ceph_decode_8_safe(p, end, *type,\n                                          err_free_lockers)\n\nThe goto targets differ intentionally:\n  err_inval: is a new label returning -EINVAL directly. It is used for\n  the pre-allocation failure path where *lockers is not yet allocated\n  and must not be passed to ceph_free_lockers().\n\n  err_free_lockers: is the existing label. It is used for the\n  post-allocation failure path where *lockers is allocated and must\n  be freed.\n\nret is set to -EINVAL before ceph_decode_8_safe() so that\nerr_free_lockers returns the correct error code on bounds violation.\nWithout this, err_free_lockers would return a stale ret value (0 from\nthe successful decode_locker() loop), silently swallowing the error.\n\n-EINVAL is correct for both failure paths. The data received from the\nOSD is structurally malformed. -ENOMEM would misrepresent the failure\nclass to callers and to stable@ backporters triaging error paths.\n\nAttacker model: a malicious or compromised OSD in a multi-tenant Ceph\ndeployment can trigger this against any kernel client that issues the\nlock.get_info class method (e.g. during RBD exclusive lock acquisition).\n\n[ idryomov: trim changelog, formatting ]"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The flaw is reached when libceph decodes a crafted MOSDOpReply for the lock.get_info class method received over the Ceph messenger TCP session from a compromised or malicious OSD; no local syscall or ioctl is required on the victim.\nAC:L - A malicious OSD can deterministically send struct_len=0 or craft num_lockers so the decode pointer reaches end, triggering both bare decodes on every attempt without races, special memory layout, or rare kernel configuration.\nPR:N - The attacker acts as the remote Ceph OSD peer and needs no account or privileges on the victim Linux host; any kernel RBD client connected to a multi-tenant or attacker-controlled cluster is exposed during automatic exclusive-lock operations.\nUI:N - Once an RBD image is mapped, ceph_cls_lock_info() is invoked automatically during exclusive-lock acquisition and object-map lock recovery; no further victim user or administrator action is required at exploit time.\nS:U - The slab out-of-bounds reads and any resulting kernel memory corruption occur entirely within the victim host kernel running the Ceph client, without crossing VM, container, or IOMMU security boundaries.\nC:H - Bare ceph_decode_32/8 past the validated reply boundary perform slab out-of-bounds reads of adjacent kernel memory; the leaked u32 can drive kzalloc_objs() sizing and the OOB u8 directly controls the lock-type field consumed by RBD lock logic.\nI:H - Attacker-influenced out-of-bounds values feed heap allocation sizing and lock-type discrimination in kernel lock-handling paths, providing memory-corruption primitives in a privileged parser that can be leveraged beyond simple information disclosure.\nA:H - Slab out-of-bounds reads can trigger KASAN faults or kernel oops on instrumented builds, and attacker-controlled locker counts can force very large kzalloc attempts causing severe memory pressure, OOM conditions, and loss of availability on RBD client hosts."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-17T04:58:29.706Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/a54be593d0b749161b08a1e56189b2cb9114267a"
        },
        {
          "url": "https://git.kernel.org/stable/c/a109a556115271ca7896dcda7b4b7e45e156c227"
        }
      ],
      "title": "libceph: fix two unsafe bare decodes in decode_lockers()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-68082",
    "datePublished": "2026-08-08T09:17:45.394Z",
    "dateReserved": "2026-07-30T09:28:09.367Z",
    "dateUpdated": "2026-08-17T04:58:29.706Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-68082",
      "date": "2026-08-17",
      "epss": "0.00308",
      "percentile": "0.23377"
    },
    "microsoft_vex": {
      "current_release_date": "2026-08-09T01:02:46.000Z",
      "cve": "CVE-2026-68082",
      "id": "msrc_CVE-2026-68082",
      "initial_release_date": "2026-08-09T01:02:46.000Z",
      "product_status:under_investigation": "1",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "libceph: fix two unsafe bare decodes in decode_lockers()",
      "url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-68082.json",
      "version": "1"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-68082\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-08-08T10:16:55.377\",\"lastModified\":\"2026-08-17T05:18:07.353\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nlibceph: fix two unsafe bare decodes in decode_lockers()\\n\\ndecode_lockers() in cls_lock_client.c contains two bare decode operations\\nthat allow a malicious or compromised OSD to trigger slab-out-of-bounds\\nreads:\\n\\n1. ceph_decode_32(p) at the num_lockers field has no preceding bounds\\n   check. ceph_start_decoding() accepts struct_len=0 as valid -- the\\n   internal ceph_decode_need(p, end, 0, bad) always passes -- so when an\\n   OSD sends struct_len=0, ceph_start_decoding() returns success with\\n   p == end. The immediately following bare ceph_decode_32(p) then reads\\n   4 bytes past the validated buffer boundary. The garbage value is\\n   passed directly to kzalloc_objs() as the locker count.\\n\\n   The sibling function decode_watchers() in osd_client.c already uses\\n   ceph_decode_32_safe() after its own ceph_start_decoding() call.\\n   decode_lockers() was the only site using the bare variant.\\n\\n2. ceph_decode_8(p) after the decode_locker() loop has no preceding\\n   bounds check. If an OSD crafts num_lockers such that the loop\\n   advances p exactly to end, the subsequent bare ceph_decode_8(p) reads\\n   one byte past the validated buffer boundary. The result is passed\\n   directly into *type, which is used as a lock type discriminator by\\n   callers, giving an OSD-controlled one-byte OOB read with direct\\n   influence over the lock type field.\\n\\nFix both by replacing bare operations with their safe variants:\\n  ceph_decode_32(p) -\u003e ceph_decode_32_safe(p, end, *num_lockers,\\n                                           err_inval)\\n  ceph_decode_8(p)  -\u003e ceph_decode_8_safe(p, end, *type,\\n                                          err_free_lockers)\\n\\nThe goto targets differ intentionally:\\n  err_inval: is a new label returning -EINVAL directly. It is used for\\n  the pre-allocation failure path where *lockers is not yet allocated\\n  and must not be passed to ceph_free_lockers().\\n\\n  err_free_lockers: is the existing label. It is used for the\\n  post-allocation failure path where *lockers is allocated and must\\n  be freed.\\n\\nret is set to -EINVAL before ceph_decode_8_safe() so that\\nerr_free_lockers returns the correct error code on bounds violation.\\nWithout this, err_free_lockers would return a stale ret value (0 from\\nthe successful decode_locker() loop), silently swallowing the error.\\n\\n-EINVAL is correct for both failure paths. The data received from the\\nOSD is structurally malformed. -ENOMEM would misrepresent the failure\\nclass to callers and to stable@ backporters triaging error paths.\\n\\nAttacker model: a malicious or compromised OSD in a multi-tenant Ceph\\ndeployment can trigger this against any kernel client that issues the\\nlock.get_info class method (e.g. during RBD exclusive lock acquisition).\\n\\n[ idryomov: trim changelog, formatting ]\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"net/ceph/cls_lock_client.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"d4ed4a530562881cc5225050e42d96034f405aae\",\"lessThan\":\"a54be593d0b749161b08a1e56189b2cb9114267a\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"d4ed4a530562881cc5225050e42d96034f405aae\",\"lessThan\":\"a109a556115271ca7896dcda7b4b7e45e156c227\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"net/ceph/cls_lock_client.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4.9\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"4.9\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.1.6\",\"lessThanOrEqual\":\"7.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.2\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":9.8,\"baseSeverity\":\"CRITICAL\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":3.9,\"impactScore\":5.9}]},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/a109a556115271ca7896dcda7b4b7e45e156c227\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/a54be593d0b749161b08a1e56189b2cb9114267a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}



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.