ghsa-p23j-c29j-hjgv
Vulnerability from github
Published
2024-07-12 15:31
Modified
2024-07-12 15:31
Details

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

ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()

In the following concurrency we will access the uninitialized rs->lock:

ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ratelimit(&(EXT4SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, RET_IP) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock here

and get the following dump_stack:

========================================================= INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ratelimit+0xf6/0x220 _ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4] [...] =========================================================

Normally interval is 0 until s_msg_ratelimit_state is initialized, so ___ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is uninitialized, and then a call to ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-40998"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-12T13:15:20Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix uninitialized ratelimit_state-\u003elock access in __ext4_fill_super()\n\nIn the following concurrency we will access the uninitialized rs-\u003elock:\n\next4_fill_super\n  ext4_register_sysfs\n   // sysfs registered msg_ratelimit_interval_ms\n                             // Other processes modify rs-\u003einterval to\n                             // non-zero via msg_ratelimit_interval_ms\n  ext4_orphan_cleanup\n    ext4_msg(sb, KERN_INFO, \"Errors on filesystem, \"\n      __ext4_msg\n        ___ratelimit(\u0026(EXT4_SB(sb)-\u003es_msg_ratelimit_state)\n          if (!rs-\u003einterval)  // do nothing if interval is 0\n            return 1;\n          raw_spin_trylock_irqsave(\u0026rs-\u003elock, flags)\n            raw_spin_trylock(lock)\n              _raw_spin_trylock\n                __raw_spin_trylock\n                  spin_acquire(\u0026lock-\u003edep_map, 0, 1, _RET_IP_)\n                    lock_acquire\n                      __lock_acquire\n                        register_lock_class\n                          assign_lock_key\n                            dump_stack();\n  ratelimit_state_init(\u0026sbi-\u003es_msg_ratelimit_state, 5 * HZ, 10);\n    raw_spin_lock_init(\u0026rs-\u003elock);\n    // init rs-\u003elock here\n\nand get the following dump_stack:\n\n=========================================================\nINFO: trying to register non-static key.\nThe code is fine but needs lockdep annotation, or maybe\nyou didn\u0027t initialize this object before use?\nturning off the locking correctness validator.\nCPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504\n[...]\nCall Trace:\n dump_stack_lvl+0xc5/0x170\n dump_stack+0x18/0x30\n register_lock_class+0x740/0x7c0\n __lock_acquire+0x69/0x13a0\n lock_acquire+0x120/0x450\n _raw_spin_trylock+0x98/0xd0\n ___ratelimit+0xf6/0x220\n __ext4_msg+0x7f/0x160 [ext4]\n ext4_orphan_cleanup+0x665/0x740 [ext4]\n __ext4_fill_super+0x21ea/0x2b10 [ext4]\n ext4_fill_super+0x14d/0x360 [ext4]\n[...]\n=========================================================\n\nNormally interval is 0 until s_msg_ratelimit_state is initialized, so\n___ratelimit() does nothing. But registering sysfs precedes initializing\nrs-\u003elock, so it is possible to change rs-\u003einterval to a non-zero value\nvia the msg_ratelimit_interval_ms interface of sysfs while rs-\u003elock is\nuninitialized, and then a call to ext4_msg triggers the problem by\naccessing an uninitialized rs-\u003elock. Therefore register sysfs after all\ninitializations are complete to avoid such problems.",
  "id": "GHSA-p23j-c29j-hjgv",
  "modified": "2024-07-12T15:31:29Z",
  "published": "2024-07-12T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40998"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/23afcd52af06880c6c913a0ad99022b8937b575c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/645267906944a9aeec9d5c56ee24a9096a288798"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b4b4fda34e535756f9e774fb2d09c4537b7dfd1c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


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