Zephyr OS Syscall Verifiers: Validate a Stable Copy of User-Controlled Parameters

Checking that a userspace pointer is readable does not make the pointed-to contents stable. Another permitted thread can change shared memory between a verifier's check and the implementation's use. For control parameters, the privileged side needs a validated snapshot rather than repeated reads of user-controlled state.

This article uses Zephyr 4.4.0's syscall guidance and verifier helpers. It focuses on designing an application-specific privilege boundary, distinct from diagnosing a missing kernel-object permission. It provides no exploit procedure or claim of a vulnerability in a particular product.

Identify control data before writing checks

Classify each parameter by how the privileged implementation uses it. A length, index, mode, or nested pointer influences control flow and memory access. A large payload that is only copied or transmitted may have different handling requirements. Input/output parameters need both an initial value and a controlled way to return the result.

The tagged syscall documentation assigns argument validation to the verifier and discusses changes to by-reference parameters during a call. Its recommended approach for control data is to copy into privileged storage, validate the copy, and pass that copy onward.

Do not validate a field in the user structure and then hand the original structure to code that reads the same field again. The second read is a separate observation and may no longer match the checked value.

Follow pointers through the structure

Copying an outer structure does not automatically copy data reached through its pointers. Draw the parameter graph: outer request, nested descriptors, array elements, and payload regions. For each edge, decide what must be copied, what bounds must be checked, and which storage remains user-controlled.

A hypothetical request might contain an element count and a pointer to an array of descriptors. A stable copy of the outer count is useful, but the descriptor array can still contain mutable lengths or pointers. The verifier needs a coherent policy for the complete control structure, not one initial pointer check.

Bound the total work and memory required before allocating copies. A valid accessible array can still be too large for the service's intended resource budget. Access validity and acceptable request size answer different questions.

Check arithmetic before checking the resulting range

The tagged syscall helper definitions include array-memory checks that detect multiplication overflow before validating the computed range. This matters when an element count and element size become a byte length.

A wrapped byte count can make a small range appear valid while later code processes many more elements. Use the release's intended verifier helpers and inspect their conventions; they are internal facilities for extending Zephyr functionality, not general application APIs to scatter through unrelated code.

Apply the same scrutiny to additions, offsets, and conversions used by the implementation. A pointer's initial accessibility does not prove that a later calculated subrange is valid.

Keep output handling under the same contract

For a small output or input/output value, keep the privileged working value separate and copy the final result back through the appropriate checked path. Avoid allowing shared output storage to become a hidden control variable that another thread can modify while privileged code is running.

Define what the caller can observe when an operation fails. Does the API leave output unchanged, return a partial count, or provide a separately marked result? That decision should be part of the API contract rather than an accidental consequence of how many writes occurred before failure.

The official guidance makes a limited distinction for large buffers whose contents are not used for validation or control flow. Do not generalize that exception to structures containing counts, pointers, or operating modes.

Exercise the verifier from user mode

A supervisor call can reach the implementation without the same validation path. Test the intended user-mode entry with valid inputs, inaccessible ranges, oversized counts, and controlled concurrent changes to shared request storage. Use a harness that expects fault handling where applicable; invalid syscall arguments are not guaranteed to behave like ordinary recoverable application errors.

Keep the test's purpose defensive: demonstrate that the implementation acts only on the validated request snapshot and rejects invalid boundaries. A successful normal request alone does not establish that property.

A well-defined verifier leaves the privileged implementation with a bounded, stable set of parameters and an explicit output policy. That is the useful review target, rather than the number of pointer-check macros present in the source.