linux-kernel - Re: [PATCH] bpf, arm64: Fix address emission with tag-based KASAN enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4d7a35f8-2d03-4cf6-af6a-9e8e8b374618@huaweicloud.com>
Date: Sat, 19 Oct 2024 17:24:42 +0800
From: Xu Kuohai <xukuohai@...weicloud.com>
To: Peter Collingbourne <pcc@...gle.com>, Alexei Starovoitov
 <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, Puranjay Mohan <puranjay12@...il.com>,
 Xu Kuohai <xukuohai@...weicloud.com>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Jean-Philippe Brucker <jean-philippe@...aro.org>, bpf@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Cc: Alexander Potapenko <glider@...gle.com>,
 Andrey Konovalov <andreyknvl@...il.com>, stable@...r.kernel.org
Subject: Re: [PATCH] bpf, arm64: Fix address emission with tag-based KASAN
 enabled

On 10/19/2024 6:16 AM, Peter Collingbourne wrote:
> When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image
> struct on the stack is passed during the size calculation pass and
> an address on the heap is passed during code generation. This may
> cause a heap buffer overflow if the heap address is tagged because
> emit_a64_mov_i64() will emit longer code than it did during the size
> calculation pass. The same problem could occur without tag-based
> KASAN if one of the 16-bit words of the stack address happened to
> be all-ones during the size calculation pass. Fix the problem by
> assuming the worst case (4 instructions) when calculating the size
> of the bpf_tramp_image address emission.
> 
> Fixes: 19d3c179a377 ("bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG")
> Signed-off-by: Peter Collingbourne <pcc@...gle.com>
> Link: https://linux-review.googlesource.com/id/I1496f2bc24fba7a1d492e16e2b94cf43714f2d3c
> Cc: stable@...r.kernel.org
> ---
>   arch/arm64/net/bpf_jit_comp.c | 12 ++++++++++--
>   1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
> index 8bbd0b20136a8..5db82bfc9dc11 100644
> --- a/arch/arm64/net/bpf_jit_comp.c
> +++ b/arch/arm64/net/bpf_jit_comp.c
> @@ -2220,7 +2220,11 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im,
>   	emit(A64_STR64I(A64_R(20), A64_SP, regs_off + 8), ctx);
>   
>   	if (flags & BPF_TRAMP_F_CALL_ORIG) {
> -		emit_a64_mov_i64(A64_R(0), (const u64)im, ctx);
> +		/* for the first pass, assume the worst case */
> +		if (!ctx->image)
> +			ctx->idx += 4;
> +		else
> +			emit_a64_mov_i64(A64_R(0), (const u64)im, ctx);
>   		emit_call((const u64)__bpf_tramp_enter, ctx);
>   	}
>   
> @@ -2264,7 +2268,11 @@ static int prepare_trampoline(struct jit_ctx *ctx, struct bpf_tramp_image *im,
>   
>   	if (flags & BPF_TRAMP_F_CALL_ORIG) {
>   		im->ip_epilogue = ctx->ro_image + ctx->idx;
> -		emit_a64_mov_i64(A64_R(0), (const u64)im, ctx);
> +		/* for the first pass, assume the worst case */
> +		if (!ctx->image)
> +			ctx->idx += 4;
> +		else
> +			emit_a64_mov_i64(A64_R(0), (const u64)im, ctx);
>   		emit_call((const u64)__bpf_tramp_exit, ctx);
>   	}
>

Acked-by: Xu Kuohai <xukuohai@...wei.com>