All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hui Zhu" <hui.zhu@linux.dev>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 2/2] selftests/bpf: add memcg async reclaim test
Date: Thu, 20 Aug 2026 06:22:16 +0000	[thread overview]
Message-ID: <20260820062216.AA0BC1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <53762e3403fe8e8c263cf685cea5d55377ec5204.1787205002.git.zhuhui@kylinos.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Insecure temporary file creation pattern leading to a TOCTOU race condition.
--

--- Patch [2]: [PATCH bpf-next v4 2/2] selftests/bpf: add memcg async reclaim test ---
commit 690f8d9075834023b364e130547a2026753c92e6
Author: Hui Zhu <zhuhui@kylinos.cn>

selftests/bpf: add memcg async reclaim test

Add memcg_async_reclaim selftest that verifies BPF-driven async
proactive reclaim can mitigate refault-induced slowdown under memory
pressure.

> diff --git a/tools/testing/selftests/bpf/prog_tests/memcg_async_reclaim.c b/tools/testing/selftests/bpf/prog_tests/memcg_async_reclaim.c
> new file mode 100644
> index 0000000000000..ece7bceaab3c4
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/memcg_async_reclaim.c

[ ... ]

> +static int
> +run_high_low_workload(double *high_elapsed, double *low_elapsed, int read_times)
> +{
> +	char high_data_file[PATH_MAX];
> +	char low_data_file[PATH_MAX];
> +	char high_time_file[PATH_MAX];
> +	char low_time_file[PATH_MAX];
> +	const char *dir = workload_files_dir();
> +	pid_t high_pid = -1, low_pid = -1;
> +	pid_t wait_ret;
> +	int fd, status;
> +	int ret = -1;
> +
> +	snprintf(high_data_file, sizeof(high_data_file),
> +		 "%s/memcg_async_high_data_XXXXXX", dir);

[ ... ]

> +	fd = mkstemp(high_data_file);
> +	if (!ASSERT_GE(fd, 0, "mkstemp"))
> +		goto cleanup;
> +	close(fd);

[Severity: Medium]
Is this temporary file creation vulnerable to a time-of-check to time-of-use
race condition?

By immediately closing the file descriptor securely created by mkstemp()
and reopening it by name later in write_file():

write_file() {
	fp = fopen(filename, "wb");
}

Could this allow a symlink attack in the window between the close and the
open if the file is replaced?

While selftests run in a controlled environment, this pattern is frequently
flagged as a security anti-pattern by static analysis tools.

Would it be possible to pass the file descriptor directly to the child
process instead of closing it, or use exclusive creation flags when
reopening?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787205002.git.zhuhui@kylinos.cn?part=2

  reply	other threads:[~2026-08-20  6:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20  6:12 [PATCH bpf-next v4 0/2] bpf: BPF-driven proactive memcg reclaim Hui Zhu
2026-08-20  6:12 ` [PATCH bpf-next v4 1/2] mm/bpf: Add bpf_proactive_reclaim kfuncs Hui Zhu
2026-08-20  6:24   ` sashiko-bot
2026-08-20  7:05   ` bot+bpf-ci
2026-08-20  6:12 ` [PATCH bpf-next v4 2/2] selftests/bpf: add memcg async reclaim test Hui Zhu
2026-08-20  6:22   ` sashiko-bot [this message]
2026-08-20  7:05   ` bot+bpf-ci

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=20260820062216.AA0BC1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=hui.zhu@linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.