Re: [LTP] [PATCH v6] cve: reproducer for cve-2026-64600

[Petr Vorel <pvorel@suse.cz>]

Hi Andrea,

> Hi Petr,

> > > +			.min_kver = "4.16",
> > It got introduced in 4.11. Is there a reason for testing from 4.16?
> > Or is it just the copy paste error?

> 1e369b0e199bb ("xfs: remove experimental tag for reflinks") was merged
> in 4.16

Well, 1e369b0e199bb just remove warning from dmesg that reflinks are
experimental. Why to hide from users that kernels from 4.11 to 4.15 are
vulnerable? Also, Darrick marked his fix as vulnerable from 4.11 (Commit has
"Cc: stable@vger.kernel.org # v4.11" [1]), blog publish 4.11 [2], but LTP test
says "Test requires 4.16" => potential user of 4.11 will think "ok I'm safe".
IMHO perfect example of hiding kernel bug, specially due the fact that oldest
fixed kernel is v5.15.212, which backported upstream fix 2f4acd0fcd86 as
dc11be133efc, it was not backported to still supported LTS 5.10.x (EOL 31 Dec
2026) because it has conflicts.

> > Other than that LGTM.
> > Reviewed-by: Petr Vorel <pvorel@suse.cz>

> > > +			.mkfs_ver = "mkfs.xfs >= 1.5.0",
> > > +			.mkfs_opts = (const char *const []) {
> > > +				"-m", "reflink=1",
> > > +				NULL
> > > +			},
> > > +		},
> > > +		{}
> > > +	},
> > > +	.tags = (const struct tst_tag[]) {
> > > +		{"linux-git", "2f4acd0fcd86"},
> > Can you please before merge use longer hash
> > "2f4acd0fcd862e22eab45690ec2c08c80b6ef2e7"?

> I thought as a rule we always have to use short hash, we never use
> longer one, besides a couple of tests. Is there a reason for it?

I'm not sure if there was ever such rule, we just use short hash.

But isn't the possible git hash collision is a good reason to use full hash?
(Kernel repo has many commits => chance is higher in smaller repo e.g. LTP git.)

Specially in "linux-git" which has no git commit description, therefore user
would have to search by timestamp which has was valid. Also, that hash is used
as part of URL to the commit in git.kernel.org.

Because I have no evidence of git collision for 12 chars hash, let's use 2f4acd
(6 chars). URL in git.kernel org with hash collision [1] shows "Bad object id:
2f4acd".

User trying to investigate with git will see:

	$ git show 2f4acd
	error: short object ID 2f4acd is ambiguous
	hint: The candidates are:
	hint:   2f4acd0fcd86 commit 2026-07-13 - xfs: resample the data fork mapping after cycling ILOCK
	hint:   2f4acd6a2004 tree
	hint:   2f4acd8324d7 tree
	hint:   2f4acda35a5c tree
	fatal: ambiguous argument '2f4acd': unknown revision or path not in the working tree.

Anyway, I discussed it in the past [2] and I got ack from Cyril [3] and Jan [4],
and I posted my intention to implement it [5]. I'm sorry I did not post it to ML
to get the approval and instead merged it in 36dad3e738 [6]. I considered it as
agreed and I did not want to bother with yet another review. But I could have at
least sent informal patch with [COMMITTED] subject (maybe I should do at least
now).

Kind regards,
Petr


[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=206c09b04dc5469c7ff14d8aceff2d47c88078d9
[2] https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2f4acd
[2] https://lore.kernel.org/ltp/20260331072051.GA5254@pevik/
[3] https://lore.kernel.org/ltp/act71G89AKEf63LA@yuki.lan/
[4] https://lore.kernel.org/ltp/CAASaF6xgitWDpquGfcALptj+Rv8iNg=FEifXzw+1dfXNVYNVxw@mail.gmail.com/
[5] https://lore.kernel.org/ltp/20260401094946.GA126168@pevik/
[6] https://github.com/linux-test-project/ltp/commit/36dad3e738e61c86669a76affb6d557f17311a7e

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp