Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp142994imm; Tue, 7 Aug 2018 15:42:49 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyUYiKX9HywcquHH0cL6aOz4G6nLg4q8PnI5MBxPEYSdmTK0ZgddFFQWl2ahdMFexnOFwRh X-Received: by 2002:a63:4106:: with SMTP id o6-v6mr208959pga.453.1533681769050; Tue, 07 Aug 2018 15:42:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533681769; cv=none; d=google.com; s=arc-20160816; b=bu8hmwRM9GmEu8A1KIKWuGoGiOEp0zK8JcOGJYuK64AuScKOBp52tRLZO60x2wiVvP Arb58vcSke7o7KHmixnhwFelmylttti0y3VBLrIacyKpy92AgTDNG4P7M6w90WlNmSJW R1OUYlqUWW5YcQA57WDkSUOFI4g+F3WTTvxVLwAQPitQF3CDDTIoTL21A5vumOX/Kw8D u8tFQ3OI5jAQZYVCm/G2CMOxZxqoTRTMZ0Eb1jgHi7mY7S0W27BghqX4XE0TsISB19sE siZ+KUOixfbsII8m4lde1HDzxcN638uUM7fjyD7dXovg6hLB08yRmQrGg85Y3KrvdS5X w10A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=6wcPcEmBrCe30s2P6wP3HU2jjNGByf4NHf5idxVyogQ=; b=0ixbGV0T6PrE9fbJVyVUQg619GrUiviCJf7b7CqJt1znEkP86R844RKCdKI/vK2xd2 umw/hClGW8PMK5KsQjmkYf16fvX8Ber392Ozw4AcSvJhMlrnY/FAE4K4KAkUOSlOeVtr 4oUvdBSqjTE9UgzFkQkjBa95W+64T9PnKRizSqHVYzfNoK3jWVD/8qOgI+OozJbMcuCZ CZ+km0RMivrjjsSnbOi0khbI0IOvcQwbR7JRqXAeccBHvUV0EybonykUIdAxDPjQRrt/ lcV8NzrsA9Jfo7rrONunRVxHmzoG6lROr+Gat8Yh/QE++LHsx8v8vWmpf+G51ViArkUS 8KzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=d5KoyyMd; dkim=pass header.i=@codeaurora.org header.s=default header.b=FUoGYTsT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b16-v6si1930160pgw.478.2018.08.07.15.42.33; Tue, 07 Aug 2018 15:42:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=d5KoyyMd; dkim=pass header.i=@codeaurora.org header.s=default header.b=FUoGYTsT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726873AbeHHA6R (ORCPT + 99 others); Tue, 7 Aug 2018 20:58:17 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:60202 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726672AbeHHA6Q (ORCPT ); Tue, 7 Aug 2018 20:58:16 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 0F3FE60B22; Tue, 7 Aug 2018 22:41:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1533681702; bh=HftTJFQpewgrmnTRTEUtCkT0uj3a1JsncM5on3skTy8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=d5KoyyMdDnScru+cRgqJEEwbFypPXFuyF085I3NJqsOYU/ANQSiABQcS8bmftPVKo BOZashGaBsrfOnL85q+V/q+/vKxMAgGtFCKpx/RWKDlr3IDyIO6kWzybq0kEHgReGT S0Ql7QkNf8/E7DglarSQ/A8HMI5EWxbFmligHzDk= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 305FD60115; Tue, 7 Aug 2018 22:41:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1533681701; bh=HftTJFQpewgrmnTRTEUtCkT0uj3a1JsncM5on3skTy8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FUoGYTsT9manneDd6Rd83yjN4cCuSRn68NscWJT9TgyFpKXKO6IXhJs8nFjnpqEEV JaNyzBxxmN6FH65ya/1UvI9c0lpNSGYtkKQrNKba7kpHQHL+Rgr6xzwTIthoNne3qv aT7s5wrvSB3BsOu4mUH8TVIbArVPAksTA7MzTprA= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 07 Aug 2018 15:41:41 -0700 From: rishabhb@codeaurora.org To: Luis Chamberlain Cc: Mimi Zohar , Bjorn Andersson , ard.biesheuvel@linaro.org, vbabka@suse.cz, riel@surriel.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, ckadabi@codeaurora.org, tsoni@codeaurora.org, psodagud@codeaurora.org, Vikram Mulukutla Subject: Re: [PATCH] firmware: Fix security issue with request_firmware_into_buf() In-Reply-To: References: <1533165956-23727-1-git-send-email-rishabhb@codeaurora.org> Message-ID: X-Sender: rishabhb@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-08-02 14:58, Luis Chamberlain wrote: > On Wed, Aug 1, 2018, 4:26 PM Rishabh Bhatnagar > wrote: > >> When calling request_firmware_into_buf() with the FW_OPT_NOCACHE >> flag >> it is expected that firmware is loaded into buffer from memory. >> But inside alloc_lookup_fw_priv every new firmware that is loaded is >> added to the firmware cache (fwc) list head. So if any driver >> requests >> a firmware that is already loaded the code iterates over the above >> mentioned list and it can end up giving a pointer to other device >> driver's >> firmware buffer. >> Also the existing copy may either be modified by drivers, remote >> processors >> or even freed. This causes a potential security issue with batched >> requests >> when using request_firmware_into_buf. >> >> Fix alloc_lookup_fw_priv to not add to the fwc head list if >> FW_OPT_NOCACHE >> is set, and also don't do the lookup in the list. >> >> Fixes: 0e742e9275 ("firmware: provide infrastructure to make fw >> caching optional") >> >> Signed-off-by: Vikram Mulukutla >> Signed-off-by: Rishabh Bhatnagar >> --- > > Did you test with the tools/testing/selftests/firmware/ scripts? If > not please do so and report back and confirm no regressions are found. > > Brownie points for you to add a test case to show the issue > highlighted in this patch, and which it fixes. I believe this fix > should be pushed to stable, so I'll do that after you confirm no > regressions were found. > > The new selftests changed you'd make would not go to stable, however > there are Linux distributions and 0day that test the latest tools > directory against older kernels. So this test would help capture gaps > later. > > Luis I ran the selftests and observed no regressions with this change. I'm still working on adding a test case though. -Rishabh