Messages in this thread | | | Date | Tue, 30 Apr 2024 10:13:10 +0200 | From | Greg Kroah-Hartman <> | Subject | Re: CVE-2023-52630: blk-iocost: Fix an UBSAN shift-out-of-bounds warning |
| |
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
| |