From: Greg KH <greg@kroah.com>
To: hsimeliere.opensource@witekio.com
Cc: stable@vger.kernel.org, Xu Kuohai <xukuohai@huawei.com>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
BRUNO VERNAY <bruno.vernay@se.com>
Subject: Re: [PATCH v2 6.1] bpf: Prevent tail call between progs attached to different hooks
Date: Tue, 21 Jan 2025 18:09:08 +0100 [thread overview]
Message-ID: <2025012138-quarrel-uneaten-83da@gregkh> (raw)
In-Reply-To: <20250121154117.205334-1-hsimeliere.opensource@witekio.com>
On Tue, Jan 21, 2025 at 04:41:17PM +0100, hsimeliere.opensource@witekio.com wrote:
> From: Xu Kuohai <xukuohai@huawei.com>
>
> [ Upstream commit 28ead3eaabc16ecc907cfb71876da028080f6356 ]
>
> bpf progs can be attached to kernel functions, and the attached functions
> can take different parameters or return different return values. If
> prog attached to one kernel function tail calls prog attached to another
> kernel function, the ctx access or return value verification could be
> bypassed.
>
> For example, if prog1 is attached to func1 which takes only 1 parameter
> and prog2 is attached to func2 which takes two parameters. Since verifier
> assumes the bpf ctx passed to prog2 is constructed based on func2's
> prototype, verifier allows prog2 to access the second parameter from
> the bpf ctx passed to it. The problem is that verifier does not prevent
> prog1 from passing its bpf ctx to prog2 via tail call. In this case,
> the bpf ctx passed to prog2 is constructed from func1 instead of func2,
> that is, the assumption for ctx access verification is bypassed.
>
> Another example, if BPF LSM prog1 is attached to hook file_alloc_security,
> and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier
> knows the return value rules for these two hooks, e.g. it is legal for
> bpf_lsm_audit_rule_known to return positive number 1, and it is illegal
> for file_alloc_security to return positive number. So verifier allows
> prog2 to return positive number 1, but does not allow prog1 to return
> positive number. The problem is that verifier does not prevent prog1
> from calling prog2 via tail call. In this case, prog2's return value 1
> will be used as the return value for prog1's hook file_alloc_security.
> That is, the return value rule is bypassed.
>
> This patch adds restriction for tail call to prevent such bypasses.
>
> Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
> Link: https://lore.kernel.org/r/20240719110059.797546-4-xukuohai@huaweicloud.com
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> [ Deletion of the patch line on the condition using bpf_prog_is_dev_bound as
> it was added by commit 3d76a4d3d4e591af3e789698affaad88a5a8e8ab which is not
> present in version 6.1 ]
> Signed-off-by: BRUNO VERNAY <bruno.vernay@se.com>
> Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
> ---
> include/linux/bpf.h | 1 +
> kernel/bpf/core.c | 19 +++++++++++++++++--
> 2 files changed, 18 insertions(+), 2 deletions(-)
Why is this commit needed in the 6.1.y kernel tree?
confused,
greg k-h
next prev parent reply other threads:[~2025-01-21 17:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-10 8:40 [PATCH 6.1] bpf: Prevent tail call between progs attached to different hooks hsimeliere.opensource
2025-01-10 17:39 ` Sasha Levin
2025-01-12 11:51 ` Greg KH
2025-01-21 15:41 ` [PATCH v2 " hsimeliere.opensource
2025-01-21 17:09 ` Greg KH [this message]
2025-02-10 9:44 ` hsimeliere.opensource
2025-02-10 9:55 ` Greg KH
2025-02-10 14:29 ` hsimeliere.opensource
2025-02-10 14:43 ` Greg KH
2025-02-10 16:32 ` hsimeliere.opensource
2025-02-11 6:41 ` Greg KH
2025-01-21 19:52 ` Sasha Levin
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=2025012138-quarrel-uneaten-83da@gregkh \
--to=greg@kroah.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bruno.vernay@se.com \
--cc=hsimeliere.opensource@witekio.com \
--cc=stable@vger.kernel.org \
--cc=xukuohai@huawei.com \
/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.