Linux Kernel hasta 6.1.78/6.6.14/6.7.2/6.8-rc1 nfsd nfsd4_release_lockowner escalada de privilegios

CVSS Puntuación meta temporalPrecio actual del exploit (≈)Puntuación de interés CTI
5.4$0-$5k0.00

Resumeninformación

Se ha identificado una vulnerabilidad clasificada como problemática en Linux Kernel hasta 6.1.78/6.6.14/6.7.2/6.8-rc1. Está afectada una función desconocida en el componente nfsd. Mediante la manipulación de un input desconocido se causa una vulnerabilidad de clase escalada de privilegios. Esta vulnerabilidad está identificada como CVE-2024-26629. No existe ningún exploit disponible. Es recomendable actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad clasificada como problemática ha sido encontrada en Linux Kernel hasta 6.1.78/6.6.14/6.7.2/6.8-rc1 (Operating System). La función nfsd4_release_lockowner del componente nfsd es afectada por esta vulnerabilidad. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase escalada de privilegios. Los efectos exactos de un ataque con éxito no son conocidos. CVE resume:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: arreglar RELEASE_LOCKOWNER La prueba en so_count en nfsd4_release_lockowner() no tiene sentido y es dañina. Vuelva a usar check_for_locks(), cambiándolo para no dormir. Primero: dañino. Como se documenta en el comentario de kdoc para nfsd4_release_lockowner(), la prueba en so_count puede devolver transitoriamente un falso positivo, lo que resulta en una devolución de NFS4ERR_LOCKS_HELD cuando en realidad no se mantienen bloqueos. Esto es claramente una violación del protocolo y con el cliente NFS de Linux puede provocar un comportamiento incorrecto. Si se envía RELEASE_LOCKOWNER mientras algún otro subproceso todavía está procesando una solicitud de LOCK que falló porque, en el momento en que se recibió esa solicitud, el propietario determinado tenía un bloqueo en conflicto, entonces el subproceso nfsd que procesa esa solicitud de LOCK puede contener una referencia (conflock) a el propietario del bloqueo que hace que nfsd4_release_lockowner() devuelva un error incorrecto. El cliente NFS de Linux ignora ese error NFS4ERR_LOCKS_HELD porque nunca envía NFS4_RELEASE_LOCKOWNER sin liberar primero ningún bloqueo, por lo que sabe que el error es imposible. Se supone que el propietario de la cerradura fue liberado, por lo que puede utilizar el mismo identificador de propietario de la cerradura en alguna solicitud de bloqueo posterior. Cuando reutiliza un identificador de propietario de bloqueo para el cual falló una RELEASE anterior, naturalmente usará un lock_seqid de cero. Sin embargo, el servidor, que no liberó al propietario del bloqueo, esperará un lock_seqid mayor y, por lo tanto, responderá con NFS4ERR_BAD_SEQID. Claramente es perjudicial permitir un falso positivo, lo que permite la prueba so_count. La prueba es una tontería porque... bueno... no significa nada. so_count es la suma de tres recuentos diferentes. 1/ el conjunto de estados enumerados en so_stateids 2/ el conjunto de bloqueos vfs activos propiedad de cualquiera de esos estados 3/ varios recuentos transitorios, como bloqueos en conflicto. Cuando se prueba con '2', queda claro que una de ellas es la referencia transitoria obtenida por find_lockowner_str_locked(). No está claro cuál se espera que sea el otro. En la práctica, el recuento suele ser 2 porque hay precisamente un estado en so_stateids. Si hubiera más, esto fracasaría. En mis pruebas veo dos circunstancias en las que se llama a RELEASE_LOCKOWNER. En un caso, se llama a CLOSE antes de RELEASE_LOCKOWNER. Eso da como resultado que se eliminen todos los estados de bloqueo y, por lo tanto, se descarte el propietario de la cerradura (se elimina cuando no hay más referencias, lo que generalmente sucede cuando se descarta el estado de bloqueo). Cuando nfsd4_release_lockowner() descubre que el propietario del bloqueo no existe, devuelve éxito. El otro caso muestra un so_count de '2' y precisamente un estado listado en so_stateid. Parece que el cliente Linux utiliza un propietario de bloqueo independiente para cada archivo, lo que da como resultado un estado de bloqueo por propietario de bloqueo, por lo que esta prueba en '2' es segura. Para otro cliente puede que no sea seguro. Entonces, este parche cambia check_for_locks() para usar el (nuevo) find_any_file_locked() para que no tome una referencia en nfs4_file y así nunca llame a nfsd_file_put(), y por lo tanto nunca duerma. Con esta verificación, es seguro restaurar el uso de check_for_locks() en lugar de probar so_count con el misterioso '2'.

