From: Jeff Layton <jlayton@kernel.org>
To: Dorjoy Chowdhury <dorjoychy111@gmail.com>, linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
ceph-devel@vger.kernel.org, gfs2@lists.linux.dev,
linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org,
v9fs@lists.linux.dev, linux-kselftest@vger.kernel.org,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
chuck.lever@oracle.com, alex.aring@gmail.com, arnd@arndb.de,
adilger@dilger.ca, mjguzik@gmail.com, smfrench@gmail.com,
richard.henderson@linaro.org, mattst88@gmail.com,
linmag7@gmail.com, tsbogend@alpha.franken.de,
James.Bottomley@HansenPartnership.com, deller@gmx.de,
davem@davemloft.net, andreas@gaisler.com, idryomov@gmail.com,
amarkuze@redhat.com, slava@dubeyko.com, agruenba@redhat.com,
trondmy@kernel.org, anna@kernel.org, sfrench@samba.org,
pc@manguebit.org, ronniesahlberg@gmail.com,
sprasad@microsoft.com, tom@talpey.com, bharathsm@microsoft.com,
shuah@kernel.org, miklos@szeredi.hu, hansg@kernel.org
Subject: Re: [PATCH v5 1/4] openat2: new OPENAT2_REGULAR flag support
Date: Mon, 16 Mar 2026 12:53:40 -0400 [thread overview]
Message-ID: <5fcc2a6e6d92dae0601c6b3b8faa8b2f83981afb.camel@kernel.org> (raw)
In-Reply-To: <20260307140726.70219-2-dorjoychy111@gmail.com>
On Sat, 2026-03-07 at 20:06 +0600, Dorjoy Chowdhury wrote:
> This flag indicates the path should be opened if it's a regular file.
> This is useful to write secure programs that want to avoid being
> tricked into opening device nodes with special semantics while thinking
> they operate on regular files. This is a requested feature from the
> uapi-group[1].
>
> A corresponding error code EFTYPE has been introduced. For example, if
> openat2 is called on path /dev/null with OPENAT2_REGULAR in the flag
> param, it will return -EFTYPE. EFTYPE is already used in BSD systems
> like FreeBSD, macOS.
>
> When used in combination with O_CREAT, either the regular file is
> created, or if the path already exists, it is opened if it's a regular
> file. Otherwise, -EFTYPE is returned.
>
> When OPENAT2_REGULAR is combined with O_DIRECTORY, -EINVAL is returned
> as it doesn't make sense to open a path that is both a directory and a
> regular file.
>
> [1]: https://uapi-group.org/kernel-features/#ability-to-only-open-regular-files
>
> Signed-off-by: Dorjoy Chowdhury <dorjoychy111@gmail.com>
> ---
> arch/alpha/include/uapi/asm/errno.h | 2 ++
> arch/alpha/include/uapi/asm/fcntl.h | 1 +
> arch/mips/include/uapi/asm/errno.h | 2 ++
> arch/parisc/include/uapi/asm/errno.h | 2 ++
> arch/parisc/include/uapi/asm/fcntl.h | 1 +
> arch/sparc/include/uapi/asm/errno.h | 2 ++
> arch/sparc/include/uapi/asm/fcntl.h | 1 +
> fs/ceph/file.c | 4 ++++
> fs/gfs2/inode.c | 6 ++++++
> fs/namei.c | 4 ++++
> fs/nfs/dir.c | 4 ++++
> fs/open.c | 4 +++-
> fs/smb/client/dir.c | 14 +++++++++++++-
> include/linux/fcntl.h | 2 ++
> include/uapi/asm-generic/errno.h | 2 ++
> include/uapi/asm-generic/fcntl.h | 4 ++++
> tools/arch/alpha/include/uapi/asm/errno.h | 2 ++
> tools/arch/mips/include/uapi/asm/errno.h | 2 ++
> tools/arch/parisc/include/uapi/asm/errno.h | 2 ++
> tools/arch/sparc/include/uapi/asm/errno.h | 2 ++
> tools/include/uapi/asm-generic/errno.h | 2 ++
> 21 files changed, 63 insertions(+), 2 deletions(-)
>
>
I pointed Claude at this patch and got this back. Both issues that it
found will need to be fixed:
Analysis Summary
Commit: 7e7fa2653ca57 - openat2: new OPENAT2_REGULAR flag support
This patch adds a new OPENAT2_REGULAR flag for openat2() that restricts opens to regular files only, returning a new
EFTYPE errno for non-regular files. It adds filesystem-specific checks in ceph, gfs2, nfs, and cifs atomic_open paths,
plus a VFS-level fallback in do_open().
Issues found:
1. OPENAT2_REGULAR leaks into f_flags - do_dentry_open() strips open-time-only flags (O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC)
but does not strip OPENAT2_REGULAR. When a regular file is successfully opened via openat2() with this flag, the bit
persists in file->f_flags and will be returned by fcntl(fd, F_GETFL).
2. BUILD_BUG_ON not updated - The compile-time guard checks upper_32_bits(VALID_OPEN_FLAGS) but the code now accepts
VALID_OPENAT2_FLAGS. The guard should cover the expanded flag set.
Verified correct:
- All hex→octal conversions in MIPS and SPARC fcntl.h are numerically correct
- Legacy open()/openat() properly strips OPENAT2_REGULAR via build_open_how() masking with VALID_OPEN_FLAGS
- All filesystem cleanup paths (ceph, gfs2, nfs, cifs) properly handle resources when returning -EFTYPE
- O_DIRECTORY + OPENAT2_REGULAR mutual exclusion is correct
- O_PATH + OPENAT2_REGULAR is properly rejected by O_PATH_FLAGS check
Ruled out:
- NFS -ENOTDIR to -EFTYPE conversion: in atomic_open context, parent path is VFS-resolved, server errors relate to
target
- CIFS resource leak: out_err label properly closes server handle and calls iput()
- OPENAT2_REGULAR + O_TMPFILE: silently accepted but tmpfiles are always regular, so harmless
FINAL REGRESSIONS FOUND: 2
FINAL TOKENS USED: ~45000
False positives eliminated: NFS -ENOTDIR conversion, CIFS resource leak, O_TMPFILE interaction
Cheers,
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2026-03-16 16:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 14:06 [PATCH v5 0/4] OPENAT2_REGULAR flag support for openat2 Dorjoy Chowdhury
2026-03-07 14:06 ` [PATCH v5 1/4] openat2: new OPENAT2_REGULAR flag support Dorjoy Chowdhury
2026-03-07 18:56 ` Andy Lutomirski
2026-03-08 6:31 ` Dorjoy Chowdhury
2026-03-08 11:40 ` Jeff Layton
2026-03-08 17:10 ` Andy Lutomirski
2026-03-09 8:57 ` Christian Brauner
2026-03-09 16:50 ` Andy Lutomirski
2026-03-09 17:39 ` Florian Weimer
2026-03-10 11:24 ` Christian Brauner
2026-03-11 4:48 ` Aleksa Sarai
2026-03-11 16:10 ` Andy Lutomirski
2026-03-12 9:37 ` Aleksa Sarai
2026-03-16 16:53 ` Jeff Layton [this message]
2026-03-16 17:22 ` Dorjoy Chowdhury
2026-03-07 14:06 ` [PATCH v5 2/4] kselftest/openat2: test for OPENAT2_REGULAR flag Dorjoy Chowdhury
2026-03-07 14:06 ` [PATCH v5 3/4] sparc/fcntl.h: convert O_* flag macros from hex to octal Dorjoy Chowdhury
2026-03-07 14:06 ` [PATCH v5 4/4] mips/fcntl.h: " Dorjoy Chowdhury
2026-03-16 16:12 ` [PATCH v5 0/4] OPENAT2_REGULAR flag support for openat2 Dorjoy Chowdhury
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5fcc2a6e6d92dae0601c6b3b8faa8b2f83981afb.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=adilger@dilger.ca \
--cc=agruenba@redhat.com \
--cc=alex.aring@gmail.com \
--cc=amarkuze@redhat.com \
--cc=andreas@gaisler.com \
--cc=anna@kernel.org \
--cc=arnd@arndb.de \
--cc=bharathsm@microsoft.com \
--cc=brauner@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=dorjoychy111@gmail.com \
--cc=gfs2@lists.linux.dev \
--cc=hansg@kernel.org \
--cc=idryomov@gmail.com \
--cc=jack@suse.cz \
--cc=linmag7@gmail.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=miklos@szeredi.hu \
--cc=mjguzik@gmail.com \
--cc=pc@manguebit.org \
--cc=richard.henderson@linaro.org \
--cc=ronniesahlberg@gmail.com \
--cc=sfrench@samba.org \
--cc=shuah@kernel.org \
--cc=slava@dubeyko.com \
--cc=smfrench@gmail.com \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=v9fs@lists.linux.dev \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox