From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Amery Hung <ameryhung@gmail.com>,
Kaiyan Mei <M202472210@hust.edu.cn>,
Yinhao Hu <dddddd@hust.edu.cn>, Dongliang Mu <dzm91@hust.edu.cn>,
Alexei Starovoitov <ast@kernel.org>,
Sasha Levin <sashal@kernel.org>,
kpsingh@kernel.org, mattbobrowski@google.com,
daniel@iogearbox.net, andrii@kernel.org, bpf@vger.kernel.org
Subject: [PATCH AUTOSEL 6.18-6.12] bpf: Disable file_alloc_security hook
Date: Mon, 8 Dec 2025 19:15:29 -0500 [thread overview]
Message-ID: <20251209001610.611575-37-sashal@kernel.org> (raw)
In-Reply-To: <20251209001610.611575-1-sashal@kernel.org>
From: Amery Hung <ameryhung@gmail.com>
[ Upstream commit b4bf1d23dc1da236c92a9d9be68cc63358d1f750 ]
A use-after-free bug may be triggered by calling bpf_inode_storage_get()
in a BPF LSM program hooked to file_alloc_security. Disable the hook to
prevent this from happening.
The cause of the bug is shown in the trace below. In alloc_file(), a
file struct is first allocated through kmem_cache_alloc(). Then,
file_alloc_security hook is invoked. Since the zero initialization or
assignment of f->f_inode happen after this LSM hook, a BPF program may
get a dangeld inode pointer by walking the file struct.
alloc_file()
-> alloc_empty_file()
-> f = kmem_cache_alloc()
-> init_file()
-> security_file_alloc() // f->f_inode not init-ed yet!
-> f->f_inode = NULL;
-> file_init_path()
-> f->f_inode = path->dentry->d_inode
Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
Reported-by: Dongliang Mu <dzm91@hust.edu.cn>
Closes: https://lore.kernel.org/bpf/1d2d1968.47cd3.19ab9528e94.Coremail.kaiyanm@hust.edu.cn/
Signed-off-by: Amery Hung <ameryhung@gmail.com>
Link: https://lore.kernel.org/r/20251126202927.2584874-1-ameryhung@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Summary
### What the Bug Is
This is a **use-after-free vulnerability** in BPF LSM. When a file is
allocated:
1. `kmem_cache_alloc()` allocates a file struct
2. `security_file_alloc()` is called - **BPF hooks run here**
3. `f->f_inode = NULL` is set **AFTER** the hook (fs/file_table.c:179)
If a BPF program attached to `file_alloc_security` calls
`bpf_inode_storage_get()`, it reads `f->f_inode` which contains
**uninitialized slab memory** - a classic UAF pattern.
### The Fix
Adds `bpf_lsm_file_alloc_security` to the `bpf_lsm_disabled_hooks` set.
This causes the BPF verifier to reject any program trying to attach to
this hook (line 126-130 in bpf_lsm.c).
### Stable Kernel Assessment
| Criterion | Assessment |
|-----------|------------|
| **Fixes real bug** | ✅ UAF vulnerability, reported by security
researchers |
| **Obviously correct** | ✅ Follows established pattern (11 other hooks
already disabled) |
| **Small and contained** | ✅ Single line addition |
| **No new features** | ✅ Actually disables functionality |
| **Tested** | ✅ Reviewed by BPF maintainer |
| **Risk of regression** | ✅ Very low - only affects programs that were
already buggy |
### Dependency Concern
The `bpf_lsm_disabled_hooks` mechanism was introduced in commit
21c7063f6d08a (v6.12-rc1). This fix **only applies to 6.12.y stable
tree**. Older LTS kernels (6.6.y, 6.1.y, 5.15.y, etc.) would require
backporting the entire disabled hooks infrastructure first.
### Missing Stable Tags
The commit lacks "Cc: stable@vger.kernel.org" and "Fixes:" tags.
However:
- This is a security fix (UAF)
- The fix is trivial and safe
- Signed off by BPF maintainer Alexei Starovoitov
### Risk vs Benefit
- **Risk**: Near zero - only prevents BPF programs from attaching to an
unsafe hook
- **Benefit**: Prevents a UAF vulnerability that could cause crashes or
be exploited
### Conclusion
This commit should be backported to the 6.12.y stable tree. It fixes a
real security vulnerability with a minimal, safe, one-line change that
follows an established pattern. The absence of explicit stable tags
appears to be an oversight. For older stable trees, this specific patch
won't apply without the disabled hooks infrastructure.
**YES**
kernel/bpf/bpf_lsm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c
index 0a59df1c550a0..7cb6e8d4282cb 100644
--- a/kernel/bpf/bpf_lsm.c
+++ b/kernel/bpf/bpf_lsm.c
@@ -51,6 +51,7 @@ BTF_ID(func, bpf_lsm_key_getsecurity)
BTF_ID(func, bpf_lsm_audit_rule_match)
#endif
BTF_ID(func, bpf_lsm_ismaclabel)
+BTF_ID(func, bpf_lsm_file_alloc_security)
BTF_SET_END(bpf_lsm_disabled_hooks)
/* List of LSM hooks that should operate on 'current' cgroup regardless
--
2.51.0
prev parent reply other threads:[~2025-12-09 0:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251209001610.611575-1-sashal@kernel.org>
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] bpf: Skip bounds adjustment for conditional jumps on same scalar register Sasha Levin
2025-12-09 0:15 ` [PATCH AUTOSEL 6.18-6.12] cxgb4: Rename sched_class to avoid type clash Sasha Levin
2025-12-09 0:15 ` Sasha Levin [this message]
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=20251209001610.611575-37-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=M202472210@hust.edu.cn \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dddddd@hust.edu.cn \
--cc=dzm91@hust.edu.cn \
--cc=kpsingh@kernel.org \
--cc=mattbobrowski@google.com \
--cc=patches@lists.linux.dev \
--cc=stable@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