Silent truncation of mount options containing null bytes (\u0000)

[74suiko]

Description: I noticed that crun (v1.28) behaves differently from the latest versions of runc (v1.4.2) and youki (v0.6.0) when parsing mount options that contain a null byte (\u0000).

When mounting filesystems such as cgroup, mqueue, sysfs, or when mounting tmpfs to shm, appending a null byte to a mount option (e.g., nosuid\u0000) causes crun to successfully create the container, whereas runc and youki error out.

Specification and Security Basis: While JSON allows \u0000 in strings, Linux mount(2) treats null bytes as C-string terminators. It appears that crun silently truncates the mount option at the null byte and proceeds with the operation. This behavior might be inconsistent with expected configuration fidelity and poses a potential security risk: if additional security-critical mount options follow the null byte, they might be silently discarded without alerting the user.

Steps to reproduce the issue:

1. Use the following minimal config.json snippet where \u0000 is injected into the mount options:

config.json snippet

"mounts": [
    {
        "destination": "/proc",
        "type": "proc",
        "source": "proc"
    },
    {
        "destination": "/dev",
        "type": "tmpfs",
        "source": "tmpfs",
        "options": [
            "nosuid",
            "strictatime",
            "mode=755",
            "size=65536k"
        ]
    },
    {
        "destination": "/dev/pts",
        "type": "devpts",
        "source": "devpts",
        "options": [
            "nosuid",
            "noexec",
            "newinstance",
            "ptmxmode=0666",
            "mode=0620",
            "gid=5"
        ]
    },
    {
        "destination": "/dev/shm",
        "type": "tmpfs",
        "source": "shm",
        "options": [
            "nosuid",
            "noexec",
            "nodev",
            "mode=1777",
            "size=65536k"
        ]
    },
    {
        "destination": "/dev/mqueue",
        "type": "mqueue",
        "source": "mqueue",
        "options": [
            "nosuid",
            "noexec",
            "nodev"
        ]
    },
    {
        "destination": "/sys",
        "type": "sysfs",
        "source": "sysfs",
        "options": [
            "nosuid",
            "noexec",
            "nodev",
            "ro"
        ]
    },
    {
        "destination": "/sys/fs/cgroup",
        "type": "cgroup2",
        "source": "cgroup2",
        "options": [
            "nosuid\u0000",
            "noexec",
            "nodev",
            "relatime",
            "ro",
            "nsdelegate"
        ]
    }
]

2. Run the container creation command:

sudo crun create -b . mycontainer

Describe the results you received and expected:

• Expected behavior: crun should explicitly reject mount options containing null bytes and error out immediately, preventing silent configuration truncation (similar to how runc and youki handle it).
• Actual behavior: crun silently ignores the null byte (and anything following it), and successfully creates the container.

Logs and Outputs:

Output from crun:

Returns exit code 0 and successfully creates the container

For comparison, output from runc and youki (which behave correctly by throwing an error indicating the invalid argument):

runc output:

ERRO[0000] runc create failed: unable to start container process: error during container init: error mounting "cgroup2" to rootfs at "/sys/fs/cgroup": mount src=cgroup2, dst=/sys/fs/cgroup, dstFd=/proc/thread-self/fd/11, flags=MS_RDONLY|MS_NODEV|MS_NOEXEC|MS_RELATIME, data=nosuid,nsdelegate: invalid argument

youki output:

ERROR libcontainer::rootfs::mount: failed to mount Mount { destination: "/sys/fs/cgroup", typ: Some("cgroup2"), source: Some("cgroup2"), options: Some(["nosuid\0", "noexec", "nodev", "relatime", "ro", "nsdelegate"]), uid_mappings: None, gid_mappings: None }: syscall
ERROR libcontainer::process::init::process: failed to prepare rootfs err=Mount(Syscall(Nix(EINVAL)))
ERROR libcontainer::process::container_intermediate_process: failed to initialize container process: failed to prepare rootfs

[74suiko]

I verified the code path. The mount options flow through get_mount_flags_or_option() in src/libcrun/linux.c at line 713:我已经验证了代码路径。在 src/libcrun/linux.c 的第 713 行，挂载选项是通过 get_mount_flags_or_option() 来传递的。

1. Each option string from mount->options[] is passed directly as a const char *name mount->options[] 中的每个选项字符串都会被直接作为 const char *name 来处理。
2. If it's not a recognized mount flag (MS_BIND, MS_RDONLY, etc.), it's appended to the data string via xasprintf(option, "%s,%s", *option, name) at line 724如果该值不是公认的挂载标志（如 MS_BIND、MS_RDONLY 等），则会在第 724 行，通过 xasprintf(option, "%s,%s", *option, name) 将其追加到 data 字符串的末尾。
3. This data string is later passed to mount(2) via the data parameter这个 data 字符串随后会通过 data 参数被传递给 mount(2) 。

The root cause is that mount(2) treats its data parameter as a C string — the first null byte terminates it. So "nosuid\\0,noexec" would silently become just nosuid.根本原因在于， mount(2) 将 data 参数视为 C 字符串来处理——字符串以第一个空字符结束。因此， "nosuid\\0,noexec" 实际上就变成了 nosuid 。

The fix is to validate mount options for embedded null bytes before they reach get_mount_flags_or_option, similar to what runc and youki do. A validation check in the mount option parsing loop at linux.c:2274 would catch this:解决办法是在嵌入式空字节到达 get_mount_flags_or_option 位置之前，先对其是否有效进行验证，就像 runc 和 yuki 所做的那样。在 linux.c:2274 处的挂载选项解析过程中进行验证，就能发现这个问题。

for (j = 0; j < mount->options_len; j++) {
if (strlen(mount->options[j]) != strnlen(mount->options[j], SIZE_MAX))
return crun_make_error(err, EINVAL, "mount option %s contains null byte", mount->options[j]);
flags |= get_mount_flags_or_option(mount->options[j], flags, &extra_flags, &data, &rec_clear, &rec_set);
}
This matches how runc rejects these per OCI runtime-spec section "POSIX-platform Mounts" — the spec says options are comma-separated strings.这与 runc 根据 OCI 运行时规范中“POSIX 平台挂载”部分的约定来处理这些参数的方式一致：该规范规定，各种选项应以逗号分隔的形式呈现。

Hi,

Apologies for the delayed reply—I've been tied up with final exams recently.

Thank you for tracing the code path! I followed your suggestion and applied the validation check during the def->mounts iteration:

  for (j = 0; j < def->mounts[i]->options_len; j++){
    if (strlen(def->mounts[i]->options[j]) != strnlen(def->mounts[i]->options[j], SIZE_MAX))
        return crun_make_error(err, EINVAL, "mount option `%s` contains null byte", def->mounts[i]->options[j]);
    flags |= get_mount_flags_or_option (def->mounts[i]->options[j], flags, &extra_flags, &data, &rec_clear, &rec_set);
  }

I compiled crun from source and tested it against the payload, but the container still silently creates successfully without throwing the "contains null byte" error.

The reason this bypasses the check is due to standard C-string behavior. By the time the string reaches this loop, def->mounts[i]->options[j] is already a char *. The string was silently truncated earlier during the JSON deserialization phase. Both strlen and strnlen(..., SIZE_MAX) stop at the first embedded \0, so they both return the exact same length (e.g., 6 for nosuid\0noexec). Thus, the if condition always evaluates to false.

To properly catch the injected null byte, the validation must happen earlier at the JSON parser layer (e.g., where yajl knows the true token length) before it becomes a standard null-terminated C string.

Since crun uses a generated parser for config.json, what would be the most appropriate place in the codebase to intercept and validate this string length mismatch?