From: Jens Axboe <axboe@kernel.dk>
To: Prithvi Tambewagh <activprithvi@gmail.com>
Cc: io-uring@vger.kernel.org, linux-kernel@vger.kernel.org,
brauner@kernel.org, jack@suse.cz, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org,
linux-kernel-mentees@lists.linux.dev, skhan@linuxfoundation.org,
david.hunter.linux@gmail.com, khalid@kernel.org,
syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH] io_uring: fix filename leak in __io_openat_prep()
Date: Wed, 24 Dec 2025 11:01:55 -0700 [thread overview]
Message-ID: <dc51a709-e404-4515-8023-3597c376aff5@kernel.dk> (raw)
In-Reply-To: <20251224164247.103336-1-activprithvi@gmail.com>
On 12/24/25 9:42 AM, Prithvi Tambewagh wrote:
> __io_openat_prep() allocates a struct filename using getname(), but
> it isn't freed in case the present file is installed in the fixed file
> table and simultaneously, it has the flag O_CLOEXEC set in the
> open->how.flags field.
>
> This is an erroneous condition, since for a file installed in the fixed
> file table, it won't be installed in the normal file table, due to which
> the file cannot support close on exec. Earlier, the code just returned
> -EINVAL error code for this condition, however, the memory allocated for
> that struct filename wasn't freed, resulting in a memory leak.
>
> Hence, the case of file being installed in the fixed file table as well
> as having O_CLOEXEC flag in open->how.flags set, is adressed by using
> putname() to release the memory allocated to the struct filename, then
> setting the field open->filename to NULL, and after that, returning
> -EINVAL.
>
> Reported-by: syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=00e61c43eb5e4740438f
> Tested-by: syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com
> Cc: stable@vger.kernel.org
> Signed-off-by: Prithvi Tambewagh <activprithvi@gmail.com>
> ---
> io_uring/openclose.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/io_uring/openclose.c b/io_uring/openclose.c
> index bfeb91b31bba..fc190a3d8112 100644
> --- a/io_uring/openclose.c
> +++ b/io_uring/openclose.c
> @@ -75,8 +75,11 @@ static int __io_openat_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe
> }
>
> open->file_slot = READ_ONCE(sqe->file_index);
> - if (open->file_slot && (open->how.flags & O_CLOEXEC))
> + if (open->file_slot && (open->how.flags & O_CLOEXEC)) {
> + putname(open->filename);
> + open->filename = NULL;
> return -EINVAL;
> + }
>
> open->nofile = rlimit(RLIMIT_NOFILE);
> req->flags |= REQ_F_NEED_CLEANUP;
You can probably fix it similarly by just having REQ_F_NEED_CLEANUP set
earlier in the process, then everything that needs undoing will get
undone as part of ending the request.
--
Jens Axboe
next prev parent reply other threads:[~2025-12-24 18:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-24 16:42 [PATCH] io_uring: fix filename leak in __io_openat_prep() Prithvi Tambewagh
2025-12-24 18:01 ` Jens Axboe [this message]
2025-12-25 7:08 ` Prithvi
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=dc51a709-e404-4515-8023-3597c376aff5@kernel.dk \
--to=axboe@kernel.dk \
--cc=activprithvi@gmail.com \
--cc=brauner@kernel.org \
--cc=david.hunter.linux@gmail.com \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=khalid@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+00e61c43eb5e4740438f@syzkaller.appspotmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.