Linux VFS Fix For 5 Year Old Bug That Could Cause Corruption, Security Issues Or Crash
([Linux Storage] 5 Hours Ago
Linux VFS Fix)
- Reference: 0001481724
- News link: https://www.phoronix.com/news/Linux-6.11-VFS-Fix-5-Year-Bug
- Source link:
Ahead of the Linux 6.11 merge window set to close tomorrow, Linux engineer Christian Brauner at Microsoft sent in a set of two VFS fixes. One of the fixes is more noteworthy that is for a five year old bug that could cause on-disk corruption, security issues, or a kernel crash.
After Christian Brauner discovered this VFS bug, Seth Forshee of DigitalOcean took to fixing the situation where it was possible to mount file-systems with a non-initial user name-space. This could cause security issues, bugs, or even on-disk corruption. But the good news is that the mount with a non-initial user-namespace was limited in scope to privileged users.
This is a bug that was introduced by a patch authored in 2018 and found in the mainline Linux kernel since February 2019. Thus this VFS fix is expected to be back-ported to currently supported stable Linux kernel series.
Brauner explained in the [1]VFS fixes pull request of the problem:
"I noticed that it is possible for a privileged user to mount most filesystems with a non-initial user namespace in sb->s_user_ns. When fsopen() is called in a non-init namespace the caller's namespace is recorded in fs_context->user_ns. If the returned file descriptor is then passed to a process privileged in init_user_ns, that process can call fsconfig(fd_fs, FSCONFIG_CMD_CREATE*), creating a new superblock with sb->s_user_ns set to the namespace of the process which called fsopen().
This is problematic as only filesystems that raise FS_USERNS_MOUNT are known to be able to support a non-initial s_user_ns. Others may suffer security issues, on-disk corruption or outright crash the kernel. Prevent that by restricting such delegation to filesystems that allow FS_USERNS_MOUNT.
Note, that this delegation requires a privileged process to actually create the superblock so either the privileged process is cooperaing or someone must have tricked a privileged process into operating on a fscontext file descriptor whose origin it doesn't know (a stupid idea).
The bug dates back to about 5 years afaict."
It's just an 11 line patch (well, actually three lines of code, the rest code comments) to fend off this problem. The code is now awaiting pulling to the mainline kernel and then backporting to the stable Linux kernel series.
[1] https://lore.kernel.org/lkml/20240727-vfs-fixes-c054317e0d77@brauner/
After Christian Brauner discovered this VFS bug, Seth Forshee of DigitalOcean took to fixing the situation where it was possible to mount file-systems with a non-initial user name-space. This could cause security issues, bugs, or even on-disk corruption. But the good news is that the mount with a non-initial user-namespace was limited in scope to privileged users.
This is a bug that was introduced by a patch authored in 2018 and found in the mainline Linux kernel since February 2019. Thus this VFS fix is expected to be back-ported to currently supported stable Linux kernel series.
Brauner explained in the [1]VFS fixes pull request of the problem:
"I noticed that it is possible for a privileged user to mount most filesystems with a non-initial user namespace in sb->s_user_ns. When fsopen() is called in a non-init namespace the caller's namespace is recorded in fs_context->user_ns. If the returned file descriptor is then passed to a process privileged in init_user_ns, that process can call fsconfig(fd_fs, FSCONFIG_CMD_CREATE*), creating a new superblock with sb->s_user_ns set to the namespace of the process which called fsopen().
This is problematic as only filesystems that raise FS_USERNS_MOUNT are known to be able to support a non-initial s_user_ns. Others may suffer security issues, on-disk corruption or outright crash the kernel. Prevent that by restricting such delegation to filesystems that allow FS_USERNS_MOUNT.
Note, that this delegation requires a privileged process to actually create the superblock so either the privileged process is cooperaing or someone must have tricked a privileged process into operating on a fscontext file descriptor whose origin it doesn't know (a stupid idea).
The bug dates back to about 5 years afaict."
It's just an 11 line patch (well, actually three lines of code, the rest code comments) to fend off this problem. The code is now awaiting pulling to the mainline kernel and then backporting to the stable Linux kernel series.
[1] https://lore.kernel.org/lkml/20240727-vfs-fixes-c054317e0d77@brauner/
phoronix