From: "Kani, Toshi" <toshi.kani@hpe.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "rrichter@marvell.com" <rrichter@marvell.com>,
"mchehab@kernel.org" <mchehab@kernel.org>,
"Elliott, Robert (Servers)" <elliott@hpe.com>,
"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Borislav Petkov" <bp@suse.de>
Subject: RE: [PATCH] EDAC/ghes: Fix buffer overflow in ghes_edac_register()
Date: Wed, 20 Jul 2022 15:41:20 +0000 [thread overview]
Message-ID: <PH7PR84MB1838CC03943D28806F7DCD8F828E9@PH7PR84MB1838.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <YtfsOcWbWREu1NnK@zn.tnic>
Borislav Petkov wrote:
> On Tue, Jul 19, 2022 at 04:01:24PM -0600, Toshi Kani wrote:
> > The following buffer overflow BUG was observed on an HPE system.
> > ghes_edac_register() called strlen() on an uninitialized label, which
> > had non-zero values from krealloc_array().
> > Change dimm_setup_label() to always initialize the label.
>
> Do we also know why dmi_memdev_name() doesn't give bank and/or device?
Yes.
> SMBIOS handle wrong?
SMBIOS handle is correct.
In dimm_setup_label(), *device is set but *bank is null (dmi_empty_string).
*bank is set from SMBIOS type 17 Bank Locator, offset 11h. This value is
set to 0x0 (null string) on this system, as shown below.
Handle 0x0020, DMI type 17, 84 bytes
Memory Device
Array Handle: 0x0013
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: DIMM
Set: None
Locator: PROC 1 DIMM 1 <===== device
Bank Locator: Not Specified <===== bank
....
Handle 0x0020, DMI type 17, 84 bytes
Header and Data:
11 54 20 00 13 00 FE FF 48 00 40 00 FF 7F 09 00
01 00 1A 80 20 75 0B 02 00 00 03 02 00 80 00 00
^^
75 0B B0 04 B0 04 B0 04 03 08 00 00 89 83 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
Strings:
50 52 4F 43 20 31 20 44 49 4D 4D 20 31 00
PROC 1 DIMM 1
55 4E 4B 4E 4F 57 4E 00
UNKNOWN
4E 4F 54 20 41 56 41 49 4C 41 42 4C 45 00
NOT AVAILABLE
Thanks,
Toshi
next prev parent reply other threads:[~2022-07-20 15:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 22:01 Toshi Kani
2022-07-20 11:51 ` Borislav Petkov
2022-07-20 15:41 ` Kani, Toshi [this message]
2022-07-20 15:57 ` Borislav Petkov
2022-07-20 16:17 ` Kani, Toshi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PH7PR84MB1838CC03943D28806F7DCD8F828E9@PH7PR84MB1838.NAMPRD84.PROD.OUTLOOK.COM \
--to=toshi.kani@hpe.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=elliott@hpe.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rrichter@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®