Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp1188302ybf; Thu, 27 Feb 2020 06:32:12 -0800 (PST) X-Google-Smtp-Source: APXvYqxvW4nMfB2N3t64XCFXnYsYZ9jlu8I/gmy/Kkcxow1Wgl6yXyur5Xpa9wRVt159grqzuCtB X-Received: by 2002:a05:6830:1e37:: with SMTP id t23mr3703092otr.16.1582813932395; Thu, 27 Feb 2020 06:32:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582813932; cv=none; d=google.com; s=arc-20160816; b=ds1JLMkFluGMqqGegELY+1ec4RW9G4IcsiE10Ye1hHDtvupuASAR9DRnoB0yliFQzg evyTCEYhz59oMtoRrd1g5Yf0988OM4Qf+QmRcaxUY2Ym2Z5g5MXnb9iKMJxdQ7UKUTth 1Bz6Ug2ebhs/JpLT8ebMoldmHymdfra4jbiDoXa6Dls7I5FKiVFMdtYkgABQqABNTdjh 4Xj/6AXQA9S3G+3cNotXOeq6m8KXeg4cvnC77kdWxWpWy7IPl/ruNQJkMY7gh0HURfwQ +AKPnB1YGsURvCjS8eqTgYwxyNQPp28PYXZVbD19NCZ8JduEIYB3lEXX9//G5jvt/VAP 3Mnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=FusjMugAOuB9AV3CCrIFMdmUAGIdmhvpTsX+ogqVgA0=; b=AfB0P/W60+mu/1NcZjEa4YS3g6YRn/hbfLn5dplxdI83yXnSHgcbnrub2o5P+p2Uov oi6i83ybFoGQRhoh2rbZ9Lla+SFyH8z6GgVUl9zdL5t3gHCajsV/orvZnYD52T8gbZCD zLNCAaNsSc1wGdSgK0m+x84jkESu5jYay3FockkG+Dcxc4M7lIuYd5DP16Q7mAwKJlcc i14i1FwK2p+4Vp6vQYhF1YA15ZrEBTWM3AcNTSvv5ZOH1IdPSQsKMG3PajarvoyhqpIQ cNHjS9f+Kcic8kkc6e6iAIr77I9fFO0Gjy8Gn8cMDO9/rp3oxVdKmrU0klTDvuZswcOe 6hhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=A61KqJJd; 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 t24si1647666oth.319.2020.02.27.06.32.00; Thu, 27 Feb 2020 06:32:12 -0800 (PST) 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=@kernel.org header.s=default header.b=A61KqJJd; 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 S2387601AbgB0OEb (ORCPT + 99 others); Thu, 27 Feb 2020 09:04:31 -0500 Received: from mail.kernel.org ([198.145.29.99]:40474 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387567AbgB0OEV (ORCPT ); Thu, 27 Feb 2020 09:04:21 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (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 EBD2020801; Thu, 27 Feb 2020 14:04:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582812258; bh=ep/R6/bCPKBeHBroTETaokEleV9E49zDrDWvWc6h8Oo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A61KqJJdQDJTLFX6ffzgLw3BdQCyCcY9uIO3l6JcaM8Zcio9HyE4sE349asOHWwr+ uAE3Kw2A8Sj8r39VIOZ3RDVRtjPpy8uC60n7mkimAHt1GTcad2giP8B+WaVumqW1Xj C5edlkb8BtC3jEH18D9oQWcmc4xI32AEzSMxUBxU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ioanna Alifieraki , Manfred Spraul , "Herton R. Krzesinski" , Arnd Bergmann , Catalin Marinas , malat@debian.org, "Joel Fernandes (Google)" , Davidlohr Bueso , Jay Vosburgh , Andrew Morton , Linus Torvalds Subject: [PATCH 4.19 45/97] Revert "ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()" Date: Thu, 27 Feb 2020 14:36:53 +0100 Message-Id: <20200227132221.919471596@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200227132214.553656188@linuxfoundation.org> References: <20200227132214.553656188@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: Ioanna Alifieraki commit edf28f4061afe4c2d9eb1c3323d90e882c1d6800 upstream. This reverts commit a97955844807e327df11aa33869009d14d6b7de0. Commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()") removes a lock that is needed. This leads to a process looping infinitely in exit_sem() and can also lead to a crash. There is a reproducer available in [1] and with the commit reverted the issue does not reproduce anymore. Using the reproducer found in [1] is fairly easy to reach a point where one of the child processes is looping infinitely in exit_sem between for(;;) and if (semid == -1) block, while it's trying to free its last sem_undo structure which has already been freed by freeary(). Each sem_undo struct is on two lists: one per semaphore set (list_id) and one per process (list_proc). The list_id list tracks undos by semaphore set, and the list_proc by process. Undo structures are removed either by freeary() or by exit_sem(). The freeary function is invoked when the user invokes a syscall to remove a semaphore set. During this operation freeary() traverses the list_id associated with the semaphore set and removes the undo structures from both the list_id and list_proc lists. For this case, exit_sem() is called at process exit. Each process contains a struct sem_undo_list (referred to as "ulp") which contains the head for the list_proc list. When the process exits, exit_sem() traverses this list to remove each sem_undo struct. As in freeary(), whenever a sem_undo struct is removed from list_proc, it is also removed from the list_id list. Removing elements from list_id is safe for both exit_sem() and freeary() due to sem_lock(). Removing elements from list_proc is not safe; freeary() locks &un->ulp->lock when it performs list_del_rcu(&un->list_proc) but exit_sem() does not (locking was removed by commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()"). This can result in the following situation while executing the reproducer [1] : Consider a child process in exit_sem() and the parent in freeary() (because of semctl(sid[i], NSEM, IPC_RMID)). - The list_proc for the child contains the last two undo structs A and B (the rest have been removed either by exit_sem() or freeary()). - The semid for A is 1 and semid for B is 2. - exit_sem() removes A and at the same time freeary() removes B. - Since A and B have different semid sem_lock() will acquire different locks for each process and both can proceed. The bug is that they remove A and B from the same list_proc at the same time because only freeary() acquires the ulp lock. When exit_sem() removes A it makes ulp->list_proc.next to point at B and at the same time freeary() removes B setting B->semid=-1. At the next iteration of for(;;) loop exit_sem() will try to remove B. The only way to break from for(;;) is for (&un->list_proc == &ulp->list_proc) to be true which is not. Then exit_sem() will check if B->semid=-1 which is and will continue looping in for(;;) until the memory for B is reallocated and the value at B->semid is changed. At that point, exit_sem() will crash attempting to unlink B from the lists (this can be easily triggered by running the reproducer [1] a second time). To prove this scenario instrumentation was added to keep information about each sem_undo (un) struct that is removed per process and per semaphore set (sma). CPU0 CPU1 [caller holds sem_lock(sma for A)] ... freeary() exit_sem() ... ... ... sem_lock(sma for B) spin_lock(A->ulp->lock) ... list_del_rcu(un_A->list_proc) list_del_rcu(un_B->list_proc) Undo structures A and B have different semid and sem_lock() operations proceed. However they belong to the same list_proc list and they are removed at the same time. This results into ulp->list_proc.next pointing to the address of B which is already removed. After reverting commit a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()") the issue was no longer reproducible. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1694779 Link: http://lkml.kernel.org/r/20191211191318.11860-1-ioanna-maria.alifieraki@canonical.com Fixes: a97955844807 ("ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()") Signed-off-by: Ioanna Alifieraki Acked-by: Manfred Spraul Acked-by: Herton R. Krzesinski Cc: Arnd Bergmann Cc: Catalin Marinas Cc: Cc: Joel Fernandes (Google) Cc: Davidlohr Bueso Cc: Jay Vosburgh Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- ipc/sem.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) --- a/ipc/sem.c +++ b/ipc/sem.c @@ -2345,11 +2345,9 @@ void exit_sem(struct task_struct *tsk) ipc_assert_locked_object(&sma->sem_perm); list_del(&un->list_id); - /* we are the last process using this ulp, acquiring ulp->lock - * isn't required. Besides that, we are also protected against - * IPC_RMID as we hold sma->sem_perm lock now - */ + spin_lock(&ulp->lock); list_del_rcu(&un->list_proc); + spin_unlock(&ulp->lock); /* perform adjustments registered in un */ for (i = 0; i < sma->sem_nsems; i++) {