Linux filesystem development
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: [bug report] coredump: hand a pidfd to the usermode coredump helper
Date: Fri, 25 Apr 2025 17:23:38 +0300	[thread overview]
Message-ID: <aAua6ufHsy6qhMcs@stanley.mountain> (raw)

Hello Christian Brauner,

Commit 4268b86fe0c7 ("coredump: hand a pidfd to the usermode coredump
helper") from Apr 14, 2025 (linux-next), leads to the following
Smatch static checker warning:

	fs/coredump.c:556 umh_coredump_setup()
	warn: re-assigning __cleanup__ ptr 'pidfs_file'

fs/coredump.c
    536 static int umh_coredump_setup(struct subprocess_info *info, struct cred *new)
    537 {
    538         struct file *files[2];
    539         struct coredump_params *cp = (struct coredump_params *)info->data;
    540         int err;
    541 
    542         if (cp->pid) {
    543                 struct file *pidfs_file __free(fput) = NULL;
    544 
    545                 pidfs_file = pidfs_alloc_file(cp->pid, 0);

We allocate pidfs_file.

    546                 if (IS_ERR(pidfs_file))
    547                         return PTR_ERR(pidfs_file);
    548 
    549                 /*
    550                  * Usermode helpers are childen of either
    551                  * system_unbound_wq or of kthreadd. So we know that
    552                  * we're starting off with a clean file descriptor
    553                  * table. So we should always be able to use
    554                  * COREDUMP_PIDFD_NUMBER as our file descriptor value.
    555                  */
--> 556                 VFS_WARN_ON_ONCE((pidfs_file = fget_raw(COREDUMP_PIDFD_NUMBER)) != NULL);

Then we set it to NULL without calling fput() on it.

    557 
    558                 err = replace_fd(COREDUMP_PIDFD_NUMBER, pidfs_file, 0);

pidfs_file is NULL so then we basically do:

	err = close_fd(COREDUMP_PIDFD_NUMBER);

I'm so confused...  Should the WARN_ON be for == NULL?

    559                 if (err < 0)
    560                         return err;
    561         }
    562 
    563         err = create_pipe_files(files, 0);
    564         if (err)
    565                 return err;
    566 
    567         cp->file = files[1];
    568 
    569         err = replace_fd(0, files[0], 0);
    570         fput(files[0]);
    571         if (err < 0)
    572                 return err;
    573 
    574         /* and disallow core files too */
    575         current->signal->rlim[RLIMIT_CORE] = (struct rlimit){1, 1};
    576 
    577         return 0;
    578 }

regards,
dan carpenter

             reply	other threads:[~2025-04-25 14:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-25 14:23 Dan Carpenter [this message]
2025-04-28  7:51 ` [bug report] coredump: hand a pidfd to the usermode coredump helper Christian Brauner

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=aAua6ufHsy6qhMcs@stanley.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /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