ghsa-9fhm-w5m6-rqv5
Vulnerability from github
Published
2025-01-11 15:30
Modified
2025-01-31 15:30
Severity ?
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Details

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

dlm: fix possible lkb_resource null dereference

This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded.

The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference.

In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-47809"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-11T13:15:22Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndlm: fix possible lkb_resource null dereference\n\nThis patch fixes a possible null pointer dereference when this function is\ncalled from request_lock() as lkb-\u003elkb_resource is not assigned yet,\nonly after validate_lock_args() by calling attach_lkb(). Another issue\nis that a resource name could be a non printable bytearray and we cannot\nassume to be ASCII coded.\n\nThe log functionality is probably never being hit when DLM is used in\nnormal way and no debug logging is enabled. The null pointer dereference\ncan only occur on a new created lkb that does not have the resource\nassigned yet, it probably never hits the null pointer dereference but we\nshould be sure that other changes might not change this behaviour and we\nactually can hit the mentioned null pointer dereference.\n\nIn this patch we just drop the printout of the resource name, the lkb id\nis enough to make a possible connection to a resource name if this\nexists.",
  "id": "GHSA-9fhm-w5m6-rqv5",
  "modified": "2025-01-31T15:30:44Z",
  "published": "2025-01-11T15:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47809"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2db11504ef82a60c1a2063ba7431a5cd013ecfcb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6fbdc3980b70e9c1c86eccea7d5ee68108008fa7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b98333c67daf887c724cd692e88e2db9418c0861"
    }
  ],
  "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 seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.