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 AF4AEC19F21 for ; Wed, 27 Jul 2022 05:25:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232226AbiG0FZk (ORCPT ); Wed, 27 Jul 2022 01:25:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229507AbiG0FZi (ORCPT ); Wed, 27 Jul 2022 01:25:38 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D981B3DBC3 for ; Tue, 26 Jul 2022 22:25:35 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1FA0820156; Wed, 27 Jul 2022 05:25:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1658899534; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bdqmQ5p2ejZx38NuBZXzRSiBR0XeVRrw8M3dUjIZMMw=; b=UvMxtc8LNEj6R91u/dPgYCdwo81tvHkxZHFcc5ChPMt6KGXFEh5ZazTsiTYgGUUKdht70S ZBNK/V/prwer8fk6Ef/L4arzxq/Ejb6ovKOUj1HeVWAiwaHJSxXcQJ3L6UXVvE7CjDUuXU RpocNP/tRbeaUhXCsyS54EiRHL5+37Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1658899534; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bdqmQ5p2ejZx38NuBZXzRSiBR0XeVRrw8M3dUjIZMMw=; b=yu0yTJPq1NYJt+Rw/fdkL6xr9Uq6K6UfnKT1yAWtwPbiJDzGYALauCC7nIMWm1vfVPDOmg /+0lxs6uQVVERHBA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id D9A8213A7C; Wed, 27 Jul 2022 05:25:33 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id bFNyNE3M4GJjZQAAMHmgww (envelope-from ); Wed, 27 Jul 2022 05:25:33 +0000 Date: Wed, 27 Jul 2022 07:25:33 +0200 Message-ID: <87tu73p1o2.wl-tiwai@suse.de> From: Takashi Iwai To: Dipanjan Das Cc: Greg KH , perex@perex.cz, tiwai@suse.com, consult.awy@gmail.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, syzkaller@googlegroups.com, fleischermarius@googlemail.com, its.priyanka.bose@gmail.com Subject: Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params In-Reply-To: References: <874jz82kx0.wl-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 26 Jul 2022 23:40:48 +0200, Dipanjan Das wrote: > > On Sat, Jul 23, 2022 at 3:17 AM Takashi Iwai wrote: > > > > On Sat, 23 Jul 2022 09:00:08 +0200, > > Greg KH wrote: > > > > > > Wondeful, do you have a fix for this that solves the reported problem > > > that you have tested with the reproducer? > > > > ... or at least more detailed information. > > Here is our analysis of the bug in the kernel v5.10.131. > > During allocation, the `size` of the DMA buffer is not page-aligned: > https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/memalloc.c#L149. > However, in sound/core/pcm_native.c:798 > (https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/pcm_native.c#L798), > the `size` variable is page-aligned before memset-ing the `dma_area`. > >From the other BUG_ON assertions in other parts of the code, it looks > like the DMA area is not supposed to be equal to or greater than > 0x200000 bytes. However, due to page-alignment, the `size` can indeed > get rounded up to 0x200000 which causes the out of bound access. > > > Last but not least, you should check whether it's specific to your > > 5.10.x kernel or it's also seen with the latest upstream, too. > > The bug is not reproducible on the latest mainline, because in > sound/core/memalloc.c:66 > (https://github.com/torvalds/linux/blob/5de64d44968e4ae66ebdb0a2d08b443f189d3651/sound/core/memalloc.c#L66) > the allocation function `snd_dma_alloc_dir_pages()` now page-aligns > the `size` right before allocating the DMA buffer. Therefore, any > subsequent page-alignment, like the one in `snd_pcm_hw_params()` does > not cause an out of bound access. Thanks for the analysis. A good news is that, at least for the vmalloc() case, it's a kind of false-positive; vmalloc() always takes the full pages, so practically seen, the size is page-aligned. It's fooling the memory checker, though. But the similar problem could be seen with genalloc calls, and this was fixed by the upstream commit 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e ALSA: memalloc: Align buffer allocations in page size I suppose you can simply backport this commit to 5.10.y. Could you confirm that this fixes your problem? thanks, Takashi 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 9F2C0C19F21 for ; Wed, 27 Jul 2022 05:26:40 +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 F35E984B; Wed, 27 Jul 2022 07:25:47 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz F35E984B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1658899598; bh=sVh6ABbamvq3k6yhY+MCoVBwmnUR+u9St2BDuFh3xS0=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Udc4DiBeP9gNYDNpIuXcp5i8+BuuLB7751Qxx1kssHbkNKYyJQqsUczdwV5HJIx0R bahx/8lbJDGJU2XViU5vAmANcAB5DaVj9aqJ/2FbDiOfWugPb+tEWKtkadWGCH+VNL LzepFMgz32xJpL2NSpoC/JGJ4Ovg55JRHeLkvXlM= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 4B5C2F80155; Wed, 27 Jul 2022 07:25:47 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 247F7F8015B; Wed, 27 Jul 2022 07:25:45 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 0A5BFF800FA for ; Wed, 27 Jul 2022 07:25:36 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 0A5BFF800FA Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="UvMxtc8L"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="yu0yTJPq" Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1FA0820156; Wed, 27 Jul 2022 05:25:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1658899534; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bdqmQ5p2ejZx38NuBZXzRSiBR0XeVRrw8M3dUjIZMMw=; b=UvMxtc8LNEj6R91u/dPgYCdwo81tvHkxZHFcc5ChPMt6KGXFEh5ZazTsiTYgGUUKdht70S ZBNK/V/prwer8fk6Ef/L4arzxq/Ejb6ovKOUj1HeVWAiwaHJSxXcQJ3L6UXVvE7CjDUuXU RpocNP/tRbeaUhXCsyS54EiRHL5+37Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1658899534; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bdqmQ5p2ejZx38NuBZXzRSiBR0XeVRrw8M3dUjIZMMw=; b=yu0yTJPq1NYJt+Rw/fdkL6xr9Uq6K6UfnKT1yAWtwPbiJDzGYALauCC7nIMWm1vfVPDOmg /+0lxs6uQVVERHBA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id D9A8213A7C; Wed, 27 Jul 2022 05:25:33 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id bFNyNE3M4GJjZQAAMHmgww (envelope-from ); Wed, 27 Jul 2022 05:25:33 +0000 Date: Wed, 27 Jul 2022 07:25:33 +0200 Message-ID: <87tu73p1o2.wl-tiwai@suse.de> From: Takashi Iwai To: Dipanjan Das Subject: Re: KASAN: vmalloc-out-of-bounds Write in snd_pcm_hw_params In-Reply-To: References: <874jz82kx0.wl-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: alsa-devel@alsa-project.org, fleischermarius@googlemail.com, Greg KH , linux-kernel@vger.kernel.org, tiwai@suse.com, consult.awy@gmail.com, syzkaller@googlegroups.com, its.priyanka.bose@gmail.com 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 Tue, 26 Jul 2022 23:40:48 +0200, Dipanjan Das wrote: > > On Sat, Jul 23, 2022 at 3:17 AM Takashi Iwai wrote: > > > > On Sat, 23 Jul 2022 09:00:08 +0200, > > Greg KH wrote: > > > > > > Wondeful, do you have a fix for this that solves the reported problem > > > that you have tested with the reproducer? > > > > ... or at least more detailed information. > > Here is our analysis of the bug in the kernel v5.10.131. > > During allocation, the `size` of the DMA buffer is not page-aligned: > https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/memalloc.c#L149. > However, in sound/core/pcm_native.c:798 > (https://elixir.bootlin.com/linux/v5.10.131/source/sound/core/pcm_native.c#L798), > the `size` variable is page-aligned before memset-ing the `dma_area`. > >From the other BUG_ON assertions in other parts of the code, it looks > like the DMA area is not supposed to be equal to or greater than > 0x200000 bytes. However, due to page-alignment, the `size` can indeed > get rounded up to 0x200000 which causes the out of bound access. > > > Last but not least, you should check whether it's specific to your > > 5.10.x kernel or it's also seen with the latest upstream, too. > > The bug is not reproducible on the latest mainline, because in > sound/core/memalloc.c:66 > (https://github.com/torvalds/linux/blob/5de64d44968e4ae66ebdb0a2d08b443f189d3651/sound/core/memalloc.c#L66) > the allocation function `snd_dma_alloc_dir_pages()` now page-aligns > the `size` right before allocating the DMA buffer. Therefore, any > subsequent page-alignment, like the one in `snd_pcm_hw_params()` does > not cause an out of bound access. Thanks for the analysis. A good news is that, at least for the vmalloc() case, it's a kind of false-positive; vmalloc() always takes the full pages, so practically seen, the size is page-aligned. It's fooling the memory checker, though. But the similar problem could be seen with genalloc calls, and this was fixed by the upstream commit 5c1733e33c888a3cb7f576564d8ad543d5ad4a9e ALSA: memalloc: Align buffer allocations in page size I suppose you can simply backport this commit to 5.10.y. Could you confirm that this fixes your problem? thanks, Takashi