Received-SPF: pass (google.com: domain of linux-kernel+bounces-163524-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 30 Apr 2024 10:13:10 +0200
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Michal =?iso-8859-1?Q?Koutn=FD?= <mkoutny@suse.com>
Cc: cve@kernel.org, linux-kernel@vger.kernel.org,
	linux-cve-announce@vger.kernel.org,
	Breno =?iso-8859-1?Q?Leit=E3o?= <leitao@debian.org>,
	Tejun Heo <tj@kernel.org>
Subject: Re: CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds
 warning
Message-ID: <2024043053-campsite-refining-1c3c@gregkh>
References: <2024040219-CVE-2023-52630-a529@gregkh>
 <7x4ufwbvk4wmhag66rstdpbm4f2iplyc2l66cl7i2wl5nfh2tm@uxc425y2kfno>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7x4ufwbvk4wmhag66rstdpbm4f2iplyc2l66cl7i2wl5nfh2tm@uxc425y2kfno>

On Fri, Apr 26, 2024 at 07:34:45PM +0200, Michal Koutn? wrote:
> On Tue, Apr 02, 2024 at 08:22:20AM +0200, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > blk-iocost: Fix an UBSAN shift-out-of-bounds warning
> > 
> > When iocg_kick_delay() is called from a CPU different than the one which set
> > the delay, @now may be in the past of @iocg->delay_at leading to the
> > following warning:
> > 
> >   UBSAN: shift-out-of-bounds in block/blk-iocost.c:1359:23
> >   shift exponent 18446744073709 is too large for 64-bit type 'u64' (aka 'unsigned long long')
> >   ...
> >   Call Trace:
> >    <TASK>
> >    dump_stack_lvl+0x79/0xc0
> >    __ubsan_handle_shift_out_of_bounds+0x2ab/0x300
> >    iocg_kick_delay+0x222/0x230
> >    ioc_rqos_merge+0x1d7/0x2c0
> >    __rq_qos_merge+0x2c/0x80
> >    bio_attempt_back_merge+0x83/0x190
> >    blk_attempt_plug_merge+0x101/0x150
> >    blk_mq_submit_bio+0x2b1/0x720
> >    submit_bio_noacct_nocheck+0x320/0x3e0
> >    __swap_writepage+0x2ab/0x9d0
> > 
> > The underflow itself doesn't really affect the behavior in any meaningful
> > way; however, the past timestamp may exaggerate the delay amount calculated
> > later in the code, which shouldn't be a material problem given the nature of
> > the delay mechanism.
> 
> The worst implication is unfair or slowed IO but that can't be
> quantified given empirical implementation of the delay mechanism.
> 
> > If @now is in the past, this CPU is racing another CPU which recently set up
> > the delay and there's nothing this CPU can contribute w.r.t. the delay.
> 
> This means the user has limited control (with noise) over such
> placements.
> 
> > Let's bail early from iocg_kick_delay() in such cases.
> > 
> > The Linux kernel CVE team has assigned CVE-2023-52630 to this issue.
> 
> Based on the above I don't think this fix deserves CVE tracking. Shall
> it be rejected?

Makes sense, thanks for looking into this, and sorry for the delay.  Now
rejected.

greg k-h