From: Sergei Nizovtsev <snizovtsev@cloudlinux.com>
To: bpf@vger.kernel.org
Cc: linux-security-module@vger.kernel.org,
Sergei Nizovtsev <snizovtsev@cloudlinux.com>,
stable@vger.kernel.org, KP Singh <kpsingh@kernel.org>,
Matt Bobrowski <matt@bobrowski.net>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jiri Olsa <jolsa@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
Ihor Solodrai <ihor.solodrai@linux.dev>,
Serge Hallyn <serge@hallyn.com>,
Amir Goldstein <amir73il@gmail.com>,
Paul Moore <paul@paul-moore.com>,
Christian Brauner <brauner@kernel.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH bpf] bpf, lsm: Mark backing_file_alloc/free LSM hooks as untrusted
Date: Wed, 11 Nov 2026 21:35:52 +0100 [thread overview]
Message-ID: <20261111203614.1221188-1-snizovtsev@cloudlinux.com> (raw)
The backing_file_alloc and backing_file_free LSM hooks get the backing
file as "struct file *backing_file", but its f_path is not populated
while they run:
- security_backing_file_alloc() is called from init_backing_file() in
alloc_empty_backing_file(), before vfs_open() sets f_path, so
backing_file->f_path.dentry is NULL;
- security_backing_file_free() can run for a backing file whose open
failed and whose f_path was already cleared.
Neither hook is listed in untrusted_lsm_hooks, so bpf_lsm_is_trusted()
lets BPF LSM programs use the argument as a trusted pointer. A program
attached to lsm/backing_file_alloc can pass &backing_file->f_path to the
trusted-args kfunc bpf_path_d_path(), and d_path() dereferences the NULL
dentry on the first open of a file on overlayfs:
extern int bpf_path_d_path(const struct path *path, char *buf,
size_t sz) __ksym;
char buf[256];
SEC("lsm/backing_file_alloc")
int BPF_PROG(poc, struct file *backing_file,
const struct file *user_file)
{
bpf_path_d_path(&backing_file->f_path, buf, sizeof(buf));
return 0;
}
# bpftool prog load poc.bpf.o /sys/fs/bpf/poc autoattach
# cat <any file on an overlayfs mount>
Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]
RIP: 0010:d_path+0xb4/0x810
Call Trace:
bpf_path_d_path+0x26/0x70
bpf_prog_f8f2e241d4ff7217_poc+0x33/0x37
bpf_trampoline_6442521065+0x61/0xf9
security_backing_file_alloc+0x78/0xe0
alloc_empty_backing_file+0xf0/0x170
backing_file_open+0xfd/0x290
ovl_open_realfile+0x1ed/0x270
ovl_open+0x1a9/0x2f0
do_dentry_open+0x404/0x1280
vfs_open_consume+0xba/0x4b0
path_openat+0xc4f/0x1f60
Add both hooks to untrusted_lsm_hooks, next to file_alloc_security and
file_free_security, which are listed there for the same reason. The
program above is then rejected at load time with "R1 must be referenced
or trusted".
Fixes: 6af36aeb147a ("lsm: add backing_file LSM hooks")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-fable-5-2
Signed-off-by: Sergei Nizovtsev <snizovtsev@cloudlinux.com>
---
Tested on bpf.git master (475a0cfd02f1) under virtme-ng with KASAN: the
reproducer oopses without the patch and fails to load with it. Only the
backing_file_alloc case was reproduced; backing_file_free is from code
reading.
kernel/bpf/bpf_lsm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c
index f58dce888ff4a..f39a3766f2245 100644
--- a/kernel/bpf/bpf_lsm.c
+++ b/kernel/bpf/bpf_lsm.c
@@ -411,6 +411,8 @@ BTF_ID(func, bpf_lsm_bpf_map_free)
BTF_ID(func, bpf_lsm_bpf_prog_free)
BTF_ID(func, bpf_lsm_file_alloc_security)
BTF_ID(func, bpf_lsm_file_free_security)
+BTF_ID(func, bpf_lsm_backing_file_alloc)
+BTF_ID(func, bpf_lsm_backing_file_free)
#ifdef CONFIG_SECURITY_NETWORK
BTF_ID(func, bpf_lsm_sk_alloc_security)
BTF_ID(func, bpf_lsm_sk_free_security)
--
2.56.0
next reply other threads:[~2026-11-11 20:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 20:35 Sergei Nizovtsev [this message]
2026-11-11 21:02 ` [PATCH bpf] bpf, lsm: Mark backing_file_alloc/free LSM hooks as untrusted sashiko-bot
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=20261111203614.1221188-1-snizovtsev@cloudlinux.com \
--to=snizovtsev@cloudlinux.com \
--cc=amir73il@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=matt@bobrowski.net \
--cc=memxor@gmail.com \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=song@kernel.org \
--cc=stable@vger.kernel.org \
--cc=yonghong.song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox