From: Xu Kuohai <xukuohai@huaweicloud.com>
To: bpf@vger.kernel.org, linux-security-module@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
Florent Revest <revest@chromium.org>,
Brendan Jackman <jackmanb@chromium.org>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E . Hallyn" <serge@hallyn.com>,
Khadija Kamran <kamrankhadijadj@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Ondrej Mosnacek <omosnace@redhat.com>,
Kees Cook <keescook@chromium.org>,
John Johansen <john.johansen@canonical.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Shung-Hsi Yu <shung-hsi.yu@suse.com>
Subject: [PATCH bpf-next v2 0/7] Add check for bpf lsm return value
Date: Mon, 25 Mar 2024 17:56:46 +0800 [thread overview]
Message-ID: <20240325095653.1720123-1-xukuohai@huaweicloud.com> (raw)
From: Xu Kuohai <xukuohai@huawei.com>
A bpf prog returning positive number attached to file_alloc_security hook
will make kernel panic.
Here is a panic log:
[ 441.235774] BUG: kernel NULL pointer dereference, address: 00000000000009
[ 441.236748] #PF: supervisor write access in kernel mode
[ 441.237429] #PF: error_code(0x0002) - not-present page
[ 441.238119] PGD 800000000b02f067 P4D 800000000b02f067 PUD b031067 PMD 0
[ 441.238990] Oops: 0002 [#1] PREEMPT SMP PTI
[ 441.239546] CPU: 0 PID: 347 Comm: loader Not tainted 6.8.0-rc6-gafe0cbf23373 #22
[ 441.240496] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b4
[ 441.241933] RIP: 0010:alloc_file+0x4b/0x190
[ 441.242485] Code: 8b 04 25 c0 3c 1f 00 48 8b b0 30 0c 00 00 e8 9c fe ff ff 48 3d 00 f0 ff fb
[ 441.244820] RSP: 0018:ffffc90000c67c40 EFLAGS: 00010203
[ 441.245484] RAX: ffff888006a891a0 RBX: ffffffff8223bd00 RCX: 0000000035b08000
[ 441.246391] RDX: ffff88800b95f7b0 RSI: 00000000001fc110 RDI: f089cd0b8088ffff
[ 441.247294] RBP: ffffc90000c67c58 R08: 0000000000000001 R09: 0000000000000001
[ 441.248209] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000001
[ 441.249108] R13: ffffc90000c67c78 R14: ffffffff8223bd00 R15: fffffffffffffff4
[ 441.250007] FS: 00000000005f3300(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000
[ 441.251053] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 441.251788] CR2: 00000000000001a9 CR3: 000000000bdc4003 CR4: 0000000000170ef0
[ 441.252688] Call Trace:
[ 441.253011] <TASK>
[ 441.253296] ? __die+0x24/0x70
[ 441.253702] ? page_fault_oops+0x15b/0x480
[ 441.254236] ? fixup_exception+0x26/0x330
[ 441.254750] ? exc_page_fault+0x6d/0x1c0
[ 441.255257] ? asm_exc_page_fault+0x26/0x30
[ 441.255792] ? alloc_file+0x4b/0x190
[ 441.256257] alloc_file_pseudo+0x9f/0xf0
[ 441.256760] __anon_inode_getfile+0x87/0x190
[ 441.257311] ? lock_release+0x14e/0x3f0
[ 441.257808] bpf_link_prime+0xe8/0x1d0
[ 441.258315] bpf_tracing_prog_attach+0x311/0x570
[ 441.258916] ? __pfx_bpf_lsm_file_alloc_security+0x10/0x10
[ 441.259605] __sys_bpf+0x1bb7/0x2dc0
[ 441.260070] __x64_sys_bpf+0x20/0x30
[ 441.260533] do_syscall_64+0x72/0x140
[ 441.261004] entry_SYSCALL_64_after_hwframe+0x6e/0x76
[ 441.261643] RIP: 0033:0x4b0349
[ 441.262045] Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 88
[ 441.264355] RSP: 002b:00007fff74daee38 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
[ 441.265293] RAX: ffffffffffffffda RBX: 00007fff74daef30 RCX: 00000000004b0349
[ 441.266187] RDX: 0000000000000040 RSI: 00007fff74daee50 RDI: 000000000000001c
[ 441.267114] RBP: 000000000000001b R08: 00000000005ef820 R09: 0000000000000000
[ 441.268018] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004
[ 441.268907] R13: 0000000000000004 R14: 00000000005ef018 R15: 00000000004004e8
The reason is that the positive number returned by bpf prog is not a
valid errno, and could not be filtered out with IS_ERR which is used by
the file system to check errors. As a result, the filesystem mistakenly
uses this random positive number as file pointer, causing panic.
To fix this issue, there are two schemes:
1. Modify the calling sites of file_alloc_security to take positive
return values as zero.
2. Make the bpf verifier to ensure no unpredicted value returned by
lsm bpf prog.
Considering that hook file_alloc_security never returned positive number
before bpf lsm was introduced, and other lsm hooks may have the same
problem, scheme 2 is more reasonable.
So this patch set adds lsm return value check in verifier to fix it.
v2:
fix bpf ci failure
v1:
https://lore.kernel.org/bpf/20240316122359.1073787-1-xukuohai@huaweicloud.com/
Xu Kuohai (7):
bpf, lsm: Annotate lsm hook return integer with new macro LSM_RET_INT
bpf, lsm: Add return value range description for lsm hook
bpf, lsm: Add function to read lsm hook return value range
bpf, lsm: Check bpf lsm hook return values in verifier
bpf: Fix compare error in function retval_range_within
selftests/bpf: Avoid load failure for token_lsm.c
selftests/bpf: Add return value checks and corrections for failed
progs
include/linux/bpf.h | 1 +
include/linux/bpf_lsm.h | 8 +
include/linux/lsm_hook_defs.h | 433 +++++++++---------
include/linux/lsm_hooks.h | 6 -
kernel/bpf/bpf_lsm.c | 66 ++-
kernel/bpf/btf.c | 5 +-
kernel/bpf/verifier.c | 59 ++-
security/security.c | 1 +
tools/testing/selftests/bpf/progs/err.h | 10 +
.../selftests/bpf/progs/test_sig_in_xattr.c | 4 +
.../bpf/progs/test_verify_pkcs7_sig.c | 8 +-
tools/testing/selftests/bpf/progs/token_lsm.c | 4 +-
.../bpf/progs/verifier_global_subprogs.c | 7 +-
13 files changed, 376 insertions(+), 236 deletions(-)
--
2.30.2
next reply other threads:[~2024-03-25 9:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 9:56 Xu Kuohai [this message]
2024-03-25 9:56 ` [PATCH bpf-next v2 1/7] bpf, lsm: Annotate lsm hook return integer with new macro LSM_RET_INT Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 2/7] bpf, lsm: Add return value range description for lsm hook Xu Kuohai
2024-04-08 17:09 ` KP Singh
2024-04-08 22:15 ` KP Singh
2024-04-10 12:30 ` Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 3/7] bpf, lsm: Add function to read lsm hook return value range Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 4/7] bpf, lsm: Check bpf lsm hook return values in verifier Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 5/7] bpf: Fix compare error in function retval_range_within Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 6/7] selftests/bpf: Avoid load failure for token_lsm.c Xu Kuohai
2024-03-25 9:56 ` [PATCH bpf-next v2 7/7] selftests/bpf: Add return value checks and corrections for failed progs Xu Kuohai
2024-04-08 21:45 ` [PATCH bpf-next v2 0/7] Add check for bpf lsm return value KP Singh
2024-04-10 12:34 ` Xu Kuohai
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=20240325095653.1720123-1-xukuohai@huaweicloud.com \
--to=xukuohai@huaweicloud.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=jackmanb@chromium.org \
--cc=jmorris@namei.org \
--cc=john.fastabend@gmail.com \
--cc=john.johansen@canonical.com \
--cc=jolsa@kernel.org \
--cc=kamrankhadijadj@gmail.com \
--cc=keescook@chromium.org \
--cc=kpsingh@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=martin.lau@linux.dev \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--cc=revest@chromium.org \
--cc=roberto.sassu@huawei.com \
--cc=sdf@google.com \
--cc=serge@hallyn.com \
--cc=shung-hsi.yu@suse.com \
--cc=song@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).