Zephyr Project up to 4.4.2 Syscall Verifier rtio_syscalls.c z_vrfy_rtio_cqe_get_mempool_buffer buff/buff_len permission
| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 5.1 | $0-$5k | 6.76- |
Summary
A vulnerability marked as problematic has been reported in Zephyr Project Zephyr up to 4.4.2. This affects the function z_vrfy_rtio_cqe_get_mempool_buffer of the file subsys/rtio/rtio_syscalls.c of the component Syscall Verifier. The manipulation of the argument buff/buff_len leads to permission.
This vulnerability is listed as CVE-2026-19595. The attack must be carried out locally. There is no available exploit.
Applying a patch is the recommended action to fix this issue.
Details
A vulnerability was found in Zephyr Project Zephyr up to 4.4.2 and classified as problematic. This issue affects the function z_vrfy_rtio_cqe_get_mempool_buffer of the file subsys/rtio/rtio_syscalls.c of the component Syscall Verifier. The manipulation of the argument buff/buff_len with an unknown input leads to a permission vulnerability. Using CWE to declare the problem leads to CWE-275. Impacted is integrity, and availability. The summary by CVE is:
The user-mode syscall verifier z_vrfy_rtio_cqe_get_mempool_buffer() in subsys/rtio/rtio_syscalls.c validated its two output parameters, buff and buff_len, with K_SYSCALL_MEMORY_READ() rather than K_SYSCALL_MEMORY_WRITE(). Both are pure out-parameters: z_impl_rtio_cqe_get_mempool_buffer() stores the mempool buffer address and its length through them. The distinction is enforced by every architecture validator — arch_buffer_validate() on RISC-V PMP explicitly accepts the global __rom_region/__rodata_region for reads only, and the ARM MPU validators accept P_RO_U_RO and P_RW_U_RO regions for reads only — so a read-validated pointer is not necessarily writable by the calling thread. An unprivileged user-mode thread that has been granted access to an RTIO context (rtio_access_grant()) can invoke the rtio_cqe_get_mempool_buffer() syscall with buff/buff_len pointing at memory it may read but not write, and with a completion-queue entry whose flags field it fully controls (only RTIO_CQE_FLAG_MEMPOOL_BUFFER in flags[7:0] is required; flags[19:8] and flags[31:20] supply the block index and count). The kernel then performs a pointer-sized and a 4-byte store through those addresses while running in supervisor mode. Reaching the store requires CONFIG_USERSPACE together with CONFIG_RTIO_SYS_MEM_BLOCKS, the configuration behind RTIO_DEFINE_WITH_MEMPOOL; without the latter the implementation returns -ENOTSUP and writes nothing. Two outcomes follow. If the target lies in a memory-domain partition declared K_MEM_PARTITION_P_RW_U_RO (privileged read-write, user read-only), the kernel-mode store succeeds and deposits partly attacker-chosen values into memory the memory domain had marked read-only for that thread, bypassing the partition's write protection. If the target lies in globally readable but unwritable memory such as .text/.rodata in flash, the store faults in kernel mode; the fault is delivered to z_fatal_error() and the default k_sys_fatal_error_handler() halts or reboots the device, giving an unprivileged thread a reliable full denial of service. The read-permission check does bound the damage: the address must still be readable by the calling thread, so kernel-private memory cannot be targeted and no confidential data is disclosed. The fix replaces both checks with K_SYSCALL_MEMORY_WRITE(), so a thread lacking write permission is terminated by K_OOPS before the implementation runs; the cqe argument correctly remains read-validated.
The advisory is shared at github.com. The identification of this vulnerability is CVE-2026-19595 since 08/12/2026. The exploitation is known to be easy. An attack has to be approached locally. Technical details are known, but no exploit is available. MITRE ATT&CK project uses the attack technique T1222 for this issue.
Applying the patch bea93400138362691403b7f81de1e9048681547d is able to eliminate this problem.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Product
Type
Vendor
Name
Version
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 5.2VulDB Meta Temp Score: 5.1
VulDB Base Score: 4.4
VulDB Temp Score: 4.2
VulDB Vector: 🔒
VulDB Reliability: 🔍
CNA Base Score: 6.1
CNA Vector (zephyr): 🔒
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: PermissionCWE: CWE-275 / CWE-266
CAPEC: 🔒
ATT&CK: 🔒
Physical: Partially
Local: Yes
Remote: No
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: PatchStatus: 🔍
0-Day Time: 🔒
Patch: bea93400138362691403b7f81de1e9048681547d
Timeline
08/12/2026 CVE reserved10/19/2026 VulDB entry created
10/20/2026 Advisory disclosed
10/20/2026 VulDB entry last update
Sources
Advisory: github.comStatus: Confirmed
CVE: CVE-2026-19595 (🔒)
GCVE (CVE): GCVE-0-2026-19595
GCVE (VulDB): GCVE-100-422573
Entry
Created: 10/20/2026 01:14Changes: 10/20/2026 01:14 (68)
Complete: 🔍
Cache ID: 216::103
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
No comments yet. Languages: en.
Please log in to comment.