fkie_cve-2024-40998
Vulnerability from fkie_nvd
Published
2024-07-12 13:15
Modified
2024-11-21 09:32
Severity ?
Summary
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(&(EXT4_SB(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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/23afcd52af06880c6c913a0ad99022b8937b575c
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/645267906944a9aeec9d5c56ee24a9096a288798
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b4b4fda34e535756f9e774fb2d09c4537b7dfd1c
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/23afcd52af06880c6c913a0ad99022b8937b575c
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/645267906944a9aeec9d5c56ee24a9096a288798
af854a3a-2127-422b-91ae-364da2661108https://git.kernel.org/stable/c/b4b4fda34e535756f9e774fb2d09c4537b7dfd1c
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ext4: arreglar ratelimit_state no inicializado-\u0026gt;bloquear acceso en __ext4_fill_super() En la siguiente concurrencia accederemos al rs-\u0026gt;lock no inicializado: ext4_fill_super ext4_register_sysfs // sysfs registrado msg_ratelimit_interval_ms // Otros procesos modificar rs-\u0026gt;interval a // distinto de cero a trav\u00e9s de msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, \"Errores en el sistema de archivos, \" __ext4_msg ___ratelimit(\u0026amp;(EXT4_SB(sb)-\u0026gt;s_msg_ratelimit_state) if (!rs-\u0026gt;interval) // hacer nada si el intervalo es 0 devuelve 1; -\u0026gt;s_msg_ratelimit_state , 5 * HZ, 10); raw_spin_lock_init(\u0026amp;rs-\u0026gt;lock); // inicia rs-\u0026gt;lock aqu\u00ed y obtiene el siguiente dump_stack: ==================== ===================================== INFORMACI\u00d3N: intentando registrar una clave no est\u00e1tica. El c\u00f3digo est\u00e1 bien pero necesita una anotaci\u00f3n de bloqueo, \u00bfo tal vez no inicializ\u00f3 este objeto antes de usarlo? apagando el validador de correcci\u00f3n de bloqueo. CPU: 12 PID: 753 Comunicaciones: montaje contaminado: GE 6.7.0-rc6-next-20231222 #504 [...] Seguimiento de llamadas: 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] 0x2b10 [ext4] text4_fill_super+0x14d/0x360 [ext4] [. ..] ================================================= ========== Normalmente el intervalo es 0 hasta que se inicializa s_msg_ratelimit_state, por lo que ___ratelimit() no hace nada. Pero el registro de sysfs precede a la inicializaci\u00f3n de rs-\u0026gt;lock, por lo que es posible cambiar rs-\u0026gt;interval a un valor distinto de cero a trav\u00e9s de la interfaz msg_ratelimit_interval_ms de sysfs mientras rs-\u0026gt;lock no est\u00e1 inicializado, y luego una llamada a ext4_msg desencadena el problema al accediendo a un rs-\u0026gt;lock no inicializado. Por lo tanto, registre sysfs despu\u00e9s de que se completen todas las inicializaciones para evitar este tipo de problemas."
    }
  ],
  "id": "CVE-2024-40998",
  "lastModified": "2024-11-21T09:32:02.043",
  "metrics": {},
  "published": "2024-07-12T13:15:20.857",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/23afcd52af06880c6c913a0ad99022b8937b575c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/645267906944a9aeec9d5c56ee24a9096a288798"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b4b4fda34e535756f9e774fb2d09c4537b7dfd1c"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/23afcd52af06880c6c913a0ad99022b8937b575c"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/645267906944a9aeec9d5c56ee24a9096a288798"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "url": "https://git.kernel.org/stable/c/b4b4fda34e535756f9e774fb2d09c4537b7dfd1c"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


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.