Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2536097imu; Thu, 29 Nov 2018 06:33:08 -0800 (PST) X-Google-Smtp-Source: AFSGD/UbU9aKiRZ2EI1UIQlalCV9cnPT77B3d6EUTU1aWwHMZ2UKvC8erhwq4a9Y4BcZDulgikEd X-Received: by 2002:a63:d450:: with SMTP id i16mr1420721pgj.246.1543501987999; Thu, 29 Nov 2018 06:33:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543501987; cv=none; d=google.com; s=arc-20160816; b=d+DWaubkxNtr/k427PRVwN76kOOzQeMZfYsbXztOjfEaG5kLGNrOGUdSrDxJmNMegj hA8PHa1w/rSQ+lHqsKKxak7k6RtYVZJ7yFJo+zwin76Zp6oZeAxwdrqwDSPxZXRk/+Ir vAUeEBMAmMiZfUkIopl/zPazjUZz0xQriJQ7OoODmP6WrF2Wp1DdFNmP+eD9DeCyE2Qs aIJDE+SNhkJZN7dfaNNKzllkEP+v0tGCVS/CgcAqFiBMKsBF7Emgs6UXRT4wv4G1QVp2 sZoMaVkk2TQ6R2mIn7IJdPhcyjdDkgmfFKwoyQXncV4yJ8QUS51a+fkdbq1xt7RxAKlW W3zQ== 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=/FN2ADQsXcxWu20E3U1Ur+3As5wwsDmGobFgrEcwQPg=; b=cIDU2W5ee5aIxC2SvUU0jR5lk+rS3ULfPwkctMkWzv+PYY7hNYxeGT9cNfO3zyjGcd NnxJbFdlndsgJ+JXfwgohH8aT7OjJnzjMXbVB344ebS6D9IMDt556QfjLjeBFyKjNNLr +RDWxVmCjPBzjOHaaMOwY6+yKWWr1yocXXeRbA8SgDU0/zAEEc/gRTAwCKQCxRFFgLqy yFs6BkviFvT898qBNXaBQ10qNbHCl5/0XSmZFOVT8Dard9g+i2xtAreddM2I70mCaLzI mvzFR9+jtfnXuR2j3klxsnOl2Q17vDyP1GEUWwi/IGO9ML39+fxw2bnBMJLM4Oi8YFgD KkBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=0XHsHx7K; 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 b131si2005543pga.51.2018.11.29.06.32.52; Thu, 29 Nov 2018 06:33:07 -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=0XHsHx7K; 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 S2388875AbeK3BgQ (ORCPT + 99 others); Thu, 29 Nov 2018 20:36:16 -0500 Received: from mail.kernel.org ([198.145.29.99]:38520 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388288AbeK3BgP (ORCPT ); Thu, 29 Nov 2018 20:36:15 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.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 781942146D; Thu, 29 Nov 2018 14:30:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543501841; bh=NmwN7OLb5hPJCztU4RpgnHKGI1wXmt9Iyh8GHXhRPBg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0XHsHx7KRxIphTI0j7LxPrfl3BfE68OGWykhIffRFSP4Lxc8sIogxbCy1e6IiwY2B EGeZ+3PVDUEHp9TJLoPTLw26OG03K7y33YNIwdchBIOKWVW3AYw5ivCHxm1YQcLYhI 83Ii/eYbfmg0eaITEl7bcBzOYN3PNiZuz7Zn8RhM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Amir Goldstein , Jan Kara Subject: [PATCH 4.19 064/110] fanotify: fix handling of events on child sub-directory Date: Thu, 29 Nov 2018 15:12:35 +0100 Message-Id: <20181129135923.838481094@linuxfoundation.org> X-Mailer: git-send-email 2.19.2 In-Reply-To: <20181129135921.231283053@linuxfoundation.org> References: <20181129135921.231283053@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review 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 4.19-stable review patch. If anyone has any objections, please let me know. ------------------ From: Amir Goldstein commit b469e7e47c8a075cc08bcd1e85d4365134bdcdd5 upstream. When an event is reported on a sub-directory and the parent inode has a mark mask with FS_EVENT_ON_CHILD|FS_ISDIR, the event will be sent to fsnotify() even if the event type is not in the parent mark mask (e.g. FS_OPEN). Further more, if that event happened on a mount or a filesystem with a mount/sb mark that does have that event type in their mask, the "on child" event will be reported on the mount/sb mark. That is not desired, because user will get a duplicate event for the same action. Note that the event reported on the victim inode is never merged with the event reported on the parent inode, because of the check in should_merge(): old_fsn->inode == new_fsn->inode. Fix this by looking for a match of an actual event type (i.e. not just FS_ISDIR) in parent's inode mark mask and by not reporting an "on child" event to group if event type is only found on mount/sb marks. [backport hint: The bug seems to have always been in fanotify, but this patch will only apply cleanly to v4.19.y] Cc: # v4.19 Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara [amir: backport to v4.19] Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman --- fs/notify/fanotify/fanotify.c | 10 +++++----- fs/notify/fsnotify.c | 8 ++++++-- 2 files changed, 11 insertions(+), 7 deletions(-) --- a/fs/notify/fanotify/fanotify.c +++ b/fs/notify/fanotify/fanotify.c @@ -115,12 +115,12 @@ static bool fanotify_should_send_event(s continue; mark = iter_info->marks[type]; /* - * if the event is for a child and this inode doesn't care about - * events on the child, don't send it! + * If the event is for a child and this mark doesn't care about + * events on a child, don't send it! */ - if (type == FSNOTIFY_OBJ_TYPE_INODE && - (event_mask & FS_EVENT_ON_CHILD) && - !(mark->mask & FS_EVENT_ON_CHILD)) + if (event_mask & FS_EVENT_ON_CHILD && + (type != FSNOTIFY_OBJ_TYPE_INODE || + !(mark->mask & FS_EVENT_ON_CHILD))) continue; marks_mask |= mark->mask; --- a/fs/notify/fsnotify.c +++ b/fs/notify/fsnotify.c @@ -161,9 +161,9 @@ int __fsnotify_parent(const struct path parent = dget_parent(dentry); p_inode = parent->d_inode; - if (unlikely(!fsnotify_inode_watches_children(p_inode))) + if (unlikely(!fsnotify_inode_watches_children(p_inode))) { __fsnotify_update_child_dentry_flags(p_inode); - else if (p_inode->i_fsnotify_mask & mask) { + } else if (p_inode->i_fsnotify_mask & mask & ALL_FSNOTIFY_EVENTS) { struct name_snapshot name; /* we are notifying a parent so come up with the new mask which @@ -331,6 +331,10 @@ int fsnotify(struct inode *to_tell, __u3 else mnt = NULL; + /* An event "on child" is not intended for a mount mark */ + if (mask & FS_EVENT_ON_CHILD) + mnt = NULL; + /* * Optimization: srcu_read_lock() has a memory barrier which can * be expensive. It protects walking the *_fsnotify_marks lists.