La vulnerabilidad fue publicada el 2024-03-13 (confirmado). El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2024-26629. Hay detalles técnicos conocidos, pero no se dispone de un exploit.

Para el scanner Nessus se dispone de un plugin ID 237278 (Alibaba Cloud Linux 3 : 0075: cloud-kernel bugfix, enhancement and (ALINUX3-SA-2025:0075)), que puede ayudar a determinar la existencia del riesgo analizado.

Una actualización a la versión 6.1.79, 6.6.15, 6.7.3 o 6.8-rc2 elimina esta vulnerabilidad. Aplicando el parche e4cf8941664c/b7d2eee1f538/8f5b860de870/edcf9725150e es posible eliminar el problema. El parche puede ser descargado de git.kernel.org. El mejor modo sugerido para mitigar el problema es Actualización.

La vulnerabilidad también está documentado en la base de datos Tenable (237278). Once again VulDB remains the best source for vulnerability data.

Productoinformación

Escribe

Proveedor

Nombre

Versión

Licencia

Sitio web

CPE 2.3información

CPE 2.2información

CVSSv4información

VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CVSSv3información

VulDB Puntuación meta base: 5.5
VulDB Puntuación meta temporal: 5.4

VulDB Puntuación base: 5.5
VulDB Puntuación temporal: 5.3
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 5.5
NVD Vector: 🔍

CVSSv2información

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplejidadAutenticaciónConfidencialidadIntegridadDisponibilidad
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear

VulDB Puntuación base: 🔍
VulDB Puntuación temporal: 🔍
VulDB Confiabilidad: 🔍

Explotacióninformación

Clase: Escalada de privilegios
CWE: CWE-371
CAPEC: 🔍
ATT&CK: 🔍

Físico: En parte
Local: Sí
Remoto: En parte

Disponibilidad: 🔍
Estado: No está definido

EPSS Score: 🔍
EPSS Percentile: 🔍

Predicción de precios: 🔍
Estimación del precio actual: 🔍

0-DayDesbloquearDesbloquearDesbloquearDesbloquear
HoyDesbloquearDesbloquearDesbloquearDesbloquear

Nessus ID: 237278
Nessus Nombre: Alibaba Cloud Linux 3 : 0075: cloud-kernel bugfix, enhancement and (ALINUX3-SA-2025:0075)

Inteligencia de amenazasinformación

Interés: 🔍
Actores activos: 🔍
Grupos APT activos: 🔍

Contramedidasinformación

Recomendación: Actualización
Estado: 🔍

Hora de 0 días: 🔍

Actualización: Kernel 6.1.79/6.6.15/6.7.3/6.8-rc2
Parche: e4cf8941664c/b7d2eee1f538/8f5b860de870/edcf9725150e

Línea de tiempoinformación

2024-02-19 🔍
2024-03-13 +23 días 🔍
2024-03-13 +0 días 🔍
2025-05-27 +440 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2024-26629 (🔍)
GCVE (CVE): GCVE-0-2024-26629
GCVE (VulDB): GCVE-100-256716

Artículoinformación

Fecha de creación: 2024-03-13 15:42
Actualizado: 2025-05-27 13:43
Cambios: 2024-03-13 15:42 (43), 2024-06-11 13:10 (15), 2025-02-27 04:32 (11), 2025-05-27 13:43 (2)
Completo: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Discusión

Sin comentarios aún. Idiomas: es + pt + en.

Por favor, inicie sesión para comentar.

◂ AnteriorVisión De ConjuntoPróximo ▸

Interested in the pricing of exploits?

See the underground prices here!