linux-kernel - Re: xfs/ima: Regression caching i

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2b193b5ccd696420196ae9059f83dcc8b3f06473.camel@kernel.org>
Date: Fri, 12 Dec 2025 05:55:45 +0900
From: Jeff Layton <jlayton@...nel.org>
To: Frederick Lawler <fred@...udflare.com>
Cc: Christian Brauner <brauner@...nel.org>, "Darrick J. Wong"	
 <djwong@...nel.org>, Josef Bacik <josef@...icpanda.com>, Carlos Maiolino	
 <cem@...nel.org>, linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, linux-integrity@...r.kernel.org, 
 Roberto Sassu <roberto.sassu@...wei.com>, kernel-team@...udflare.com
Subject: Re: xfs/ima: Regression caching i_version

On Thu, 2025-12-11 at 14:29 -0600, Frederick Lawler wrote:
> Hi Jeff,
> 
> While testing 6.18, I think I found a regression with
> commit 1cf7e834a6fb ("xfs: switch to multigrain timestamps") since 6.13
> where IMA is no longer able to properly cache i_version when we overlay
> tmpfs on top of XFS. Each measurement diff check in function
> process_measurement() reports that the i_version is
> always set to zero for iint->real_inode.version.
> 
> The function ima_collect_measurement() is looking to extract the version
> from the cookie on next measurement to cache i_version.
> 
> I'm unclear from the commit description what the right approach here is:
> update in IMA land by checking for time changes, or do
> something else such as adding the cookie back.
> 
> 

What we probably want to do is switch to using the ctime to manufacture
a change attribute when STATX_CHANGE_ATTRIBUTE is not set in the statx
reply.

IIRC, IMA doesn't need to persist these values across reboot, so
something like this (completely untested) might work, but it may be
better to lift nfsd4_change_attribute() into a common header and use
the same mechanism for both:

diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index c35ea613c9f8..5a71845f579e 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -272,10 +272,14 @@ int ima_collect_measurement(struct ima_iint_cache *iint, struct file *file,
         * to an initial measurement/appraisal/audit, but was modified to
         * assume the file changed.
         */
-       result = vfs_getattr_nosec(&file->f_path, &stat, STATX_CHANGE_COOKIE,
+       result = vfs_getattr_nosec(&file->f_path, &stat, STATX_CHANGE_COOKIE | STATX_CTIME,
                                   AT_STATX_SYNC_AS_STAT);
-       if (!result && (stat.result_mask & STATX_CHANGE_COOKIE))
-               i_version = stat.change_cookie;
+       if (!result) {
+               if (stat.result_mask & STATX_CHANGE_COOKIE)
+                       i_version = stat.change_cookie;
+               else if (stat.result_mask & STATX_CTIME)
+                       i_version = stat.ctime.tv_sec ^ stat.ctime.tv_nsec;
+       }
        hash.hdr.algo = algo;
        hash.hdr.length = hash_digest_size[algo];