linux-kernel - Re: [PATCH] anon_inode: use a proper mode internally

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250406-angucken-ankommen-6974c000f0fb@brauner>
Date: Sun, 6 Apr 2025 21:51:19 +0200
From: Christian Brauner <brauner@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>, 
	Penglei Jiang <superman.xpt@...il.com>, viro@...iv.linux.org.uk, jack@...e.cz, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	syzbot+5d8e79d323a13aa0b248@...kaller.appspotmail.com
Subject: Re: [PATCH] anon_inode: use a proper mode internally

> Anyway, I'm finishing the patch and testing tomorrow and will send out
> with all the things I mentioned (unless I find out I'm wrong).

Found my notes about this. I knew I had notes about this somewhere...
It isn't possible to execute anoymous inodes because you cannot open
them. That includes stuff like:

execveat(fd_anon_inode, "", NULL, NULL, AT_EMPTY_PATH)

Look, anonymous inodes have inode->f_op set to no_open_fops which sets
no_open() which returns ENXIO. That means any call to do_dentry_open()
which is the endpoint of the do_open_execat() will fail. There's no
chance to execute an anonymous inode. Unless a given subsystem overrides
it ofc.

I still agree that we need to be more coherent about this and we need to
improve various semantical quirks I pointed out. But the exec problem
isn't really an issue so the patch itself still seems correct to me.