From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793208497; b=lGwb1fXHXP+f7N3NyLBjZ9/XQ/Pm0vYTefJy41rcLITyO0j9RlYdl9x+N3Yrq9b/HK6H CrwhVUEWDhHnaN7PDyco1m89sKnP5fMNC2Y0aj7nqqMRSpQ3AId0zFblEMKzbh7oniyHK AaryAP6S8KqYG+R8mYfIo1wM57lqXu9JbBGCkQtLUu4jhNa0fiiKQWtfqapzpAm09up9c ZLZEWg9i259MEtJTWPTuSEm0huEbtin/A3M65l7YJfdNNLG1Dr43xyOwmy/3bYfaBq76O uiFF7SYDk6ltk+nwtcXwGhXIMVCHi6eAogpaAX7l19lPcn5UPnTNinQCHYb1QFRKnmA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793208497; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=a69Wjn7Bk15aiKPvtN1xIpqOjIHsHi33z5ucyjaW1mc=; b=XygPupBnKMGHLvTD/joPvnxnHqT9GiYhjBtgDp8EkhejiyKnbeZID0m40U+laJkME8a3 17+/CAIkLUbK/tVJpU6vyZkIjS6TrZnMdGD8TVf4XxIK63BbJyC+jLgsvqDj0BHiCNj/+ IX4XquJ2NW11SHTYqyIDhDKPHnQ2R65zb/zJ2CB4LyO/NYAGelpev5oir0FLty41j5PY0 fZYZwN75ngb7Mw3TTNhGnTk0kbmUU1CBbz05imS5/O8Qk2fc0dyA6hmtrFQGSozfKb7u7 uDX16ESQTbRuWINd2Wbvp+Z4/PePj2qkhNIicxIlIGK+j2SnWY++yqYLB+KBuJbrkcQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=xTxPvnFe; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF185606A31C; Wed, 28 Oct 2026 17:28:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=xTxPvnFe Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3ED831F01825; Wed, 28 Oct 2026 17:28:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793208496; bh=a69Wjn7Bk15aiKPvtN1xIpqOjIHsHi33z5ucyjaW1mc=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=xTxPvnFeBOzbmkHl5XQqVF24osykg05zEMY57uP3sFPfCNGaW4hyIefgIDZIkmmjm 0iZblsgqvkJcOcP8esqukeTTiVMFZtX8cadFaGX9gF94W0rE01Ah3MGgErP6L9dmxl l7OnKQFxRJAdtaocWPjC2mArbAb5wOUtGBmuvyOA= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, =?UTF-8?q?J=C3=A9r=C3=A9my=20Jean?= , Ricardo Robaina , Bradley Morgan , Paul Moore Subject: [PATCH 5.10 138/516] audit: fix exe mark UAF in kill_rules() Date: Wed, 28 Oct 2026 17:54:50 +0100 Message-ID: <20261028170006.779545714@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028170003.522232767@linuxfoundation.org> References: <20261028170003.522232767@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Jérémy Jean commit aa650d87a498844060eecb1d336f4d46f4d1b0b3 upstream. kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry->rule.exe before removing the rule from the RCU-visible filter lists. After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free. KASAN reports: BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0 Unlink the published rules from the RCU-visible lists and retain them on tree->rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait. Cc: stable@vger.kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Assisted-by: Codex:gpt-5 Signed-off-by: Jérémy Jean Reviewed-by: Ricardo Robaina Tested-by: Ricardo Robaina Reviewed-by: Bradley Morgan Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman --- kernel/audit_tree.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) --- a/kernel/audit_tree.c +++ b/kernel/audit_tree.c @@ -543,22 +543,38 @@ static void kill_rules(struct audit_cont { struct audit_krule *rule, *next; struct audit_entry *entry; + bool need_sync = false; list_for_each_entry_safe(rule, next, &tree->rules, rlist) { entry = container_of(rule, struct audit_entry, rule); - list_del_init(&rule->rlist); if (rule->tree) { /* not a half-baked one */ audit_tree_log_remove_rule(context, rule); - if (entry->rule.exe) - audit_remove_mark(entry->rule.exe); rule->tree = NULL; list_del_rcu(&entry->list); list_del(&entry->rule.list); - call_rcu(&entry->rcu, audit_free_rule_rcu); + if (entry->rule.exe) + need_sync = true; + } else { + list_del_init(&rule->rlist); } } + + if (list_empty(&tree->rules)) + return; + + if (need_sync) + synchronize_rcu(); + + list_for_each_entry_safe(rule, next, &tree->rules, rlist) { + entry = container_of(rule, struct audit_entry, rule); + + list_del_init(&rule->rlist); + if (entry->rule.exe) + audit_remove_mark(entry->rule.exe); + call_rcu(&entry->rcu, audit_free_rule_rcu); + } } /*