nvd-json-data-feeds/CVE-2024/CVE-2024-394xx/CVE-2024-39463.json

{
  "id": "CVE-2024-39463",
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "published": "2024-06-25T15:15:14.760",
  "lastModified": "2024-06-25T18:50:42.040",
  "vulnStatus": "Undergoing Analysis",
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\n9p: add missing locking around taking dentry fid list\n\nFix a use-after-free on dentry's d_fsdata fid list when a thread\nlooks up a fid through dentry while another thread unlinks it:\n\nUAF thread:\nrefcount_t: addition on 0; use-after-free.\n p9_fid_get linux/./include/net/9p/client.h:262\n v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129\n v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181\n v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314\n v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400\n vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248\n\nFreed by:\n p9_fid_destroy (inlined)\n p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456\n p9_fid_put linux/./include/net/9p/client.h:278\n v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55\n v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518\n vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335\n\nThe problem is that d_fsdata was not accessed under d_lock, because\nd_release() normally is only called once the dentry is otherwise no\nlonger accessible but since we also call it explicitly in v9fs_remove\nthat lock is required:\nmove the hlist out of the dentry under lock then unref its fids once\nthey are no longer accessible."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: 9p: agregar bloqueo faltante al tomar la lista de fid de dentry. Se corrigi\u00f3 un use-after-free en la lista de fid d_fsdata de dentry cuando un subproceso busca un fid a trav\u00e9s de dentry mientras otro subproceso lo desvincula: UAF hilo: refcount_t: suma en 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 Linux /fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Liberado por: p9_fid_destroy (en l\u00ednea) desconocido+0xb0 /0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 El problema es que no se accedi\u00f3 a d_fsdata bajo d_lock, porque normalmente d_release() solo se llama una vez que dentry no est\u00e1 disponible. ya no es accesible, pero como tambi\u00e9n lo llamamos expl\u00edcitamente en v9fs_remove, ese bloqueo es necesario: mueva la hlist fuera del dentry bajo bloqueo y luego elimine la referencia de sus fids una vez que ya no sean accesibles."
    }
  ],
  "metrics": {},
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/c898afdc15645efb555acb6d85b484eb40a45409",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/cb299cdba09f46f090b843d78ba26b667d50a456",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/f0c5c944c6d8614c19e6e9a97fd2011dcd30e8f5",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/fe17ebf22feb4ad7094d597526d558a49aac92b4",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ]
}