Backport upstream fix for GHSA-cvmj-47v9-35m9 onto the bcff57c pin

[dflemstr]

Summary

Backports the single upstream commit that fixes GHSA-cvmj-47v9-35m9 onto fs/pin-bcff57c, the branch modal-labs/modal pins its fuser dependency to.

The advisory is an uninitialized memory read and leak inside libfuse.so: fuse_session_new was being passed a NULL operation list, where libfuse always expects a valid pointer. Upstream fixed it in cberner/fuser#390 (commit 47113e1), which defines fuse_lowlevel_ops and passes a zeroed instance instead of NULL.

This affects us: libfuse is fuser's default feature and is enabled in the modal-labs/modal build, so the vulnerable code path is live.

Why a backport instead of upgrading

modal-labs/modal previously tried to fix this advisory by moving from this fork to crates.io fuser 0.16.0 (modal#27252). It was reverted a day later (modal#27426) because it was suspected of causing volume reload issues.

Jumping to 0.16 also means dropping the 13 Modal-specific commits on this branch on top of upstream bcff57c — transport-agnostic dispatch, FilesystemSession extraction, the ReplySender/Arc<dyn> elimination, and lowering FUSE request buffers to the negotiated max_write.

Cherry-picking just the security commit keeps the blast radius to the thing the advisory is actually about, and avoids re-running the change that caused the earlier incident.

Conflict resolution

src/mnt/fuse3.rs applied cleanly. src/mnt/fuse3_sys.rs conflicted only on the import block at the top of the file: this branch had

use libc::c_void;
use libc::{c_char, c_int};

extern "C" {

and the fix replaces it with a superset import plus the new fuse_lowlevel_ops type definitions. I took the fix's side, since its imports (c_char, c_int, c_uint, c_void, dev_t, mode_t, off_t, size_t) cover everything the previous two lines provided. No Modal-specific code in that file was dropped; the extern declarations below the conflict, including the updated fuse_session_new signature, merged automatically.

Test plan

• cargo build succeeds against libfuse3 3.17.4 (only pre-existing dead-code warnings)
• Volume reload exercised on a worker before the pin is moved in modal-labs/modal, given the earlier incident

The companion pin bump in modal-labs/modal should not land until that volume reload check is done.

Made with Cursor

[op]

LGTM!

PS. This change existed last year too from the 0.16.0 release. We aren't affected because of how we use fuser so we never forked fuser, instead passing some proof into vanta to override its decision. Adding this is good tho imho.