CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning

CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning

[Greg Kroah-Hartman]

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.

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.
Let's bail early from iocg_kick_delay() in such cases.

The Linux kernel CVE team has assigned CVE-2023-52630 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.10 with commit 5160a5a53c0c and fixed in 5.10.210 with commit 9f56f3833117
	Issue introduced in 5.10 with commit 5160a5a53c0c and fixed in 5.15.149 with commit 1e4d3f8bd880
	Issue introduced in 5.10 with commit 5160a5a53c0c and fixed in 6.1.78 with commit e5dc63f01e02
	Issue introduced in 5.10 with commit 5160a5a53c0c and fixed in 6.6.17 with commit 27b216130e64
	Issue introduced in 5.10 with commit 5160a5a53c0c and fixed in 6.7.5 with commit cd33b330cb21
	Issue introduced in 5.10 with commit 5160a5a53c0c and fixed in 6.8 with commit 2a427b49d029

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-52630
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	block/blk-iocost.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/9f56f38331171c9a19754004f0664686d67ee48d
	https://git.kernel.org/stable/c/1e4d3f8bd880e02932a9ea179f90bfa74fd2e899
	https://git.kernel.org/stable/c/e5dc63f01e027721c29f82069f7e97e2149fa131
	https://git.kernel.org/stable/c/27b216130e64651e76ed583742a1b4e4d08a67c3
	https://git.kernel.org/stable/c/cd33b330cb21675189e747953845f5c3689e4912
	https://git.kernel.org/stable/c/2a427b49d02995ea4a6ff93a1432c40fa4d36821

Re: CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

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?

Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning

[Greg Kroah-Hartman]

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

Re: Re: CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning

[Michal Koutný]

[-- Attachment #1: Type: text/plain, Size: 201 bytes --]

On Tue, Apr 30, 2024 at 10:13:10AM +0200, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> Makes sense, thanks for looking into this, and sorry for the delay.  Now
> rejected.

Thanks!

Michal

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]