GHSA-H9Q4-GJ29-45HP

Vulnerability from github – Published: 2026-10-28 12:31 – Updated: 2026-10-30 15:34
VLAI
Details

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

ocfs2/dlm: Protect the recovery list during debugfs reads

Recovery participant records must remain alive while debug_state_print() walks reco.node_data and formats their fields. The formatter holds dlm->spinlock, but the recovery participant list is protected by dlm_reco_state_lock. In particular, dlm_destroy_recovery_area() detaches the list under dlm_reco_state_lock and frees the detached records after releasing it. A concurrent debugfs open can therefore read freed memory.

Protect the participant traversal and field reads in debug_state_print() with dlm_reco_state_lock, matching the existing list writers. This also serializes the traversal against list_add_tail() during recovery-area initialization. Make the existing lock available to the debug code through dlmcommon.h; the lock remains internal to the OCFS2 DLM module.

Release dlm->spinlock after formatting the other domain state and before acquiring dlm_reco_state_lock, so the debug reader does not nest the two locks. Leave recovery list insertion, detachment and freeing unchanged.

KASAN report as below:

BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0
Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896

CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x93/0xd0
 print_report+0xce/0x630
 ? debug_state_open+0x1169/0x12d0
 ? srso_alias_return_thunk+0x5/0xfbef5
 ? __virt_addr_valid+0x20e/0x420
 ? debug_state_open+0x1169/0x12d0
 kasan_report+0xe0/0x110
 ? debug_state_open+0x1169/0x12d0
 debug_state_open+0x1169/0x12d0
 ? __pfx_debug_state_open+0x10/0x10
 full_proxy_open_regular+0x193/0x310
 do_dentry_open+0x595/0x12d0
 ? __pfx_full_proxy_open_regular+0x10/0x10
 vfs_open_consume+0xd1/0x400
 ? srso_alias_return_thunk+0x5/0xfbef5
 path_openat+0x18d0/0x2020
 ? __pfx_path_openat+0x10/0x10
 do_file_open+0x21e/0x470
 ? __pfx_do_file_open+0x10/0x10
 ? _raw_spin_unlock+0x23/0x40
 ? srso_alias_return_thunk+0x5/0xfbef5
 ? alloc_fd+0x3a6/0x6b0
 do_sys_openat2+0xf4/0x1b0
 ? __pfx_do_sys_openat2+0x10/0x10
 ? srso_alias_return_thunk+0x5/0xfbef5
 ? __fput+0x5b5/0xa60
 __x64_sys_openat+0x136/0x1e0
 ? __pfx___x64_sys_openat+0x10/0x10
 do_syscall_64+0x114/0x620
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
[Register dump omitted.]
 </TASK>

Allocated by task 880:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0xaa/0xb0
 __kmalloc_cache_noprof+0x28d/0x610
 dlm_remaster_locks+0x147/0x1d90
 dlm_do_recovery+0xde1/0x1580
 dlm_recovery_thread+0x109/0x300
 kthread+0x351/0x460
 ret_from_fork+0x659/0x940
 ret_from_fork_asm+0x1a/0x30

Freed by task 880:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 __kasan_slab_free+0x5f/0x80
 kfree+0x308/0x580
 dlm_destroy_recovery_area+0x285/0x460
 dlm_remaster_locks+0x17c4/0x1d90
 dlm_do_recovery+0xde1/0x1580
 dlm_recovery_thread+0x109/0x300
 kthread+0x351/0x460
 ret_from_fork+0x659/0x940
 ret_from_fork_asm+0x1a/0x30

The buggy address belongs to the object at ffff88810662ef80
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 0 bytes inside of
 freed 32-byte region [ffff88810662ef80, ffff88810662efa0)

[Page and memory-state dumps omitted.]
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-99204"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-28T11:17:41Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2/dlm: Protect the recovery list during debugfs reads\n\nRecovery participant records must remain alive while debug_state_print()\nwalks reco.node_data and formats their fields. The formatter holds\ndlm-\u003espinlock, but the recovery participant list is protected by\ndlm_reco_state_lock. In particular, dlm_destroy_recovery_area() detaches\nthe list under dlm_reco_state_lock and frees the detached records after\nreleasing it. A concurrent debugfs open can therefore read freed memory.\n\nProtect the participant traversal and field reads in debug_state_print()\nwith dlm_reco_state_lock, matching the existing list writers. This also\nserializes the traversal against list_add_tail() during recovery-area\ninitialization. Make the existing lock available to the debug code\nthrough dlmcommon.h; the lock remains internal to the OCFS2 DLM module.\n\nRelease dlm-\u003espinlock after formatting the other domain state and before\nacquiring dlm_reco_state_lock, so the debug reader does not nest the two\nlocks. Leave recovery list insertion, detachment and freeing unchanged.\n\nKASAN report as below:\n\n    BUG: KASAN: slab-use-after-free in debug_state_open+0x1169/0x12d0\n    Read of size 4 at addr ffff88810662ef80 by task dlm-state-stres/896\n\n    CPU: 1 UID: 0 PID: 896 Comm: dlm-state-stres Not tainted 7.3.0-rc4-next-20260921-pmb-ocfs2-functional-v1+ #1 PREEMPT(lazy)\n    Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n    Call Trace:\n     \u003cTASK\u003e\n     dump_stack_lvl+0x93/0xd0\n     print_report+0xce/0x630\n     ? debug_state_open+0x1169/0x12d0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __virt_addr_valid+0x20e/0x420\n     ? debug_state_open+0x1169/0x12d0\n     kasan_report+0xe0/0x110\n     ? debug_state_open+0x1169/0x12d0\n     debug_state_open+0x1169/0x12d0\n     ? __pfx_debug_state_open+0x10/0x10\n     full_proxy_open_regular+0x193/0x310\n     do_dentry_open+0x595/0x12d0\n     ? __pfx_full_proxy_open_regular+0x10/0x10\n     vfs_open_consume+0xd1/0x400\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     path_openat+0x18d0/0x2020\n     ? __pfx_path_openat+0x10/0x10\n     do_file_open+0x21e/0x470\n     ? __pfx_do_file_open+0x10/0x10\n     ? _raw_spin_unlock+0x23/0x40\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? alloc_fd+0x3a6/0x6b0\n     do_sys_openat2+0xf4/0x1b0\n     ? __pfx_do_sys_openat2+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __fput+0x5b5/0xa60\n     __x64_sys_openat+0x136/0x1e0\n     ? __pfx___x64_sys_openat+0x10/0x10\n     do_syscall_64+0x114/0x620\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n    [Register dump omitted.]\n     \u003c/TASK\u003e\n\n    Allocated by task 880:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     __kasan_kmalloc+0xaa/0xb0\n     __kmalloc_cache_noprof+0x28d/0x610\n     dlm_remaster_locks+0x147/0x1d90\n     dlm_do_recovery+0xde1/0x1580\n     dlm_recovery_thread+0x109/0x300\n     kthread+0x351/0x460\n     ret_from_fork+0x659/0x940\n     ret_from_fork_asm+0x1a/0x30\n\n    Freed by task 880:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     kasan_save_free_info+0x3b/0x60\n     __kasan_slab_free+0x5f/0x80\n     kfree+0x308/0x580\n     dlm_destroy_recovery_area+0x285/0x460\n     dlm_remaster_locks+0x17c4/0x1d90\n     dlm_do_recovery+0xde1/0x1580\n     dlm_recovery_thread+0x109/0x300\n     kthread+0x351/0x460\n     ret_from_fork+0x659/0x940\n     ret_from_fork_asm+0x1a/0x30\n\n    The buggy address belongs to the object at ffff88810662ef80\n     which belongs to the cache kmalloc-32 of size 32\n    The buggy address is located 0 bytes inside of\n     freed 32-byte region [ffff88810662ef80, ffff88810662efa0)\n\n    [Page and memory-state dumps omitted.]",
  "id": "GHSA-h9q4-gj29-45hp",
  "modified": "2026-10-30T15:34:24Z",
  "published": "2026-10-28T12:31:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99204"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/03f2fdcc94238a5127ff8a21a4544fd6118cfc7b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/04d4571c00db61a9664f387752fa05cb3c08a537"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1c1dbaa16d70cf3d6b9b21503fc188f560376866"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/25de9d3b5a81ba7bd52fdc9601f9ea7d1d3d6ae8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2bc426a32bfb78868c7f76d9547132837b6b5284"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/403669041cb77bb5ffc5ce92bcfb49b2da3d989d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4c435828932bf46f29860e4a0375bcae101b778a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c8bc0d0f2ca3df37ef4d9c69ac5fb7d417d9b035"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.