CVE-2023-6881 is a high severity (CVSS 7.3) buffer overflow in the is_mount_point function of Zephyr RTOS, in the FUSE file system access code. The advisory lists Zephyr 3.5 and earlier as affected with no patched release. Check the advisory for a fix and avoid the affected code path.
What's affected
The Zephyr GitHub advisory GHSA-mh67-4h3q-p437 lists affected versions as 3.5 and earlier and patched versions as none at the time of reading. It points to a pull request on the main branch (#66592) and an embargo date of 2024-02-20.
The affected function lives in the file system access code in the FUSE based file system support (fuse_fs_access.c), If your products do not build that code, exposure is low. Confirm that against your own build.
How to check if you're exposed
Check whether your build uses the FUSE file system access code and which Zephyr tree you build against.
cat $ZEPHYR_BASE/VERSION
grep -r "fuse_fs_access" build/ 2>/dev/null | head
If the file never appears in your build output, the affected function is not compiled into your image.
What to do now
- Confirm whether the FUSE file system access code is part of any production build.
- Track the upstream fix in the pull request named in the advisory and update when a release carries it.
- Treat native simulator builds as development tools and keep them off exposed hosts.
- Record the Zephyr version for each product in your inventory.
- Run your dependency manifests and images through the free in-browser scan at gold.safeguard.sh/scan, and use reachability analysis to see whether the affected code is actually used in your build.
Why it matters
The advisory explains that when the path string is exactly PATH_MAX long, sprintf writes one byte past the end of the dir_path buffer. The record tags CWE-120, buffer copy without checking size of input, a classic overflow.
Memory safety bugs like this one come from code that trusts a length it never verified. In C and C++ the compiler will not stop a write past the end of a buffer, so the check has to be written by hand and has to be right on every path. This one is a single byte, but off-by-one writes can still corrupt adjacent data, and the right fix is to use a bounded copy such as snprintf.
Firmware and engineering software update slowly. Start with an inventory of what you run and where it connects. Network isolation buys time while you test and schedule updates, and it is usually the first measure vendors recommend. Give each exception an owner and a review date so the workaround does not become permanent.
Weakness class in the record: CWE-120 (Classic Buffer Overflow).
Quick check
Does this affect real hardware?
That depends on whether your build includes the FUSE based file system access code, which the advisory ties to a simulator-style environment. Check your build, and do not assume either way.
What if we cannot patch quickly?
Reduce who and what can reach the device. Segment the network, restrict management access to a known host, and record the exception with an owner and a review date.
Sources
Last reviewed: 19 October 2026.
