From patchwork Thu Apr 19 00:05:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Robert Kolchmeyer X-Patchwork-Id: 10349009 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id AE5676023A for ; Thu, 19 Apr 2018 00:05:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9C29427F89 for ; Thu, 19 Apr 2018 00:05:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9014528919; Thu, 19 Apr 2018 00:05:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, USER_IN_DEF_DKIM_WL autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2EFA727F89 for ; Thu, 19 Apr 2018 00:05:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752952AbeDSAFc (ORCPT ); Wed, 18 Apr 2018 20:05:32 -0400 Received: from mail-vk0-f73.google.com ([209.85.213.73]:50748 "EHLO mail-vk0-f73.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752922AbeDSAF3 (ORCPT ); Wed, 18 Apr 2018 20:05:29 -0400 Received: by mail-vk0-f73.google.com with SMTP id v145so2338361vkv.17 for ; Wed, 18 Apr 2018 17:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:date:message-id:subject:from:to:cc; bh=O2GBKODlBV5g10Pd/qiuOxg/QyrJV0AxfqoMWY/PtSk=; b=frytjPSuc6NOB7HycLdPOaxYxNA9XwQP/ZCUtEus5RwhnJJ6ZY10f1eZ3SzjyGb01k Og8iXKZ/rEAIpGC6nPklBSy6HelpKljW0rrsBBGKUzCWt1fBgoumF1yawrta5jFLe8AI Yuqhc8RwJoWE7NyKW7u8sNQrsxFqkQxDOFAZFh4agcsPttx6WNeWmLfu13ThsF+jqEga cDwEm9Ds6XRVf7LeEQIBFvZd/AnDFoz0/GxW5cqHyZCejMaKUSPKgpW9k2OGtgXsKFBi qMSnaxMFWXFGyA8DWNeB6O3PKYkkIpt6mdF57P74h5Vw7ImNOOKvpofjmmcP5NeiygCh jGfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=O2GBKODlBV5g10Pd/qiuOxg/QyrJV0AxfqoMWY/PtSk=; b=SH6ZBXDhdlRyEVioi3KERDFXPK4+UdIguKqKkScgDVHmp3sjXsQsD7C+jf9ZiKJdIg b5AY18+hVezKZuVqy1GYOtpeusTuWVBEwdfuDBZGHdPIPExT2Tf0R5jfSJeHGPrUP8JI i3T4AcmQynmBX41t7gnPQdey+xtjMvwTQTzPa+1pTqrKKqJoAjqa9rvcLn/QMWLspknj DLeIvTJ0CE7L4N4Gtl66mr49T7KQmjT6i7pJOUlzwoAL+7qpzxGin1wFLd/4n+O0hmmt 4j71lkQS+7l1tMrBymE3aCLa9y7K56pur/qpUcgaCU+Ve2qDEe8yD9OH7nY1FpFGLb1g giWw== X-Gm-Message-State: ALQs6tATIab8zMfNVSLESTPCLURw4puUUeYXuBvCcf00e80xdiR+ZMKD vFYuV695sx4qciuuCzcGe4iiqb2xD1NKC3jb X-Google-Smtp-Source: AIpwx4+ivw3XPTUHX2BDyHjzcCHXP7Byll8ZTptOidEwYunJ+UJvfq/DeTNPGmoTNY61wfrPkLO57xu/YXt7KOCkfQ== MIME-Version: 1.0 X-Received: by 10.176.86.71 with SMTP id z7mr1849530uaa.41.1524096329077; Wed, 18 Apr 2018 17:05:29 -0700 (PDT) Date: Wed, 18 Apr 2018 17:05:25 -0700 Message-Id: <20180419000525.21673-1-rkolchmeyer@google.com> X-Mailer: git-send-email 2.17.0.484.g0c8726318c-goog Subject: [PATCH] fsnotify: Fix fsnotify_mark_connector race From: Robert Kolchmeyer To: jack@suse.cz, amir73il@gmail.com, mszeredi@redhat.com, linux-fsdevel@vger.kernel.org, rkolchmeyer@google.com Cc: linux-fsdevel@vger.kernel.org, Robert Kolchmeyer Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP fsnotify() acquires a reference to a fsnotify_mark_connector through the SRCU-protected pointer to_tell->i_fsnotify_marks. However, it appears that no precautions are taken in fsnotify_put_mark() to ensure that fsnotify() drops its reference to this fsnotify_mark_connector before assigning a value to its 'destroy_next' field. This can result in fsnotify_put_mark() assigning a value to a connector's 'destroy_next' field right before fsnotify() tries to traverse the linked list referenced by the connector's 'list' field. Since these two fields are members of the same union, this behavior results in a kernel panic. This issue is resolved by calling synchronize_srcu() before updating the connector's 'destroy_next' field in fsnotify_put_mark(). Since the relevant section of fsnotify() occurs in a SRCU read-side critical section, this will force fsnotify_put_mark() to wait for fsnotify() to finish operating on the connector before updating its 'destroy_next' field. Since fsnotify_put_mark() removes references to the connector before assigning its 'destroy_next' field, it shouldn't be possible for another thread to acquire a reference to the connector while fsnotify_put_mark() waits for fsnotify() to finish its work. The offending behavior here is extremely unlikely; since fsnotify_put_mark() removes references to a connector (specifically, it ensures that the connector is unreachable from the inode it was formerly attached to) before updating its 'destroy_next' field, a sizeable chunk of code in fsnotify_put_mark() has to execute in the short window between when fsnotify() acquires the connector reference and saves the value of its 'list' field. On the HEAD kernel, I've only been able to reproduce this by inserting a udelay(1) in fsnotify(). However, I've been able to reproduce this issue without inserting a udelay(1) anywhere on older unmodified release kernels, so I believe it's worth fixing at HEAD. Fixes bug 199437: https://bugzilla.kernel.org/show_bug.cgi?id=199437 Fixes: 08991e83b7286635167bab40927665a90fb00d81 Signed-off-by: Robert Kolchmeyer --- fs/notify/mark.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/notify/mark.c b/fs/notify/mark.c index e9191b416434..358fc7de1e86 100644 --- a/fs/notify/mark.c +++ b/fs/notify/mark.c @@ -227,6 +227,7 @@ void fsnotify_put_mark(struct fsnotify_mark *mark) iput(inode); if (free_conn) { + synchronize_srcu(&fsnotify_mark_srcu); spin_lock(&destroy_lock); conn->destroy_next = connector_destroy_list; connector_destroy_list = conn;