[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB608343DA951D303A36B2A29EFCE92@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Thu, 30 Jan 2025 17:13:28 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Haoyu Li <lihaoyu499@...il.com>, Borislav Petkov <bp@...en8.de>, "Thomas
Gleixner" <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Dave Hansen
<dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
CC: "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "chenyuan0y@...il.com" <chenyuan0y@...il.com>
Subject: RE: x86/mce: Potential Information Leak in __mce_read_apei Due to
Uninitialized Bytes
> I would like to bring to your attention a potential issue in the
> "__mce_read_apei" function. Specifically, the struct mce m is
> initialized via the "apei_read_mce" function before being copied to
> user space. However, upon inspecting the call trace (apei_read_mce ->
> erst_read_record -> erst_read), we found that not all fields of struct
> mce are properly initialized.
Thanks for the report.
I'm not seeing it.(in upstream v6.13 kernel).
__mce_read_apei() does declare "struct mce m" as local, so there is a concern about leakage.
Now apei_read_mce() does:
memcpy(m, &rcd.mce, sizeof(*m));
so all bytes are overwritte. Digging down "rcd.mce" is also a stack local, so need to
look into erst_read_record() for how it is filled.
That happens with
erst_read(record_id, record, buflen):
which will overwrite the whole of the "struct cper_mce_record rcd"
declared by apei_read_mce().
All of the error paths look to avoid the copy_to_user() in __mce_read_apei()
Did I miss something that you saw? Are you looking at an older version?
-Tony
Powered by blists - more mailing lists