Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp3855462pxb; Mon, 27 Sep 2021 04:19:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyiOIye9GKyTBEv8ScG9GD1N/CryYF2oME5o7mRHuB5iaUQA2R1QLNsGZX/lv7qgWjdHKCH X-Received: by 2002:a05:6402:5171:: with SMTP id d17mr4676896ede.364.1632741540534; Mon, 27 Sep 2021 04:19:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632741540; cv=none; d=google.com; s=arc-20160816; b=OracXaMvYvpDe1HoHkCxq/D0KiUs8cMqBkYf9CB39Ti/AD0lBCs2Aj8E+DEqzRX3Ki F10VknKXehUP/89L88SLaEM6VR0z87vqimqQLpJRT0KqqfN2cHYqO0cOsBQQSDpes1A+ XliCmz/Lh0507zGP58myXArCW9xbtVHzLsnYU4vlGaH36bzmwuWRalp5Wixhnk+1+ufL sCTQAiBBDFcXMPPBJn+oo/j9AsvIyOO1h+5wQDq6IvvXiyqrEGd3e04klgq7SwmLdzkN AeLuCpE8GP7OupoqLdTc/G3LNOskCxxmi4cuHHC5rjdSJexHFqUWDbzX6GUlJbxsUVTg xaBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=lEWRfJ43agQ+Zsa7cE7YrLRAgFkXthq60FLY7XvZ/6I=; b=oEmZJjZ0f0w33YrlJnSsGuaqLSX8m10c+HJUpbmQgCVRBbxYfvL+gwFGzoC6sGDIap xxb05s4KveaLU+9HGVTBod2YDtrepTF2z7273GQi6YDJ1JBZtAcvKMhUWXBhyudd/Asi HtXk9MF4N2s9jvv5sBYNv0fXyTUn6waytVG/mJivA4SauKU2tQ3ZKnb65Rp0yWfo5xQS vrPkXLgAk6YOitxhzwdvbIfqhlNSukkUaILb0JrRvb3bK1CckeircSaXqhwDyOjimcY3 BPvTUoEI9yipZ7L2sZn1o75p56g7N+aaVx5Gy6nG+mgSRTf0TwTBnrvmvy7yz35AIoid hX6g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hh20si14782266ejb.10.2021.09.27.04.18.36; Mon, 27 Sep 2021 04:19:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233995AbhI0LSl (ORCPT + 99 others); Mon, 27 Sep 2021 07:18:41 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:56967 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233970AbhI0LSk (ORCPT ); Mon, 27 Sep 2021 07:18:40 -0400 Received: from fsav411.sakura.ne.jp (fsav411.sakura.ne.jp [133.242.250.110]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 18RBH0N1054907; Mon, 27 Sep 2021 20:17:00 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav411.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav411.sakura.ne.jp); Mon, 27 Sep 2021 20:17:00 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav411.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 18RBH0Yq054885 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Sep 2021 20:17:00 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH] loop: avoid out-of-range warning To: Martijn Coenen , Arnd Bergmann Cc: Jens Axboe , Nathan Chancellor , Nick Desaulniers , Arnd Bergmann , Dan Schatzberg , linux-block , LKML , llvm@lists.linux.dev References: <20210927094327.644665-1-arnd@kernel.org> From: Tetsuo Handa Message-ID: <755aa284-06f4-ee10-ec7b-0f69a1617349@i-love.sakura.ne.jp> Date: Mon, 27 Sep 2021 20:16:59 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Well, you found a bug here. lo_simple_ioctl(LOOP_SET_BLOCK_SIZE) passes "unsigned long arg" to loop_validate_block_size() via loop_set_block_size(), and uses only lower 32bits. "(lo->lo_queue->limits.logical_block_size == arg)" is failing to "return 0;" if lower 32bits are the same but higher 32bits are not 0. Shouldn't we also check that higher 32bits are 0, by either making loop_validate_block_size() to accept "unsigned long" or making loop_set_block_size() return -EINVAL if larger than UINT_MAX ? > There is nothing wrong here, so just shut up the check by changing > the type of the bsize argument. I think there is something wrong here. Since "unsigned short bsize" checked only lower 16bits, a fuzzer can pass e.g. 0xDEAD0200 (which is not a is_power_of_2() 32bits value) to blk_queue_logical_block_size(lo->lo_queue, arg); blk_queue_physical_block_size(lo->lo_queue, arg); blk_queue_io_min(lo->lo_queue, arg); and confuse the system?