From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 189CCC4360C for ; Sun, 6 Oct 2019 10:48:54 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8C7922084D for ; Sun, 6 Oct 2019 10:48:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="JJ29wgZW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C7922084D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 654B115E0; Sun, 6 Oct 2019 12:48:01 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 654B115E0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1570358931; bh=rAImRNYiTmTeHny0UxONJOk6+Kkqv+ot4N8HrK4nwi4=; h=Date:From:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From; b=JJ29wgZWGYsVWFt1bpu7qZMJ9Wzm2kVCu7oohM/2CemzYgLznfS6C2/zG5uIf/L6z Thyr6L9TAkJ131HHOCtz4Gl9COI6FSmYmTKObrnpgo5ZvsM5iOmZihDThz1J/O8WTw P+dD1qtvH9U+UGF24DnUQ87ElY3wl86urMD8L7Qs= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 0194BF804CA; Sun, 6 Oct 2019 12:47:25 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 904F3F804CB; Sun, 6 Oct 2019 12:47:22 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 1A28BF80308 for ; Sun, 6 Oct 2019 12:47:19 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 1A28BF80308 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2019 03:47:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,263,1566889200"; d="scan'208";a="192019190" Received: from gliakhov-mobl2.ger.corp.intel.com (HELO ubuntu) ([10.252.41.73]) by fmsmga008.fm.intel.com with ESMTP; 06 Oct 2019 03:47:16 -0700 Date: Sun, 6 Oct 2019 12:47:15 +0200 From: Guennadi Liakhovetski To: alsa-devel@alsa-project.org Message-ID: <20191006104715.GA14691@ubuntu> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Subject: [alsa-devel] what's the kernel policy WRT firmware parsing security? X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Hi, I decided to have a look at whether the ALSA topology parsing is bullet proof against malformed topology files. It seems not quite to be the case. At least I seem to have found a possibility of crashing the kernel by a malformed topology file. I haven't tested it, so, maybe I'm wrong. In principle, firmware files can only be written by root, and if you have root access to the system, it's anyway doomed. Is this the approach and we aren't really trying to make topology parsing 100% safe, or do we want to fix any such possible parsing issues? Thanks Guennadi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel