From patchwork Tue Apr 17 22:57:08 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 10347027 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CE37F60542 for ; Tue, 17 Apr 2018 22:57:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CE23927F8C for ; Tue, 17 Apr 2018 22:57:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C2FFE27FA5; Tue, 17 Apr 2018 22:57:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3B37627F8C for ; Tue, 17 Apr 2018 22:57:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752806AbeDQW5Q (ORCPT ); Tue, 17 Apr 2018 18:57:16 -0400 Received: from mail-pg0-f41.google.com ([74.125.83.41]:44732 "EHLO mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752707AbeDQW5O (ORCPT ); Tue, 17 Apr 2018 18:57:14 -0400 Received: by mail-pg0-f41.google.com with SMTP id l12so3446083pgp.11 for ; Tue, 17 Apr 2018 15:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=l2ZJAUQKw5qSZoKvIGmrioc33cGUi3Kb6UQL145DRt4=; b=a5ZuFclpW5CjWjS6E9GjXdxkS+2yDKU7f9f/o1UsrY6Y3/93W4VIUr+5FNFoj+qKtr CjTmz+QhJakTdBld5dWdu3RRu2aP3sJdO56ljdTo2VwBurY+tnKXE6TqwGKUl2gd7zXR BSHm2p1XGuGCnvGWnVZ2finvtCKJlISVPT+0zbCrQwlqisxBRIEWNyzFRQUBrr4rzhwZ 1tPhcZxJhxhHdRjh4FArXXQmQm63vb4OKXKj2xZueewvOTUfYpowwdp1LVEe7Sr37GUZ G1vQubhYbjxUkGNHq/M5fEghgnxSLyFd/QuZAT58kCpJYMQHDcAWPAgzh/DtyXFzjRY5 vAfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=l2ZJAUQKw5qSZoKvIGmrioc33cGUi3Kb6UQL145DRt4=; b=Vl5a+mJJIGGIl2YGkRIppSmveflCp3WUzBX/QdjiilVgGERd9Khq7wzO6q4s/hdpfl yPiMM25eC7JyHIoUhBqplcA70GOwub9GAPO0Rb8bbIrBBQXZrUwQjKVurngyczu00M28 Y0BoVAZUumL58eABPFeXJU1Iv2/cEJp2fenBnwgCO1uVgdcWjIeOx8e6QQj1mBdv2Un6 kmA/zKAY+eI5KLe2l2hzJsxQ4g4pFW4CvucX8H8zv9VgsuVuvUmItze1NlJpdFlVM6ST xG48AVIPh5eDwyPCtKN4liN14yZJ1ni5iZWqPt0CHPR3DRH+CeFBcRHXLM+Rn7JzKXOI CH7A== X-Gm-Message-State: ALQs6tBOZkXiavZCaI3AmT8LbXbZDAB7/ADmiaBxyzSOLR5RscET/4vn v6g8mR/yEGBJ//7jGkk7Wd7svg== X-Google-Smtp-Source: AIpwx4+tLAO9jKYHm+wTqCNAF1Ha4vki8plMJiApQ6xB3H8LxLwvRclW6AQhfJbK2ibjDpmWOMhBYw== X-Received: by 10.101.82.133 with SMTP id y5mr3201131pgp.27.1524005832957; Tue, 17 Apr 2018 15:57:12 -0700 (PDT) Received: from [192.168.1.211] (107.191.0.158.static.utbb.net. [107.191.0.158]) by smtp.gmail.com with ESMTPSA id t137sm30116351pgc.16.2018.04.17.15.57.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 15:57:10 -0700 (PDT) Subject: Re: usercopy whitelist woe in scsi_sense_cache From: Jens Axboe To: Kees Cook Cc: Paolo Valente , Oleksandr Natalenko , Bart Van Assche , David Windsor , "James E.J. Bottomley" , "Martin K. Petersen" , linux-scsi@vger.kernel.org, LKML , Christoph Hellwig , Hannes Reinecke , Johannes Thumshirn , linux-block@vger.kernel.org References: <10360653.ov98egbaqx@natalenko.name> <2864697.7uzmEJovl2@natalenko.name> <8473f909-2123-0cfc-43b1-beba0b1aef9b@kernel.dk> <07f263ff-cea6-ac3c-944b-0f36fee8ba25@kernel.dk> <8b32e079-d4e6-3fea-a89d-ff856e4e13b1@kernel.dk> Message-ID: <0fbf2b13-8bae-c7c5-d930-ebaafdc72202@kernel.dk> Date: Tue, 17 Apr 2018 16:57:08 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <8b32e079-d4e6-3fea-a89d-ff856e4e13b1@kernel.dk> Content-Language: en-US Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 4/17/18 3:48 PM, Jens Axboe wrote: > On 4/17/18 3:47 PM, Kees Cook wrote: >> On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe wrote: >>> On 4/17/18 3:25 PM, Kees Cook wrote: >>>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook wrote: >>>>> I see elv.priv[1] assignments made in a few places -- is it possible >>>>> there is some kind of uninitialized-but-not-NULL state that can leak >>>>> in there? >>>> >>>> Got it. This fixes it for me: >>>> >>>> diff --git a/block/blk-mq.c b/block/blk-mq.c >>>> index 0dc9e341c2a7..859df3160303 100644 >>>> --- a/block/blk-mq.c >>>> +++ b/block/blk-mq.c >>>> @@ -363,7 +363,7 @@ static struct request *blk_mq_get_request(struct >>>> request_queue *q, >>>> >>>> rq = blk_mq_rq_ctx_init(data, tag, op); >>>> if (!op_is_flush(op)) { >>>> - rq->elv.icq = NULL; >>>> + memset(&rq->elv, 0, sizeof(rq->elv)); >>>> if (e && e->type->ops.mq.prepare_request) { >>>> if (e->type->icq_cache && rq_ioc(bio)) >>>> blk_mq_sched_assign_ioc(rq, bio); >>>> @@ -461,7 +461,7 @@ void blk_mq_free_request(struct request *rq) >>>> e->type->ops.mq.finish_request(rq); >>>> if (rq->elv.icq) { >>>> put_io_context(rq->elv.icq->ioc); >>>> - rq->elv.icq = NULL; >>>> + memset(&rq->elv, 0, sizeof(rq->elv)); >>>> } >>>> } >>> >>> This looks like a BFQ problem, this should not be necessary. Paolo, >>> you're calling your own prepare request handler from the insert >>> as well, and your prepare request does nothing if rq->elv.icq == NULL. >> >> I sent the patch anyway, since it's kind of a robustness improvement, >> I'd hope. If you fix BFQ also, please add: > > It's also a memset() in the hot path, would prefer to avoid that... > The issue here is really the convoluted bfq usage of insert/prepare, > I'm sure Paolo can take it from here. Does this fix it? diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index f0ecd98509d8..d883469a1582 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -4934,8 +4934,11 @@ static void bfq_prepare_request(struct request *rq, struct bio *bio) bool new_queue = false; bool bfqq_already_existing = false, split = false; - if (!rq->elv.icq) + if (!rq->elv.icq) { + rq->elv.priv[0] = rq->elv.priv[1] = NULL; return; + } + bic = icq_to_bic(rq->elv.icq); spin_lock_irq(&bfqd->lock);