linux-kernel - Re: [PATCH 1/1] io_uring/sqpoll: do not put cpumask on stack

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] [day] [month] [year] [list]

Message-ID: <e3e6035d-078f-4803-850e-9308a75023a7@kernel.dk>
Date: Mon, 16 Sep 2024 04:23:06 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Felix Moessbauer <felix.moessbauer@...mens.com>
Cc: io-uring <io-uring@...r.kernel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] io_uring/sqpoll: do not put cpumask on stack

On 9/16/24 4:20 AM, Felix Moessbauer wrote:
> Putting the cpumask on the stack is deprecated for a long time (since
> 2d3854a37e8), as the masks can be big. Given that, we port-over the
> stack allocated mask to the cpumask allocation api.
> 
> Fixes: f011c9cf04c0 ("io_uring/sqpoll: do not allow pinning outside of cpuset")
> Signed-off-by: Felix Moessbauer <felix.moessbauer@...mens.com>
> ---
>  io_uring/sqpoll.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c
> index 7adfcf6818ff..004740d6577e 100644
> --- a/io_uring/sqpoll.c
> +++ b/io_uring/sqpoll.c
> @@ -461,15 +461,22 @@ __cold int io_sq_offload_create(struct io_ring_ctx *ctx,
>  			return 0;
>  
>  		if (p->flags & IORING_SETUP_SQ_AFF) {
> -			struct cpumask allowed_mask;
> +			cpumask_var_t allowed_mask;
>  			int cpu = p->sq_thread_cpu;
>  
>  			ret = -EINVAL;
> +			if (!alloc_cpumask_var(&allowed_mask, GFP_KERNEL)) {
> +				ret = -ENOMEM;
> +				goto err_sqpoll;
> +			}
>  			if (cpu >= nr_cpu_ids || !cpu_online(cpu))
>  				goto err_sqpoll;

This leaks allowed_mask... Probably allocate this _after_ we've already
sanity checked the 'cpu' value itself.

-- 
Jens Axboe