Re: CVE-2025-21830: landlock: Handle weird files

Kent Overstreet
2025-03-11T10:50:40Z

On Tue, Mar 11, 2025 at 03:24:40PM +1100, Dave Chinner wrote:
> On Mon, Mar 10, 2025 at 10:09:22PM -0400, Kent Overstreet wrote:
> > On Tue, Mar 11, 2025 at 10:42:41AM +1100, Dave Chinner wrote:
> > If user mounts are enabled, that comes with UID mapping, and device
> > nodes disabled - no?
>
> Not necessarily. Those security mechanisms are all optional mount
> options under userspace control....

Well, if someone's being an idiot, that's on them and not something I'm
going to argue about :) Uidmapping has been around for plenty long
enough for userspace to start using it.

>
> > Out of curiosity, what's keeping us from saying "user mounts are
> > generally expected to be safe" for XFS?
>
> What does "generally expected to be safe" actually mean?
>
> If be "safe" you mean "won't crash the kernel if the structure has
> been altered in detectable ways with", then we already largely tick
> that box. However, there are whole classes of DOS attacks that are
> very difficult to detect without rigorous, expensive runtime
> checking (e.g. loops in btree pointers).

btree nodes don't change depth, so just recording the level of a node
and validating it trivially defeats that. bcachefs has that in its on
disk format, but if you don't have that then that might be a problem -
you'd at least need to know a priori the depth of the root node.

> Hence while we catch almost all the the obvious out-of-bounds
> corruptions within an object, detecting corruptions that require
> spanning a largely unbound number of objects to detect are not
> handled at all. I can corrupt a filesystem to induce an endless
> btree search loop like this pretty easily with a little bit of
> xfs_db magic. Yup, we even provide the tools to make doing stuff
> like this easy...

*nod*

In bcachefs, we right now have no way to cleanly detect "filesystem is
actually full, disk accounting info is wrong" so - that means corruption
causes allocations to get stuck. That one is fixable, and I'm going to
have to at some point since syzbot knows how to trigger it :)

> If by "safe" you mean "can detect all cases where a metadata field
> or file data has been tampered with", then XFS is completely unsafe
> and should not be used.
>
> We can't detect that a malicious actor has changed something like a
> file permission field or the contents of a security xattr. To do
> that requires cryptographically secure signatures of metadata
> objects and file data. We do not have that sort of feature in the
> on-disk format. We expect users that need protection from such
> tampering will use an envrypted block device to prevent malicious
> actors from being able to mutate the filesystem structure in this
> way.

Yeah, but that's the less interesting case to me. Not uninteresting,
since "I don't fully trust my block device" is a real scenario with
network attached storage. But generally, the tampering would be done by
the user that did the mount - so perhaps we need to find some new nudges
to make uidmapping of user mounts required?

That could be done in util-linux...