Hacker News Reader

Comment by tremon | Hacker News Reader

What's the origin of the legacy_parse_param size parameter (from struct fs_context->fs_private->data_size)? Is this a mount option, a format-time fs configuration option, or does it require writing a specially-crafted inode to disk? The exploit says the user needs CAP_SYS_ADMIN, so I'm guessing it's the first one?

View on HN

This is a compatibility layer for the older mount APIs, for file system drivers hat don't utilize the newer API yet.

The newer mount API is called `fs_context`, and you can read the LWN article about it here:

https://lwn.net/Articles/780267/ ["VFS: Introduce filesystem context"]

From the commit [0] that added it:

> Legacy filesystems are supported by the provision of a set of legacy fs_context operations that build up a list of mount options and then invoke fs_type->mount() from within the fs_context ->get_tree() operation. This allows all filesystems to be accessed using fs_context.

And then the description of the function itself:

> Add a parameter to a legacy config. We build up a comma-separated list of options.

It looks to be the second one.

[0] https://github.com/torvalds/linux/commit/3e1aeb00e6d132efc15...

I am surprised that mounting is now allowed inside containers. Doesn't this expose a load of new surface attack for the kernel? All these pesky academical filesystem code does not inspire a lot of confidence when parsing user data/disk images....

Reply on news.ycombinator.com