All articles

Linux / 18 Sep 2026 / 4 min read

timerfd Counts Expirations Through Descriptor I/O

A periodic timerfd does not require one userspace wakeup for every timer expiration. If several expirations occur before the descriptor is read, Linux accumulates them and returns the count in one 8-byte integer. That behavior makes timer state fit the same readiness model used for sockets, pipes, and other descriptors. It also gives delayed event loops explicit information about missed periods rather than collapsing several expirations into one notification. Expiration state becomes readable descriptor data timerfd_create() creates a timer object and returns a file descriptor referring to it. The selected clock defines the timer’s time base. Common choices include CLOCK_MONOTONIC, CLOCK_REALTIME, and CLOCK_BOOTTIME.

Linux timerfd

Software Engineering / 18 Sep 2026 / 5 min read

SO_REUSEPORT Moves Listener Distribution into Socket Selection

SO_REUSEPORT permits multiple Linux AF_INET or AF_INET6 sockets to bind the same local address and port when every member satisfies the reuse-port rules. For TCP listeners, this moves incoming connection distribution ahead of accept(): the kernel selects a listener from the reuse-port group, and that listener receives the connection on its accept queue. For UDP, selection determines which socket receives an incoming datagram. This is a different concurrency boundary from several threads sharing one listening file description. Each reuse-port member is a distinct socket, with its own descriptor, queues, polling state, and lifecycle.

Software Engineering Linux

Software Engineering / 18 Sep 2026 / 3 min read

signalfd Routes Pending Signals Through Descriptor I/O

A Linux signalfd becomes readable when a signal selected by its mask is pending for the reading context. A successful read(2) consumes pending signal state and returns one or more fixed-size signalfd_siginfo records. Signal handling can therefore enter a descriptor-driven event loop without turning asynchronous handlers into the primary dispatch mechanism. The descriptor mask does not block signals The mask passed to signalfd(2) selects signals that the descriptor can accept. It does not modify the calling thread’s signal mask. Normal use separately blocks those signals with sigprocmask(2) or pthread_sigmask(3) so their ordinary dispositions do not run before descriptor consumption.

Software Engineering Linux

Linux / 18 Sep 2026 / 5 min read

Seccomp User Notifications Delegate Selected System Calls to a Supervisor

A seccomp filter can stop a selected system call before execution and turn it into a request on a listener file descriptor. The calling thread remains blocked while a userspace supervisor examines the notification and returns a result. This creates a mediation boundary that is narrower than tracing every system call and more dynamic than encoding every decision directly in classic BPF. The mechanism is SECCOMP_RET_USER_NOTIF. A filter returns that action for operations that require external mediation. A filter installed with SECCOMP_FILTER_FLAG_NEW_LISTENER yields a listener file descriptor, and a supervisor uses seccomp notification ioctls on that descriptor.

Linux Seccomp

Cybersecurity / 18 Sep 2026 / 7 min read

Seccomp User Notification Moves Selected System Calls Behind a Supervisor Decision

A sandboxed process may need an operation that cannot be represented safely as a permanent seccomp allow rule. The operation can depend on runtime policy, external state, or a resource that only a more privileged component should inspect. Allowing the system call unconditionally widens the sandbox, while rejecting it removes required functionality. Linux seccomp user notification provides a mediation point for this case. A seccomp filter can return SECCOMP_RET_USER_NOTIF for selected calls. The kernel then blocks the triggering task and emits a notification through a listener file descriptor. A supervisor reads that notification and sends a response that determines the immediate disposition of the intercepted call.

Cybersecurity Linux Security

Cybersecurity / 18 Sep 2026 / 5 min read

Seccomp User Notification Delegates Syscall Execution Across a Privilege Boundary

A confined process can reach a syscall that the kernel would reject under its current credentials, while a separate supervisor has enough privilege to perform an equivalent operation safely on its behalf. Linux seccomp user notification creates a mediation channel for that arrangement: a filter can stop the calling thread, emit a notification to a listener, and wait for a userspace response. That mechanism is more precise than treating the supervisor as a general syscall proxy. The notification carries register-level syscall data and an identifier tied to the pending request. The supervisor can synthesize a return value, inject a file descriptor, or in selected cases tell the kernel to continue the original syscall. Each option places the trust boundary in a different location.

Cybersecurity Linux Security

Software Engineering / 18 Sep 2026 / 6 min read

seccomp User Notification Delegates Selected Syscalls to a Supervisor

seccomp User Notification Delegates Selected Syscalls to a Supervisor A seccomp filter can stop a selected system call before the kernel executes it and emit a notification to a user-space supervisor instead. The target thread remains blocked while the supervisor receives the event and returns a disposition. This behavior turns a filter result into a controlled handoff across the kernel/user-space boundary. The mechanism is SECCOMP_RET_USER_NOTIF. It differs from ordinary seccomp actions because the BPF filter does not finish the decision by itself. A listener file descriptor becomes the coordination point for notification receipt, response delivery, and optional file-descriptor injection.

Linux seccomp

Software Engineering / 18 Sep 2026 / 6 min read

