OpenBSD NFS memory-safety flaws: mbuf double free and uninitialized variable

In OpenBSD 7.5 before errata 008 and OpenBSD 7.4 before errata 021, avoid possible mbuf double free in NFS client and server implementation, do not use uninitialized variable in error handling of NFS server.

• OpenBSD 7.5: affected before errata 008; errata 008 contains the fix for this NFS issue.
• OpenBSD 7.4: affected before errata 021; errata 021 contains the fix for this NFS issue.
• The normalized record does not establish the default status outside these branches. Do not infer that other OpenBSD branches are fixed or unaffected without branch-specific evidence.

The flaw is in the OpenBSD kernel implementation of NFS. Certain retry and error paths can call m_freem on an mbuf and retain the old pointer, creating a possible double-free; the patch clears the pointer after freeing it in the relevant paths. The patch also changes the NFS server name-size error handling macro to set the value to 0 before returning an error response, preventing use of an uninitialized variable. The input that can reach these paths is NFS traffic processed by the client or server, consistent with the network-reachable characteristics recorded for the issue. The specific malformed request sequence needed to trigger each path is not established by the available evidence.

The record characterizes the issue as network-reachable, low-complexity, requiring no special privileges and no user interaction. Authentication or prior access is recorded as not required. The assessment also contains an additional attack precondition, but the supplied evidence does not explain what that condition is. The normalized record marks public exploit as false and does not identify known exploitation; this does not prove that exploitation has never occurred in the wild.

A double free can cause kernel memory corruption, a crash or undefined behavior; these are possible outcomes, not a demonstrated exploit path in the record. Use of an uninitialized variable in NFS server error handling can produce incorrect error processing and contribute to unsafe behavior. The supplied assessment indicates potential impact to confidentiality, integrity and availability. Organisational consequences may include interrupted file services, loss of NFS data access or recovery work for affected hosts. The available evidence does not confirm arbitrary code execution, kernel takeover, data disclosure or a specific breach.

A successful attack could corrupt kernel memory and disrupt an NFS client or server. Systems that depend on NFS could lose file access, interrupt workloads or require service recovery after a kernel failure. The supplied assessment indicates potential effects on confidentiality, integrity and availability, but it does not establish that data was accessed, modified or exfiltrated, or that a breach occurred. The practical consequence therefore depends on whether an attacker can control the affected error paths and on the role of NFS in the environment.

1. On OpenBSD 7.5, apply errata 008. On OpenBSD 7.4, apply errata 021.
2. Use the signed patch for the applicable branch and verify it with openbsd-75-base.pub or openbsd-74-base.pub as directed by OpenBSD.
3. After applying the patch, rebuild and install a new kernel according to the OpenBSD procedure, then verify that the running kernel is the updated build.
4. Test both NFS client and NFS server operation after updating, especially on systems supporting important workloads.
5. The available evidence does not provide a validated workaround. If updating is delayed, treat the affected NFS systems as exposed and minimize the time they remain unpatched.

1. Inventory OpenBSD systems that use the NFS client or provide the NFS server.
2. Check the release, kernel update records and errata status for each host; seeing NFS enabled does not show that the system is patched.
3. For source-based builds, inspect build provenance or the source tree to confirm that the changes to sys/nfs/nfs_socket.c and sys/nfs/nfsm_subs.h are included in the running kernel.
4. Review kernel panics, crashes or unexpected restarts affecting NFS systems as supplementary detection signals. These are generic monitoring indicators, not issue-specific indicators of compromise.
5. No confirmed log event, IOC or request pattern is provided. Absence of those signs does not demonstrate that a system is safe.