Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9a3cb0c2-0b1a-28d0-0ebf-c29c6cb37f29@redhat.com>
Date:   Fri, 7 Jul 2023 19:24:00 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [BUG 6.4] sched/core: Possible buffer overflow in
 do_set_cpu_allowed
Content-Language: en-US
To:     Joe Korty <joe.korty@concurrent-rt.com>
Cc:     linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@kernel.org>
References: <20230707202851.GA4231@zipoli.concurrent-rt.com>
From:   Waiman Long <longman@redhat.com>
In-Reply-To: <20230707202851.GA4231@zipoli.concurrent-rt.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 7/7/23 16:28, Joe Korty wrote:
> In commit 9a5418bc48bab ("sched/core: Use kfree_rcu() in
> do_set_cpus_allowed()"), a kfree_rcu() is used to free a cpu mask.
> However, cpu masks can be as short as 8 bytes and this is a problem,
> as kfree_rcu requires the to-be freed buffer to be at least 16 bytes.
> Thus there is a chance of buffer overflow corruption when the number of
> possible cpus in the system is 64 or less.
>
> I have not seen this corruption in the wild.  I only noticed this possibility
> when reviewing the scheduler differences between 6.1 and 6.4.

We were aware of this known limitation. If you look at 
alloc_user_cpus_ptr():

static cpumask_t *alloc_user_cpus_ptr(int node)
{
         /*
          * See do_set_cpus_allowed() above for the rcu_head usage.
          */
         int size = max_t(int, cpumask_size(), sizeof(struct rcu_head));

         return kmalloc_node(size, GFP_KERNEL, node);
}

We made sure that the allocated buffer is big enough to hold struct 
rcu_head.

Cheers,
Longman