SCM_RIGHTS Transfers Open File Descriptions Across Process Boundaries

SCM_RIGHTS lets one process send a reference to an open file through a Unix domain socket. The receiver obtains a file descriptor in its own descriptor table, but the transfer does not reopen the pathname or copy the kernel object. On Linux, the resulting reference has semantics equivalent to duplicating the sender’s descriptor into the receiving process. That distinction matters whenever a process boundary is also an authority boundary. A supervisor can open a socket, file, pipe, device, or other descriptor-backed object and pass the established reference to a worker. The worker receives access to the already-open object, including open-file state that can remain shared with the sender.

Software Engineering Linux

Artificial Intelligence / 18 Sep 2026 / 5 min read

Recompute BatchNorm Statistics After Weight Averaging

Averaging two neural-network checkpoints can produce a useful parameter vector, yet leave BatchNorm running statistics tied to a different network. The weights define one set of activations; the stored running means and variances may describe activations produced by earlier weights. Inference then combines state from two different points in parameter space. This mismatch is easy to miss because BatchNorm running statistics are buffers rather than trainable parameters in common implementations. A parameter-averaging routine can handle every weight correctly and still produce an internally inconsistent inference state.

Artificial Intelligence Neural Networks

Cybersecurity / 18 Sep 2026 / 6 min read

process_vm_readv Crosses Process Memory Behind ptrace Access Checks

A diagnostic agent may need bytes from another process without stopping that process or attaching a traditional debugger. Linux process_vm_readv() provides that data path: the caller supplies local buffers and address ranges in a target process, and the kernel transfers bytes between the two address spaces. The interface is powerful because the target does not explicitly send the data. Its security boundary therefore sits outside the target’s application protocol. Linux gates the operation with a ptrace access-mode check, while the memory transfer itself remains subject to the target’s changing virtual-memory layout.

Cybersecurity Linux Security

Linux / 18 Sep 2026 / 4 min read

process_madvise Applies Memory Reclaim Advice Across Process Boundaries

process_madvise() can make one Linux process request memory-management action for virtual-address ranges owned by another process. The target is identified by a pidfd, while an iovec array names the target ranges. This separates memory-policy decisions from the process whose mappings receive the advice. The interface is useful for controllers that already have external knowledge about workload state. A runtime manager can mark inactive memory cold or request page reclamation without injecting code into the managed process. That capability is bounded by permission checks, supported advice values, and partial-progress semantics.

Linux Memory Management

Cybersecurity / 18 Sep 2026 / 5 min read

PR_SET_DUMPABLE Changes Linux Process Inspection Boundaries

A service receives credentials into process memory, drops privileges, and continues running under an ordinary account. Another same-account process may still be able to inspect it through interfaces intended for debugging. Linux places an additional process attribute, commonly called dumpable, into several of these access decisions. prctl(PR_SET_DUMPABLE, 0) marks the calling process non-dumpable. The effect is broader than suppressing a core file: Linux also incorporates dumpable state into ptrace access checks and changes ownership behavior for files under /proc/<pid>. These effects form related boundaries, but they are not a single universal ban on process observation.

Cybersecurity Linux Security

Software Engineering / 18 Sep 2026 / 4 min read

pidfds Bind Process Operations to Stable Kernel References

A numeric PID names a process only while that PID remains assigned to it. After termination and reaping, Linux can reuse the number for another process. A PID file descriptor, or pidfd, instead holds a kernel reference to a specific task, so later operations can target that task without resolving its numeric PID again. This distinction removes a class of time-of-check/time-of-use races from process management. It does not make a process immortal, grant extra permissions, or turn every process operation into a portable descriptor API.

Software Engineering Linux

Cybersecurity / 18 Sep 2026 / 6 min read

pidfds Bind Process Operations to Stable Kernel References

A supervisor records PID 4127, performs unrelated work, then sends a signal to 4127. Between those steps, the original process can exit and the kernel can eventually assign the same numeric PID to another process. The integer still names a process, but not necessarily the process that the supervisor intended to affect. Linux PID file descriptors, commonly called pidfds, move that boundary from repeated numeric lookup to a file descriptor that refers to a particular task. That change is narrow but security-relevant: operations that accept a pidfd can stay bound to the task selected when the reference was acquired rather than resolving a reusable number again.

Cybersecurity Linux

Linux / 18 Sep 2026 / 6 min read

pidfd_getfd Duplicates Another Process File Descriptor into the Caller

A file descriptor number has meaning only inside its process descriptor table, but the kernel object behind that number can be shared across processes. Linux pidfd_getfd() bridges those two scopes: it takes a PID file descriptor plus a descriptor number from the referenced process and installs a duplicate descriptor in the caller. The new descriptor refers to the same open file description as the target descriptor. That last property is the central boundary. pidfd_getfd() does not reopen a pathname, copy bytes, or create an independent file position. It duplicates an existing kernel reference and therefore inherits sharing semantics that can affect both processes.

Software Engineering Linux

Cybersecurity / 18 Sep 2026 / 6 min read

Pidfd Process References Separate Identity from Numeric PIDs

