CVE-2024-47741

{"id": "CVE-2024-47741", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.0, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 1.0}]}, "published": "2024-10-21T13:15:04.207", "references": [{"url": "https://git.kernel.org/stable/c/33d1310d4496e904123dab9c28b2d8d2c1800f97", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/7ee85f5515e86a4e2a2f51969795920733912bad", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a412ca489ac27b9d0e603499315b7139c948130d", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/f56a6d9c267ec7fa558ede7755551c047b1034cd", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-362"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race setting file private on concurrent lseek using same fd\n\nWhen doing concurrent lseek(2) system calls against the same file\ndescriptor, using multiple threads belonging to the same process, we have\na short time window where a race happens and can result in a memory leak.\n\nThe race happens like this:\n\n1) A program opens a file descriptor for a file and then spawns two\n threads (with the pthreads library for example), lets call them\n task A and task B;\n\n2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at\n file.c:find_desired_extent() while holding a read lock on the inode;\n\n3) At the start of find_desired_extent(), it extracts the file's\n private_data pointer into a local variable named 'private', which has\n a value of NULL;\n\n4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode\n in shared mode and enters file.c:find_desired_extent(), where it also\n extracts file->private_data into its local variable 'private', which\n has a NULL value;\n\n5) Because it saw a NULL file private, task A allocates a private\n structure and assigns to the file structure;\n\n6) Task B also saw a NULL file private so it also allocates its own file\n private and then assigns it to the same file structure, since both\n tasks are using the same file descriptor.\n\n At this point we leak the private structure allocated by task A.\n\nBesides the memory leak, there's also the detail that both tasks end up\nusing the same cached state record in the private structure (struct\nbtrfs_file_private::llseek_cached_state), which can result in a\nuse-after-free problem since one task can free it while the other is\nstill using it (only one task took a reference count on it). Also, sharing\nthe cached state is not a good idea since it could result in incorrect\nresults in the future - right now it should not be a problem because it\nend ups being used only in extent-io-tree.c:count_range_bits() where we do\nrange validation before using the cached state.\n\nFix this by protecting the private assignment and check of a file while\nholding the inode's spinlock and keep track of the task that allocated\nthe private, so that it's used only by that task in order to prevent\nuser-after-free issues with the cached state record as well as potentially\nusing it incorrectly in the future."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: arreglo de ejecuci\u00f3n que establece el archivo privado en lseek concurrente usando el mismo fd Al realizar llamadas al sistema lseek(2) concurrentes contra el mismo descriptor de archivo, usando m\u00faltiples subprocesos que pertenecen al mismo proceso, tenemos una ventana de tiempo corta donde ocurre una ejecuci\u00f3n y puede resultar en una p\u00e9rdida de memoria. La ejecuci\u00f3n ocurre as\u00ed: 1) Un programa abre un descriptor de archivo para un archivo y luego genera dos subprocesos (con la biblioteca pthreads por ejemplo), llam\u00e9moslos tarea A y tarea B; 2) La tarea A llama a lseek con SEEK_DATA o SEEK_HOLE y termina en file.c:find_desired_extent() mientras mantiene un bloqueo de lectura en el inodo; 3) Al comienzo de find_desired_extent(), extrae el puntero private_data del archivo en una variable local llamada 'private', que tiene un valor de NULL; 4) La tarea B tambi\u00e9n llama a lseek con SEEK_DATA o SEEK_HOLE, bloquea el inodo en modo compartido e ingresa a file.c:find_desired_extent(), donde tambi\u00e9n extrae file->private_data en su variable local 'private', que tiene un valor NULL; 5) Debido a que vio un archivo privado NULL, la tarea A asigna una estructura privada y la asigna a la estructura de archivo; 6) La tarea B tambi\u00e9n vio un archivo privado NULL, por lo que tambi\u00e9n asigna su propio archivo privado y luego lo asigna a la misma estructura de archivo, ya que ambas tareas est\u00e1n usando el mismo descriptor de archivo. En este punto filtramos la estructura privada asignada por la tarea A. Adem\u00e1s de la fuga de memoria, tambi\u00e9n est\u00e1 el detalle de que ambas tareas terminan usando el mismo registro de estado en cach\u00e9 en la estructura privada (struct btrfs_file_private::llseek_cached_state), lo que puede resultar en un problema de use after free, ya que una tarea puede liberarlo mientras la otra todav\u00eda lo est\u00e1 usando (solo una tarea tom\u00f3 un recuento de referencia en \u00e9l). Adem\u00e1s, compartir el estado en cach\u00e9 no es una buena idea, ya que podr\u00eda resultar en resultados incorrectos en el futuro; en este momento no deber\u00eda ser un problema porque termina siendo utilizado solo en extended-io-tree.c:count_range_bits() donde realizamos la validaci\u00f3n de rango antes de usar el estado en cach\u00e9. Solucione esto protegiendo la asignaci\u00f3n privada y la verificaci\u00f3n de un archivo mientras mantiene el spinlock del inodo y realice un seguimiento de la tarea que asign\u00f3 el privado, de modo que solo lo use esa tarea para evitar problemas de use after free con el registro de estado en cach\u00e9, as\u00ed como potencialmente usarlo incorrectamente en el futuro."}], "lastModified": "2024-10-23T22:14:34.090", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "D448821D-C085-4CAF-88FA-2DDE7BE21976", "versionEndExcluding": "6.6.54", "versionStartIncluding": "6.2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "CE94BB8D-B0AB-4563-9ED7-A12122B56EBE", "versionEndExcluding": "6.10.13", "versionStartIncluding": "6.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "AB755D26-97F4-43B6-8604-CD076811E181", "versionEndExcluding": "6.11.2", "versionStartIncluding": "6.11"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}