CVE-2026-10669
Full vulnerability record from the local CVENow database.
Description
On Xtensa SoCs built with CONFIG_XTENSA_MPU and CONFIG_USERSPACE, arch_buffer_validate() in arch/xtensa/core/mpu.c — the architecture hook that verifies a user-mode-supplied buffer is accessible to the calling user thread with the requested permission — defaulted its return value to 0 (access permitted) and only set a denial result inside its per-MPU-region probe loop. When the rounded extent of the buffer wraps the 32-bit address space (size + alignment offset near SIZE_MAX, or ROUND_UP(size + offset) overflowing to 0), the loop executes zero iterations and the function returns 0 = permitted without probing any MPU region. The syscall-layer pre-checks (K_SYSCALL_MEMORY_SIZE_CHECK / Z_DETECT_POINTER_OVERFLOW) only catch a raw addr+size wrap and do not cover the ROUND_UP-induced wrap, and the string path (arch_user_string_nlen -> arch_buffer_validate) has no syscall-layer guard at all. An unprivileged user-mode thread can therefore pass a crafted (addr, size) to any syscall that validates user buffers via k_usermode_from_copy/to_copy or k_usermode_string_copy and have validation succeed for memory it must not access; the kernel then reads from (disclosure) or, with write=1, writes to (corruption) attacker-chosen kernel or other-partition memory on the thread's behalf, enabling information disclosure, memory corruption, privilege escalation, and denial of service. Affected from v3.7.0 (when Xtensa MPU userspace support was added) through v4.4.0. The fix changes the default to -EINVAL (deny by default), adds an explicit size_add_overflow check, and sets the success value only after the full range has been validated.
View original CVE JSON
{
"id": "CVE-2026-10669",
"sourceIdentifier": "[email protected]",
"published": "2026-07-14T15:16:55.210",
"lastModified": "2026-10-24T21:10:00.130",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "On Xtensa SoCs built with CONFIG_XTENSA_MPU and CONFIG_USERSPACE, arch_buffer_validate() in arch/xtensa/core/mpu.c — the architecture hook that verifies a user-mode-supplied buffer is accessible to the calling user thread with the requested permission — defaulted its return value to 0 (access permitted) and only set a denial result inside its per-MPU-region probe loop. When the rounded extent of the buffer wraps the 32-bit address space (size + alignment offset near SIZE_MAX, or ROUND_UP(size + offset) overflowing to 0), the loop executes zero iterations and the function returns 0 = permitted without probing any MPU region.\n\nThe syscall-layer pre-checks (K_SYSCALL_MEMORY_SIZE_CHECK / Z_DETECT_POINTER_OVERFLOW) only catch a raw addr+size wrap and do not cover the ROUND_UP-induced wrap, and the string path (arch_user_string_nlen -> arch_buffer_validate) has no syscall-layer guard at all.\n\nAn unprivileged user-mode thread can therefore pass a crafted (addr, size) to any syscall that validates user buffers via k_usermode_from_copy/to_copy or k_usermode_string_copy and have validation succeed for memory it must not access; the kernel then reads from (disclosure) or, with write=1, writes to (corruption) attacker-chosen kernel or other-partition memory on the thread's behalf, enabling information disclosure, memory corruption, privilege escalation, and denial of service.\n\nAffected from v3.7.0 (when Xtensa MPU userspace support was added) through v4.4.0. The fix changes the default to -EINVAL (deny by default), adds an explicit size_add_overflow check, and sets the success value only after the full range has been validated."
},
{
"lang": "es",
"value": "En SoCs Xtensa construidos con CONFIG_XTENSA_MPU y CONFIG_USERSPACE, arch_buffer_validate() en arch/xtensa/core/mpu.c - el ’hook’ de arquitectura que verifica que un búfer proporcionado por el modo de usuario sea accesible para el hilo de usuario llamante con el permiso solicitado - establecía por defecto su valor de retorno en 0 (acceso permitido) y solo establecía un resultado de denegación dentro de su bucle de sondeo por región MPU. Cuando la extensión redondeada del búfer envuelve el espacio de direcciones de 32 bits (size + desplazamiento de alineación cerca de SIZE_MAX, o ROUND_UP(size + offset) desbordándose a 0), el bucle ejecuta cero iteraciones y la función devuelve 0 = permitido sin sondear ninguna región MPU.\n\nLas comprobaciones previas de la capa de llamadas al sistema (K_SYSCALL_MEMORY_SIZE_CHECK / Z_DETECT_POINTER_OVERFLOW) solo detectan un ’wrap’ de addr+size en bruto y no cubren el ’wrap’ inducido por ROUND_UP, y la ruta de cadena (arch_user_string_nlen -> arch_buffer_validate) no tiene ninguna protección a nivel de capa de llamadas al sistema.\n\nUn hilo de modo de usuario sin privilegios puede, por lo tanto, pasar un (addr, size) manipulado a cualquier llamada al sistema que valide búferes de usuario a través de k_usermode_from_copy/to_copy o k_usermode_string_copy y lograr que la validación tenga éxito para memoria a la que no debe acceder; el kernel entonces lee de (revelación) o, con write=1, escribe en (corrupción) memoria del kernel o de otra partición elegida por el atacante en nombre del hilo, lo que permite la revelación de información, la corrupción de memoria, la escalada de privilegios y la denegación de servicio.\n\nAfectado desde la v3.7.0 (cuando se añadió el soporte de espacio de usuario de Xtensa MPU) hasta la v4.4.0. La solución cambia el valor predeterminado a -EINVAL (denegar por defecto), añade una comprobación explícita de size_add_overflow y establece el valor de éxito solo después de que se haya validado el rango completo."
}
],
"affected": [
{
"source": "[email protected]",
"affectedData": [
{
"vendor": "zephyrproject",
"product": "zephyr",
"defaultStatus": "unaffected",
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
"packageName": "zephyr",
"programFiles": [
"arch/xtensa/core/mpu.c"
],
"versions": [
{
"version": "3.7.0",
"lessThan": "4.3.1",
"versionType": "semver",
"status": "affected"
},
{
"version": "4.4.0",
"lessThan": "4.4.1",
"versionType": "semver",
"status": "affected"
}
]
}
]
}
],
"metrics": {
"cvssMetricV31": [
{
"source": "[email protected]",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"attackVector": "LOCAL",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "UNCHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"timestamp": "2026-07-14T15:30:37.607534Z",
"id": "CVE-2026-10669",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"version": "2.0.3"
}
}
]
},
"weaknesses": [
{
"source": "[email protected]",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-787"
}
]
},
{
"source": "[email protected]",
"type": "Primary",
"description": [
{
"lang": "en",
"value": "CWE-190"
}
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:o:zephyrproject:zephyr:*:*:*:*:*:*:*:*",
"versionStartIncluding": "3.7.0",
"versionEndExcluding": "4.5.0",
"matchCriteriaId": "9F648F66-9415-47A6-92AD-4C61A70269B2"
}
]
}
]
}
],
"references": [
{
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/3b1bdaf5482188ca110ef9a411aaa8c7d3db3b16",
"source": "[email protected]",
"tags": [
"Patch"
]
},
{
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-4r4p-gh69-v6w4",
"source": "[email protected]",
"tags": [
"Exploit",
"Patch",
"Vendor Advisory"
]
}
]
}