A supervisor records a worker PID, performs unrelated work, then sends a signal to that number. If the original worker exited and the kernel reused its numeric PID, a later operation can address a different process. The number identifies an entry in a PID namespace at a moment in time; it is not, by itself, a durable process handle. Linux pidfds add a file-descriptor representation of process identity. A pidfd obtained for a process continues to refer to that process rather than being retargeted when its numeric PID is recycled. This changes the identity boundary for supervision, but it does not grant broad authority over the referenced process.

Cybersecurity Linux Security

Cybersecurity / 18 Sep 2026 / 7 min read

OverlayFS Stashed Credentials Separate Overlay Access from Backing Filesystem Access

OverlayFS Stashed Credentials Separate Overlay Access from Backing Filesystem Access A process opens a path through an OverlayFS mount and appears to access one ordinary filesystem object. The kernel may actually consult an upper layer, a lower layer, or both, and a write can trigger copy-up before the requested operation proceeds. That indirection creates an authorization problem: the caller must be permitted to use the object as exposed by the overlay, while the internal access to the backing filesystems must also run under a defined security identity.

Cybersecurity Linux Security

Linux / 18 Sep 2026 / 5 min read

openat2 Resolve Flags Constrain Path Traversal per Open

A pathname passed to openat2() can be rejected even when the same pathname would resolve successfully through openat(). The difference comes from open_how.resolve: Linux can apply traversal constraints while resolving every component of that single open operation. This changes the boundary around path handling. A directory file descriptor can act as more than a starting point; resolve flags can restrict escapes, symbolic-link traversal, mount crossings, and lookups that require work beyond cached state.

Linux System Calls

Cybersecurity / 18 Sep 2026 / 5 min read

openat2 Resolution Flags Constrain Path Traversal at the Kernel Boundary

A service can validate a pathname and still open a different object if the namespace changes between validation and use. Symbolic links, mount topology, rename operations, and special procfs links make pathname resolution a kernel operation with state that can change concurrently. Linux openat2() addresses part of this boundary by attaching resolution constraints to the lookup that produces the file descriptor. The security property is narrower than generic path sanitization. openat2() does not declare a pathname safe. It lets a caller ask the kernel to reject specific resolution behavior while the kernel performs the walk.

Software Engineering Linux

Cybersecurity / 18 Sep 2026 / 6 min read

openat2 Makes Path Resolution an Explicit Security Boundary

A privileged service may accept a relative pathname from a less trusted component while intending to access only files below a designated directory. Checking the string for .., rejecting an initial slash, or inspecting symbolic links before a later open() does not bind the check to the kernel lookup that acquires the file. Directory entries can change between operations, symbolic links can redirect traversal, and mount topology can alter the namespace reached by a path.

Cybersecurity Linux Security

Software Engineering / 18 Sep 2026 / 5 min read

openat2 Constrains Path Resolution Inside a Directory Boundary

A pathname is not a stable object reference. Between its starting directory and final component, Linux path resolution may follow symbolic links, cross mount points, process .., or encounter special links exposed by pseudo-filesystems. openat2() lets a caller attach constraints to that resolution operation so the kernel can reject a lookup that leaves the intended boundary. The distinction is stronger than checking a normalized string before open(). String validation examines syntax. openat2() can constrain the kernel’s actual traversal while filesystem objects and mount topology participate in the lookup.

Software Engineering Linux

Linux / 18 Sep 2026 / 5 min read

mseal Locks Memory Mapping Layout and Permissions

A process can establish a memory mapping with the intended address, size, and protection bits, then later alter that mapping with operations such as munmap(), mprotect(), or mremap(). Linux mseal() adds a one-way state transition: selected virtual memory areas can be sealed so a class of later mapping modifications is rejected by the kernel. The mechanism protects mapping structure rather than the bytes stored in the mapping. A writable sealed mapping remains writable through ordinary stores. Sealing instead constrains operations that could remove the mapping, relocate it, replace it, or change attributes covered by the sealing rules.

Linux Memory Management

Cybersecurity / 18 Sep 2026 / 6 min read

Mount Propagation Defines the Filesystem Boundary Between Linux Mount Namespaces

A process can enter a new Linux mount namespace and still observe a later mount created elsewhere. The namespace boundary is intact: the process has its own mount table. The new mount appears because some mounts in the two namespaces remain connected by propagation relationships. This distinction matters in container runtimes, service sandboxes, build systems, and privileged helpers. Creating a mount namespace separates the namespace’s view of the mount table, but it does not by itself make every future mount event local. Shared-subtree state determines whether mount and unmount events cross that boundary.

Cybersecurity Linux Security

Software Engineering / 18 Sep 2026 / 4 min read

memfd Seals Turn Shared File State into Monotonic Restrictions

A memfd_create() file can begin as writable shared state and later become progressively more constrained. File seals make that transition monotonic: successful seals are properties of the inode, affect every descriptor referring to it, and cannot be removed. That property is useful when one process prepares bytes and then transfers a descriptor to another process. The receiver can inspect kernel-enforced restrictions instead of relying only on a protocol promise that the producer has stopped changing the object.

Software Engineering Linux