fkie_cve-2024-53176
Vulnerability from fkie_nvd
Published
2024-12-27 14:15
Modified
2024-12-27 14:15
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: smb: During unmount, ensure all cached dir instances drop their dentry The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs: BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661! This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including: - Receiving a lease break from the server - Server reconnection triggers invalidate_all_cached_dirs(), which removes all the cfids from the list - The laundromat thread decides to expire an old cfid. To solve these problems, dropping the dentry is done in queued work done in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal. The final cleanup work for cleaning up a cfid is performed via work queued in the serverclose_wq workqueue; this is done separate from dropping the dentries so that close_all_cached_dirs() doesn't block on any server operations. Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing. While we're here, add proper locking to close_all_cached_dirs(), and locking around the freeing of cfid->dentry.
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: During unmount, ensure all cached dir instances drop their dentry\n\nThe unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can\nrace with various cached directory operations, which ultimately results\nin dentries not being dropped and these kernel BUGs:\n\nBUG: Dentry ffff88814f37e358{i=1000000000080,n=/}  still in use (2) [unmount of cifs cifs]\nVFS: Busy inodes after unmount of cifs (cifs)\n------------[ cut here ]------------\nkernel BUG at fs/super.c:661!\n\nThis happens when a cfid is in the process of being cleaned up when, and\nhas been removed from the cfids-\u003eentries list, including:\n\n- Receiving a lease break from the server\n- Server reconnection triggers invalidate_all_cached_dirs(), which\n  removes all the cfids from the list\n- The laundromat thread decides to expire an old cfid.\n\nTo solve these problems, dropping the dentry is done in queued work done\nin a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()\nflushes that workqueue after it drops all the dentries of which it\u0027s\naware. This is a global workqueue (rather than scoped to a mount), but\nthe queued work is minimal.\n\nThe final cleanup work for cleaning up a cfid is performed via work\nqueued in the serverclose_wq workqueue; this is done separate from\ndropping the dentries so that close_all_cached_dirs() doesn\u0027t block on\nany server operations.\n\nBoth of these queued works expect to invoked with a cfid reference and\na tcon reference to avoid those objects from being freed while the work\nis ongoing.\n\nWhile we\u0027re here, add proper locking to close_all_cached_dirs(), and\nlocking around the freeing of cfid-\u003edentry."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: Durante el desmontaje, asegurarse de que todas las instancias de directorio en cach\u00e9 eliminen su dentry El proceso de desmontaje (cifs_kill_sb() llamando a close_all_cached_dirs()) puede competir con varias operaciones de directorio en cach\u00e9, lo que en \u00faltima instancia da como resultado que no se eliminen los dentries y estos ERRORES del kernel: ERROR: Dentry ffff88814f37e358{i=1000000000080,n=/} todav\u00eda en uso (2) [desmontaje de cifs cifs] VFS: Inodos ocupados despu\u00e9s del desmontaje de cifs (cifs) ------------[ corte aqu\u00ed ]------------ \u00a1ERROR del kernel en fs/super.c:661! Esto sucede cuando un cfid est\u00e1 en proceso de desinfecci\u00f3n y se ha eliminado de la lista cfids-\u0026gt;entries, lo que incluye: - Recibir una interrupci\u00f3n de arrendamiento del servidor - La reconexi\u00f3n del servidor activa invalidate_all_cached_dirs(), que elimina todos los cfids de la lista - El hilo de la lavander\u00eda decide hacer caducar un cfid antiguo. Para resolver estos problemas, se elimina el dentry en el trabajo en cola realizado en una cola de trabajo cfid_put_wq reci\u00e9n agregada, y close_all_cached_dirs() vac\u00eda esa cola de trabajo despu\u00e9s de eliminar todos los dentries de los que tiene conocimiento. Esta es una cola de trabajo global (en lugar de tener un alcance de montaje), pero el trabajo en cola es m\u00ednimo. El trabajo de desinfecci\u00f3n final para limpiar un cfid se realiza a trav\u00e9s del trabajo en cola en la cola de trabajo serverclose_wq; esto se hace por separado de la eliminaci\u00f3n de los dentries para que close_all_cached_dirs() no bloquee ninguna operaci\u00f3n del servidor. Se espera que ambos trabajos en cola se invoquen con una referencia cfid y una referencia tcon para evitar que esos objetos se liberen mientras el trabajo est\u00e1 en curso. Mientras estamos aqu\u00ed, agregue un bloqueo adecuado a close_all_cached_dirs() y un bloqueo alrededor de la liberaci\u00f3n de cfid-\u0026gt;dentry."
    }
  ],
  "id": "CVE-2024-53176",
  "lastModified": "2024-12-27T14:15:24.947",
  "metrics": {},
  "published": "2024-12-27T14:15:24.947",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3fa640d035e5ae526769615c35cb9ed4be6e3662"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/548812afd96982a76a93ba76c0582ea670c40d9e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/73934e535cffbda1490fa97d82690a0f9aa73e94"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ff4528bbc82d0d90073751f7b49e7b9e9c7e5638"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


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.


Loading…

Loading…