linux-kernel - RE: [PATCH] ACPI: MRRM: Check revision of MRRM table

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: <SJ1PR11MB60835AF413CB53076304AABCFCF0A@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 23 Oct 2025 15:56:13 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: RE: [PATCH] ACPI: MRRM: Check revision of MRRM table

>> Before trying to parse the MRRM table, check that the table revision
>> is the one that is expected.
>
> OK, so should there be a Fixes: tag?  Or is it just a tidy-up of the code?

I'd be surprised if this table changed. But the h/w team that proposed the
MRRM table nagged me to check the revision "just in case". Which seems
like good practice.

Might as well add a Fixes to get this back ported in case someone locks onto
v6.16 or v6.17.

Fixes: b9020bdb9f76 ("ACPI: MRRM: Minimal parse of ACPI MRRM table")

Would you like me to post a V2, or can you just edit this in as you apply?

-Tony