Received-SPF: pass (google.com: domain of linux-kernel+bounces-160502-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Fri, 26 Apr 2024 19:34:45 +0200
From: Michal =?utf-8?Q?Koutn=C3=BD?= <mkoutny@suse.com>
To: cve@kernel.org, linux-kernel@vger.kernel.org
Cc: linux-cve-announce@vger.kernel.org, 
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Breno =?utf-8?Q?Leit=C3=A3o?= <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: <7x4ufwbvk4wmhag66rstdpbm4f2iplyc2l66cl7i2wl5nfh2tm@uxc425y2kfno>
References: <2024040219-CVE-2023-52630-a529@gregkh>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="knjgfunz3pfevm5m"
Content-Disposition: inline
In-Reply-To: <2024040219-CVE-2023-52630-a529@gregkh>


--knjgfunz3pfevm5m
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 02, 2024 at 08:22:20AM +0200, Greg Kroah-Hartman <gregkh@linuxf=
oundation.org> wrote:
> Description
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> In the Linux kernel, the following vulnerability has been resolved:
>=20
> blk-iocost: Fix an UBSAN shift-out-of-bounds warning
>=20
> 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:
>=20
>   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
>=20
> The underflow itself doesn't really affect the behavior in any meaningful
> way; however, the past timestamp may exaggerate the delay amount calculat=
ed
> 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.
>=20
> 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?

Michal

--knjgfunz3pfevm5m
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQpEWyjXuwGT2dDBqAGvrMr/1gcjgUCZivlsgAKCRAGvrMr/1gc
jjvPAP9KnRcNccTCmxgDKg5Tj4NvHNZdghJaX4/2f56gYlaiXQD+OXKX8jXsywVQ
fCk6Pmj59+Yo5kdLqYxQvYGc5rxxjQo=
=Xtp6
-----END PGP SIGNATURE-----

--knjgfunz3pfevm5m--