linux-kernel - Re: [patch|rfc] mtip32x: fix regression introduced by blk-mq per-hctx flush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 05 Aug 2015 16:44:24 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	Ming Lei <ming.lei@...onical.com>,
	Sam Bradshaw <sbradshaw@...ron.com>,
	Asai Thambi SP <asamymuthupa@...ron.com>,
	linux-kernel@...r.kernel.org, dmilburn@...hat.com
Subject: Re: [patch|rfc] mtip32x: fix regression introduced by blk-mq per-hctx flush

Jens Axboe <axboe@...nel.dk> writes:

> On 07/29/2015 08:22 AM, Jeff Moyer wrote:
>> Hi,
>>
>> After commit f70ced091707 (blk-mq: support per-distpatch_queue flush
>> machinery), the mtip32xx driver may oops upon module load due to walking
>> off the end of an array in mtip_init_cmd.  On initialization of the
>> flush_rq, init_request is called with request_index >= the maximum queue
>> depth the driver supports.  For mtip32xx, this value is used to index
>> into an array.  What this means is that the driver will walk off the end
>> of the array, and either oops or cause random memory corruption.
>>
>> The problem is easily reproduced by doing modprobe/rmmod of the mtip32xx
>> driver in a loop.  I can typically reproduce the problem in about 30
>> seconds.
>>
>> Now, in the case of mtip32xx, it actually doesn't support flush/fua, so
>> I think we can simply return without doing anything.  In addition, no
>> other mq-enabled driver does anything with the request_index passed into
>> init_request(), so no other driver is affected.  However, I'm not really
>> sure what is expected of drivers.  Ming, what did you envision drivers
>> would do when initializing the flush requests?
>
> This is really a bug in the core, we should not have to work around
> this in the driver. I'll take a look at this.

Hi, Jens,

Any update on this?

-Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/