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=-6.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham 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 4BE45C10F11 for ; Wed, 24 Apr 2019 17:23:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1BDC820675 for ; Wed, 24 Apr 2019 17:23:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556126617; bh=YoMf8MXUdVRAhakUKjCUZERg4lak23Jtcb5RKtOF4HM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=f8NpESsdc3bwJwhpJMHhSTNvms4iHK5Uir3JUxe2/Wjp6KBTp4LHO3u5BC1Tdsj+d ZKALFJDmrseLywQ2Y8N/HzQlEA3DHbKBtXazA8XbR/6ZEj8mEIhzpupM0fdicHeaLz Xzrs+JSZzpageZutZljKd7eAtLwXytYI7fdV9fmQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389729AbfDXRXg (ORCPT ); Wed, 24 Apr 2019 13:23:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:49266 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389327AbfDXRXc (ORCPT ); Wed, 24 Apr 2019 13:23:32 -0400 Received: from localhost (62-193-50-229.as16211.net [62.193.50.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1502E2190C; Wed, 24 Apr 2019 17:23:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556126611; bh=YoMf8MXUdVRAhakUKjCUZERg4lak23Jtcb5RKtOF4HM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gpmhQ7lWpef5IVguqq9BlXFQn3a8uSUPMM4wC5acmevKMSxrSVzordefBj+F5Zstl GUFwWBWRSdbk3mr/TAZ0oquLR1OxI4nNOPLZFqyMhgjyhhnpB70qNfvpPgumJJgZkr zet4L8/N5rdVpo2NoMMCALl5Rw1M1f0XwxmKnm3Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com, Takashi Iwai Subject: [PATCH 4.4 168/168] ALSA: info: Fix racy addition/deletion of nodes Date: Wed, 24 Apr 2019 19:10:12 +0200 Message-Id: <20190424170933.179251406@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190424170923.452349382@linuxfoundation.org> References: <20190424170923.452349382@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Takashi Iwai commit 8c2f870890fd28e023b0fcf49dcee333f2c8bad7 upstream. The ALSA proc helper manages the child nodes in a linked list, but its addition and deletion is done without any lock. This leads to a corruption if they are operated concurrently. Usually this isn't a problem because the proc entries are added sequentially in the driver probe procedure itself. But the card registrations are done often asynchronously, and the crash could be actually reproduced with syzkaller. This patch papers over it by protecting the link addition and deletion with the parent's mutex. There is "access" mutex that is used for the file access, and this can be reused for this purpose as well. Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/core/info.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/sound/core/info.c +++ b/sound/core/info.c @@ -724,8 +724,11 @@ snd_info_create_entry(const char *name, INIT_LIST_HEAD(&entry->children); INIT_LIST_HEAD(&entry->list); entry->parent = parent; - if (parent) + if (parent) { + mutex_lock(&parent->access); list_add_tail(&entry->list, &parent->children); + mutex_unlock(&parent->access); + } return entry; } @@ -809,7 +812,12 @@ void snd_info_free_entry(struct snd_info list_for_each_entry_safe(p, n, &entry->children, list) snd_info_free_entry(p); - list_del(&entry->list); + p = entry->parent; + if (p) { + mutex_lock(&p->access); + list_del(&entry->list); + mutex_unlock(&p->access); + } kfree(entry->name); if (entry->private_free) entry->private_free(entry);