* Re: CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning
[not found] <2024040219-CVE-2023-52630-a529@gregkh>
@ 2024-04-26 17:34 ` Michal Koutný
2024-04-30 8:13 ` Greg Kroah-Hartman
0 siblings, 1 reply; 3+ messages in thread
From: Michal Koutný @ 2024-04-26 17:34 UTC (permalink / raw
To: cve, linux-kernel
Cc: linux-cve-announce, Greg Kroah-Hartman, Breno Leitão,
Tejun Heo
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning
2024-04-26 17:34 ` CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning Michal Koutný
@ 2024-04-30 8:13 ` Greg Kroah-Hartman
2024-04-30 8:50 ` Michal Koutný
0 siblings, 1 reply; 3+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-30 8:13 UTC (permalink / raw
To: Michal Koutný
Cc: cve, linux-kernel, linux-cve-announce, Breno Leitão,
Tejun Heo
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Re: CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning
2024-04-30 8:13 ` Greg Kroah-Hartman
@ 2024-04-30 8:50 ` Michal Koutný
0 siblings, 0 replies; 3+ messages in thread
From: Michal Koutný @ 2024-04-30 8:50 UTC (permalink / raw
To: Greg Kroah-Hartman
Cc: cve, linux-kernel, linux-cve-announce, Breno Leitão,
Tejun Heo
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-04-30 8:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <2024040219-CVE-2023-52630-a529@gregkh>
2024-04-26 17:34 ` CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning Michal Koutný
2024-04-30 8:13 ` Greg Kroah-Hartman
2024-04-30 8:50 ` Michal Koutný
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).