GHSA-G8QJ-5WMW-7W59

Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2025-10-28 21:30
VLAI?
Details

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

ring-buffer: Validate the persistent meta data subbuf array

The meta data for a mapped ring buffer contains an array of indexes of all the subbuffers. The first entry is the reader page, and the rest of the entries lay out the order of the subbuffers in how the ring buffer link list is to be created.

The validator currently makes sure that all the entries are within the range of 0 and nr_subbufs. But it does not check if there are any duplicates.

While working on the ring buffer, I corrupted this array, where I added duplicates. The validator did not catch it and created the ring buffer link list on top of it. Luckily, the corruption was only that the reader page was also in the writer path and only presented corrupted data but did not crash the kernel. But if there were duplicates in the writer side, then it could corrupt the ring buffer link list and cause a crash.

Create a bitmask array with the size of the number of subbuffers. Then clear it. When walking through the subbuf array checking to see if the entries are within the range, test if its bit is already set in the subbuf_mask. If it is, then there is duplicates and fail the validation. If not, set the corresponding bit and continue.

Severity ?
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-21777"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-27T03:15:18Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nring-buffer: Validate the persistent meta data subbuf array\n\nThe meta data for a mapped ring buffer contains an array of indexes of all\nthe subbuffers. The first entry is the reader page, and the rest of the\nentries lay out the order of the subbuffers in how the ring buffer link\nlist is to be created.\n\nThe validator currently makes sure that all the entries are within the\nrange of 0 and nr_subbufs. But it does not check if there are any\nduplicates.\n\nWhile working on the ring buffer, I corrupted this array, where I added\nduplicates. The validator did not catch it and created the ring buffer\nlink list on top of it. Luckily, the corruption was only that the reader\npage was also in the writer path and only presented corrupted data but did\nnot crash the kernel. But if there were duplicates in the writer side,\nthen it could corrupt the ring buffer link list and cause a crash.\n\nCreate a bitmask array with the size of the number of subbuffers. Then\nclear it. When walking through the subbuf array checking to see if the\nentries are within the range, test if its bit is already set in the\nsubbuf_mask. If it is, then there is duplicates and fail the validation.\nIf not, set the corresponding bit and continue.",
  "id": "GHSA-g8qj-5wmw-7w59",
  "modified": "2025-10-28T21:30:28Z",
  "published": "2025-02-27T03:34:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21777"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0d547a6f5e8fad26ebc12f501d7d19fccdbad6bf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3ec743d558f111d8999aea24577ba66c65ee2eeb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f5b95f1fa2ef3a03f49eeec658ba97e721412b32"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.



Detection rules are retrieved from Rulezet.