From nobody Sun Feb 8 10:04:47 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 241C3341674 for ; Thu, 22 Jan 2026 14:07:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769090873; cv=none; b=puAiheblYLj/zD3QeeQ1r2Mv+0FcyXtIrCMD6BVdL7x+6eT4zlEIJcO1MA1EonViM+AUPSF68yqcwLTyqcCcLkWSC9CWEQ6duE5H0FElKSwkrLRchJ3kC2zfJ9V0UqURJA3zLOBhaJHp8MSh80qsT1rvdNV6nBuHV99gLRIJAaY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769090873; c=relaxed/simple; bh=G07Wvq8WvGFjY0dmP+/uGwYn1jnRFIolVqzUSFCwWXo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=KDSs4t5XQToqUScNkE1kyz69LqxkLReBxHvCmOzbthJomfbJ02dxZkcD9JS9vmO53xqjaxa84h0K+yYnbdd+hzCvEwa2VbPldOYzYMR1PggFRFm2inpjhrFtfcUfKuPnKgt/6AfvsiNjKm6Qd3NBJ9M2nJGkY9yM1/xmx2L1/5Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Q/2rZ962; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=r6rDTYd9; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Q/2rZ962"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="r6rDTYd9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769090869; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=EtcMyJILD4z1qrnqIkPGVFTkZx7N2Lh4EB8ICDznUWY=; b=Q/2rZ962h3B/ZIk113PX6ENUo9cXI+PExGOp6aJ3Zx+mGQ5c3zOi0lwu5qkiLzai5KZmHP J1VOzlli0js12/DHXK3gO88jExXqHAgJjddiu7oQZAxDILqWHDr2gfwZrPt+i5AYt3SuoW zVnwW6yBq+oBWfyGGieckexgRv5ez7s= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-494-18M78jU-POq9LOH88kolyQ-1; Thu, 22 Jan 2026 09:07:48 -0500 X-MC-Unique: 18M78jU-POq9LOH88kolyQ-1 X-Mimecast-MFC-AGG-ID: 18M78jU-POq9LOH88kolyQ_1769090867 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-4359d70faa2so688836f8f.1 for ; Thu, 22 Jan 2026 06:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769090867; x=1769695667; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=EtcMyJILD4z1qrnqIkPGVFTkZx7N2Lh4EB8ICDznUWY=; b=r6rDTYd9ICtDAVJ2Po4KepCxhAFrCKSrA5dgSgjYcWJEjdzPPbQLejdnWrz02TxobY jWlJua7WeNrJnHrgxGjcaPlL5fBCdEGh+Rw2Fffo6JCNxnyft0iQwGM42+32wT50V9bU LsgGnepJNLDh56mpQNfzV9Q36YXO76+xBg4S+r8WHoCBg0apIXF+nyfPW+6/zMDqoorX tuX6zGDXykXoa2LGAzMLFY6X0jHutnLKbjkxZLx8EGsfUsIPs50U3rupoK8svXY99HMf 7KJd9atXNJWyW8ka2qQy5EXAu9u0qQFF6bcwJpHk4tnM9q7PUKZ0sof3aKreXkXguzED R7LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769090867; x=1769695667; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=EtcMyJILD4z1qrnqIkPGVFTkZx7N2Lh4EB8ICDznUWY=; b=aq/+yc3wpW2U5mD6WGoMrveE7P8eRHHdIqiBcJ+EKkybdFwtE0SmEJfuQPTGYZg1zV tRMwAZGfQiueGUlITWeBwVyHxNXkDM9ZbooQFr7m0+HtJtDqU2vcaxnTYeDl/t4Pqq6g zG/UNZtNj+V/3uESoTe2F8lI419OpRSUVyyRXuAUDj0UP1WJ2o7XeXpkRILt1knAmFgk fK9C5w1pTsm0YnW76wYuAvTCXo+PhMbXDuNumu42Tik6CeiuNJooI60ZTnNyF5XjQNcE NuH5jWb5yYEfDDNVYV7BWV9Yuo2gkDG1guAyPP+poZOVunXVZtUVKrEF98yZtjydOuP/ ImUw== X-Gm-Message-State: AOJu0Yz6VNcBevox3bH9GDL9Gi8dsGNxBhcXHRf9uYdZ5JLJzIA3QG7s LrmxQw3PxoOHvPwJGD4DOS1hEj6gAbegGLIn7VndaJTRav7ODpW7mPZU9Evhs2MVn0xP0TFDBqB hfGLkah5dInzur9yMuPiwBvrkwzbCkeONLsn0z+TjJ12RmmlVYAqi/rPp3beKLpjsMg== X-Gm-Gg: AZuq6aL3sG2v6BALMlkgNKmaZM3K7kkcLbh/NAJu/JxtGk2UzMSoLN33xWnJB/PqFkd wIvGQpaAkcXzsFVii9E0NvYa4LxVTOLJdTro4G1DfmaGLhCunbNHg+4aPw5wW5kZ5ROwmk53NO9 ed3RxOzindtto6HPqrlvcNHK73W6hffSprRIpfuG5TtFWkUDYqcUmVp+GgsKHbM1VVKFOzXzBv8 CysKDhZcwUYYUsiHddupz9yfZP9TbmlxxYG5rk/dlNkedt+14oFGE+mZ0RFhaMKQMc/ZbxPdyOO W7rr2nZxtDmtF3hOy5s/2jda5YH1CNVm5WWC2zPfJ/XAQ1bvP8vQFBgzm7E1OI5lUZk= X-Received: by 2002:a05:6000:25c7:b0:432:5bf9:cf15 with SMTP id ffacd0b85a97d-4356a024907mr35369563f8f.5.1769090867083; Thu, 22 Jan 2026 06:07:47 -0800 (PST) X-Received: by 2002:a05:6000:25c7:b0:432:5bf9:cf15 with SMTP id ffacd0b85a97d-4356a024907mr35369503f8f.5.1769090866620; Thu, 22 Jan 2026 06:07:46 -0800 (PST) Received: from fedora ([213.175.46.86]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43595e0a705sm17390416f8f.14.2026.01.22.06.07.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 06:07:46 -0800 (PST) From: Ondrej Mosnacek To: Andrew Morton , "Eric W . Biederman" Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org Subject: [PATCH] ucount: check for CAP_SYS_RESOURCE using ns_capable_noaudit() Date: Thu, 22 Jan 2026 15:07:45 +0100 Message-ID: <20260122140745.239428-1-omosnace@redhat.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The user.* sysctls implement the ctl_table_root::permissions hook and they override the file access mode based on the CAP_SYS_RESOURCE capability (at most rwx if capable, at most r-- if not). The capability is being checked unconditionally, so if an LSM denies the capability, an audit record may be logged even when access is in fact granted. Given the logic in the set_permissions() function in kernel/ucount.c and the unfortunate way the permission checking is implemented, it doesn't seem viable to avoid false positive denials by deferring the capability check. Thus, do the same as in net_ctl_permissions() (net/sysctl_net.c) - switch from ns_capable() to ns_capable_noaudit(), so that the check never logs an audit record. Fixes: dbec28460a89 ("userns: Add per user namespace sysctls.") Signed-off-by: Ondrej Mosnacek Acked-by: Serge Hallyn Reviewed-by: Paul Moore --- kernel/ucount.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/ucount.c b/kernel/ucount.c index 586af49fc03e4..fc4a8f2d30965 100644 --- a/kernel/ucount.c +++ b/kernel/ucount.c @@ -47,7 +47,7 @@ static int set_permissions(struct ctl_table_header *head, int mode; =20 /* Allow users with CAP_SYS_RESOURCE unrestrained access */ - if (ns_capable(user_ns, CAP_SYS_RESOURCE)) + if (ns_capable_noaudit(user_ns, CAP_SYS_RESOURCE)) mode =3D (table->mode & S_IRWXU) >> 6; else /* Allow all others at most read-only access */ --=20 2.52.0