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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DDA3C433EF for ; Tue, 19 Apr 2022 13:08:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349864AbiDSNKu (ORCPT ); Tue, 19 Apr 2022 09:10:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229483AbiDSNKr (ORCPT ); Tue, 19 Apr 2022 09:10:47 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E9962B18B for ; Tue, 19 Apr 2022 06:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650373681; x=1681909681; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=i7kopf3YArKvjboCT3liagNNqNzvCwqxIhyPrNCjFeU=; b=GEv7cr/ARIDonaJd/1WdnhStCep/zoCGWPoO645fbB//9UmGG8civ6bV ea57FHgJ6YcV2ds96k4y+5BXUKDpyBnez5RitzUD0C7N5ErYIErDe186E r7X52lC48fsPnY+xDIieZb4Xkwt0r//AjEcUBL4Uz/uorD8p69zKTNmhv LgkBKvE3QuW8C8b46dJT2EzYPEGzQO5pKZ5RRKs1ZzlND5jSwSdKUz9cd s7+n0t+3LKk7jhJXzCh6elJOWmfX9KOJ6nuHmVJcklgoKpbYoniAAk/HT HmXjA/NFbFdOz4kxJUN8U3+uJmF+g60Q+DPCnPsj8/4rgbGbsEgu5i1qv g==; X-IronPort-AV: E=McAfee;i="6400,9594,10321"; a="262618207" X-IronPort-AV: E=Sophos;i="5.90,272,1643702400"; d="scan'208";a="262618207" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 06:08:00 -0700 X-IronPort-AV: E=Sophos;i="5.90,272,1643702400"; d="scan'208";a="554720563" Received: from kkho1-mobl3.amr.corp.intel.com (HELO [10.209.54.209]) ([10.209.54.209]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 06:07:59 -0700 Message-ID: Date: Tue, 19 Apr 2022 08:07:58 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Subject: Re: out-of-bounds access in sound/soc/sof/topology.c Content-Language: en-US To: =?UTF-8?Q?P=c3=a9ter_Ujfalusi?= , Sergey Senozhatsky , Liam Girdwood , Ranjani Sridharan , Kai Vehmanen , Jaska Uimonen Cc: alsa-devel@alsa-project.org, Takashi Iwai , linux-kernel@vger.kernel.org, Tomasz Figa , Mark Brown , Ricardo Ribalda , sound-open-firmware@alsa-project.org References: <8eeb08ec-4836-cf7d-2285-8ed74ccfc1cb@linux.intel.com> <8986a1c6-b546-7a66-a778-048487624c95@linux.intel.com> From: Pierre-Louis Bossart In-Reply-To: <8986a1c6-b546-7a66-a778-048487624c95@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/19/22 06:50, Péter Ujfalusi wrote: > Hi Sergey, Pierre, > > On 15/04/2022 19:00, Pierre-Louis Bossart wrote: >> Thanks Sergey for this email. >> >> On 4/15/22 04:23, Sergey Senozhatsky wrote: >>> Hi, >>> >>> I'm running 5.10.111 LTS, so if this has been fixed already then we definitely >>> want to cherry pick the fix for -stable. > > I'm afraid, that this is still valid as of today, but in real life I > don't think it can happen. > >>> Anonymous union in this struct is of zero size >>> >>> /* generic control data */ >>> struct sof_ipc_ctrl_data { >>> struct sof_ipc_reply rhdr; >>> uint32_t comp_id; >>> >>> /* control access and data type */ >>> uint32_t type; /**< enum sof_ipc_ctrl_type */ >>> uint32_t cmd; /**< enum sof_ipc_ctrl_cmd */ >>> uint32_t index; /**< control index for comps > 1 control */ >>> >>> /* control data - can either be appended or DMAed from host */ >>> struct sof_ipc_host_buffer buffer; >>> uint32_t num_elems; /**< in array elems or bytes for data type */ >>> uint32_t elems_remaining; /**< elems remaining if sent in parts */ >>> >>> uint32_t msg_index; /**< for large messages sent in parts */ >>> >>> /* reserved for future use */ >>> uint32_t reserved[6]; >>> >>> /* control data - add new types if needed */ >>> union { >>> /* channel values can be used by volume type controls */ >>> struct sof_ipc_ctrl_value_chan chanv[0]; >>> /* component values used by routing controls like mux, mixer */ >>> struct sof_ipc_ctrl_value_comp compv[0]; >>> /* data can be used by binary controls */ >>> struct sof_abi_hdr data[0]; >>> }; >>> } __packed; >>> >>> sof_ipc_ctrl_value_chan and sof_ipc_ctrl_value_comp are of the same >>> size - 8 bytes, while sof_abi_hdr is much larger - _at least_ 32 bytes >>> (`__u32 data[0]` in sof_abi_hdr suggest that there should be more >>> payload after header). But they all contribute 0 to sizeof(sof_ipc_ctrl_data). >>> >>> Now control data allocations looks as follows >>> >>> scontrol->size = struct_size(scontrol->control_data, chanv, >>> le32_to_cpu(mc->num_channels)); >>> scontrol->control_data = kzalloc(scontrol->size, GFP_KERNEL); >>> >>> Which is sizeof(sof_ipc_ctrl_data) + mc->num_channels * sizeof(sof_ipc_ctrl_value_chan) >>> >>> For some reason it uses sizeof(sof_ipc_ctrl_value_chan), which is not >>> the largest member of the union. >>> >>> And this is where the problem is: in order to make control->data.FOO loads >>> and stores legal we need mc->num_channels to be of at least 4. So that >>> >>> sizeof(sof_ipc_ctrl_data) + mc->num_channels * sizeof(sof_ipc_ctrl_value_chan) >>> >>> 92 + 4 * 8 >>> >>> will be the same as >>> >>> sizeof(sof_ipc_ctrl_data) + sizeof(sof_abi_hdr). >>> >>> 92 + 32 >>> >>> Otherwise scontrol->control_data->data.FOO will access nearby/foreign >>> slab object. >>> >>> And there is at least one such memory access. In sof_get_control_data(). >>> >>> wdata[i].pdata = wdata[i].control->control_data->data; >>> *size += wdata[i].pdata->size; >>> >>> >>> pdata->size is at offset 8, but if, say, mc->num_channels == 1 then >>> we allocate only 8 bytes for pdata, so pdata->size is 4 bytes outside >>> of allocated slab object. >>> >>> Thoughts? > > Your analyzes are spot on, unfortunately. But... > > As of today, the sof_get_control_data() is in the call path of > (ipc3-topology.c): > > sof_widget_update_ipc_comp_process() -> sof_process_load() -> > sof_get_control_data() > > sof_widget_update_ipc_comp_process() is the ipc_setup callback for > snd_soc_dapm_effect. If I'm not mistaken these only carries bin payload > and never MIXER/ENUM/SWITCH/VOLUME. > This means that the sof_get_control_data() is only called with > SND_SOC_TPLG_TYPE_BYTES and for that the allocated data area is correct. > > This can explain why we have not seen any issues so far. This does not > renders the code right, as how it is written atm is wrong. Sergey's results with KASAN show that there's a real-life problem though. I also don't understand how that might happen. Could it be that these results are with a specific topology where our assumptions are incorrect? 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id DA62CC433EF for ; Tue, 19 Apr 2022 13:09:06 +0000 (UTC) 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 C6FF61895; Tue, 19 Apr 2022 15:08:14 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz C6FF61895 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1650373744; bh=i7kopf3YArKvjboCT3liagNNqNzvCwqxIhyPrNCjFeU=; h=Date:Subject:To:References:From:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=l/tyfpj3cFy6xoSNgF4aT61r1O03MiqJmdeKMcyLPq7oBEYxJjig3bSHRsVZUKPQq 5ONgA81R1eOnRFxpzK7MHBw+cuaefCaK93L/gSunpxUqkTXH+h2+8vc+Gqx8NH9Iya ML+JrmA1hrN75hwpzuPyuI9/9ziPAjlhGu7NKnD8= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 55CD0F80237; Tue, 19 Apr 2022 15:08:14 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id DF326F80121; Tue, 19 Apr 2022 15:08:12 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 2E73FF80121; Tue, 19 Apr 2022 15:08:02 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 2E73FF80121 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="FaYZh2eD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650373689; x=1681909689; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=i7kopf3YArKvjboCT3liagNNqNzvCwqxIhyPrNCjFeU=; b=FaYZh2eDDA3zMpaEA0dbxW2Q1SsFUjCfKvas4N+hPuQD/6deolzBXzqX jewqKGpX6T8frpEz7Eb/qmTqdnUYPOoZNNNJOmH7v8bt/1dGhGqGWIw6l PwGnoZUyFfZKyNqZ7xWYgGS/yOoa9tYwvRnNS5zbXvWwPTB9zZ8XOHbqS pMzxZd7dxCTIWdtnbCZi63WoRci/5QahT87J/vncWmvMjHz9j/m0EK3o9 xRZpAbZOrY3vRwGrCh+dwZm6KRa1K8nvJgFJea7nHmDog1976ymgw4sQs 39lLXdpmFs+kWBXsi0yiQVzjwhMaXOAadkdYwG0QeqnyFyFGKMFC31nxh g==; X-IronPort-AV: E=McAfee;i="6400,9594,10321"; a="244344489" X-IronPort-AV: E=Sophos;i="5.90,272,1643702400"; d="scan'208";a="244344489" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 06:08:00 -0700 X-IronPort-AV: E=Sophos;i="5.90,272,1643702400"; d="scan'208";a="554720563" Received: from kkho1-mobl3.amr.corp.intel.com (HELO [10.209.54.209]) ([10.209.54.209]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 06:07:59 -0700 Message-ID: Date: Tue, 19 Apr 2022 08:07:58 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Subject: Re: out-of-bounds access in sound/soc/sof/topology.c Content-Language: en-US To: =?UTF-8?Q?P=c3=a9ter_Ujfalusi?= , Sergey Senozhatsky , Liam Girdwood , Ranjani Sridharan , Kai Vehmanen , Jaska Uimonen References: <8eeb08ec-4836-cf7d-2285-8ed74ccfc1cb@linux.intel.com> <8986a1c6-b546-7a66-a778-048487624c95@linux.intel.com> From: Pierre-Louis Bossart In-Reply-To: <8986a1c6-b546-7a66-a778-048487624c95@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, Takashi Iwai , Tomasz Figa , Mark Brown , Ricardo Ribalda , sound-open-firmware@alsa-project.org 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: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On 4/19/22 06:50, Péter Ujfalusi wrote: > Hi Sergey, Pierre, > > On 15/04/2022 19:00, Pierre-Louis Bossart wrote: >> Thanks Sergey for this email. >> >> On 4/15/22 04:23, Sergey Senozhatsky wrote: >>> Hi, >>> >>> I'm running 5.10.111 LTS, so if this has been fixed already then we definitely >>> want to cherry pick the fix for -stable. > > I'm afraid, that this is still valid as of today, but in real life I > don't think it can happen. > >>> Anonymous union in this struct is of zero size >>> >>> /* generic control data */ >>> struct sof_ipc_ctrl_data { >>> struct sof_ipc_reply rhdr; >>> uint32_t comp_id; >>> >>> /* control access and data type */ >>> uint32_t type; /**< enum sof_ipc_ctrl_type */ >>> uint32_t cmd; /**< enum sof_ipc_ctrl_cmd */ >>> uint32_t index; /**< control index for comps > 1 control */ >>> >>> /* control data - can either be appended or DMAed from host */ >>> struct sof_ipc_host_buffer buffer; >>> uint32_t num_elems; /**< in array elems or bytes for data type */ >>> uint32_t elems_remaining; /**< elems remaining if sent in parts */ >>> >>> uint32_t msg_index; /**< for large messages sent in parts */ >>> >>> /* reserved for future use */ >>> uint32_t reserved[6]; >>> >>> /* control data - add new types if needed */ >>> union { >>> /* channel values can be used by volume type controls */ >>> struct sof_ipc_ctrl_value_chan chanv[0]; >>> /* component values used by routing controls like mux, mixer */ >>> struct sof_ipc_ctrl_value_comp compv[0]; >>> /* data can be used by binary controls */ >>> struct sof_abi_hdr data[0]; >>> }; >>> } __packed; >>> >>> sof_ipc_ctrl_value_chan and sof_ipc_ctrl_value_comp are of the same >>> size - 8 bytes, while sof_abi_hdr is much larger - _at least_ 32 bytes >>> (`__u32 data[0]` in sof_abi_hdr suggest that there should be more >>> payload after header). But they all contribute 0 to sizeof(sof_ipc_ctrl_data). >>> >>> Now control data allocations looks as follows >>> >>> scontrol->size = struct_size(scontrol->control_data, chanv, >>> le32_to_cpu(mc->num_channels)); >>> scontrol->control_data = kzalloc(scontrol->size, GFP_KERNEL); >>> >>> Which is sizeof(sof_ipc_ctrl_data) + mc->num_channels * sizeof(sof_ipc_ctrl_value_chan) >>> >>> For some reason it uses sizeof(sof_ipc_ctrl_value_chan), which is not >>> the largest member of the union. >>> >>> And this is where the problem is: in order to make control->data.FOO loads >>> and stores legal we need mc->num_channels to be of at least 4. So that >>> >>> sizeof(sof_ipc_ctrl_data) + mc->num_channels * sizeof(sof_ipc_ctrl_value_chan) >>> >>> 92 + 4 * 8 >>> >>> will be the same as >>> >>> sizeof(sof_ipc_ctrl_data) + sizeof(sof_abi_hdr). >>> >>> 92 + 32 >>> >>> Otherwise scontrol->control_data->data.FOO will access nearby/foreign >>> slab object. >>> >>> And there is at least one such memory access. In sof_get_control_data(). >>> >>> wdata[i].pdata = wdata[i].control->control_data->data; >>> *size += wdata[i].pdata->size; >>> >>> >>> pdata->size is at offset 8, but if, say, mc->num_channels == 1 then >>> we allocate only 8 bytes for pdata, so pdata->size is 4 bytes outside >>> of allocated slab object. >>> >>> Thoughts? > > Your analyzes are spot on, unfortunately. But... > > As of today, the sof_get_control_data() is in the call path of > (ipc3-topology.c): > > sof_widget_update_ipc_comp_process() -> sof_process_load() -> > sof_get_control_data() > > sof_widget_update_ipc_comp_process() is the ipc_setup callback for > snd_soc_dapm_effect. If I'm not mistaken these only carries bin payload > and never MIXER/ENUM/SWITCH/VOLUME. > This means that the sof_get_control_data() is only called with > SND_SOC_TPLG_TYPE_BYTES and for that the allocated data area is correct. > > This can explain why we have not seen any issues so far. This does not > renders the code right, as how it is written atm is wrong. Sergey's results with KASAN show that there's a real-life problem though. I also don't understand how that might happen. Could it be that these results are with a specific topology where our assumptions are incorrect?