From: Ross Lagerwall <ross.lagerwall@citrix.com> To: Borislav Petkov <bp@alien8.de> Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-efi@vger.kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Len Brown <lenb@kernel.org>, Tony Luck <tony.luck@intel.com>, Huang Ying <ying.huang@intel.com> Subject: Re: [PATCH 2/2] efi/cper: Avoid possible OOB when checking generic data block Date: Mon, 28 Jan 2019 10:04:46 +0000 [thread overview] Message-ID: <d0a78e2a-7114-de25-4515-01844087ddbb@citrix.com> (raw) In-Reply-To: <20190123115402.GB3227@zn.tnic> On 1/23/19 11:54 AM, Borislav Petkov wrote: > On Tue, Jan 22, 2019 at 04:09:12PM +0000, Ross Lagerwall wrote: >> When checking a generic status block, we iterate over all the generic >> data blocks. The loop condition only checks that the start of the >> generic data block is valid (within estatus->data_length) but not the >> whole block. Because the size of data blocks (excluding error data) may >> vary depending on the revision and the revision is contained within the >> data block, ensure that enough of the current data block is valid before >> dereferencing any members otherwise an OOB access may occur if snip >> - data_len -= acpi_hest_get_record_size(gdata); >> + record_len = acpi_hest_get_record_size(gdata); > > record_size so that it matches the function name it is used to compute > this. > > Btw, trying to grok this code is making my head spin. > >> + if (record_len > data_len) >> + return -EINVAL; > > <---- newline here. > > Btw, those checks in the loop you can abstract away into a separate > function so that you end up with something more readable like: > > apei_estatus_for_each_section(estatus, gdata) { > record_size = check_hest_record_size(gdata, data_len); > if (!record_size) > return -EINVAL; > > data_len -= record_size; > } > > for example. > There are only two if statements in the loop body -- I don't think it is necessary to abstract this into a separate function (which still requires having one if statement in the loop body). I've made the other changes you suggested and sent a V2. Thanks, -- Ross Lagerwall
WARNING: multiple messages have this Message-ID (diff)
From: Ross Lagerwall <ross.lagerwall@citrix.com> To: Borislav Petkov <bp@alien8.de> Cc: <linux-kernel@vger.kernel.org>, <linux-acpi@vger.kernel.org>, <linux-efi@vger.kernel.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Len Brown <lenb@kernel.org>, Tony Luck <tony.luck@intel.com>, Huang Ying <ying.huang@intel.com> Subject: Re: [PATCH 2/2] efi/cper: Avoid possible OOB when checking generic data block Date: Mon, 28 Jan 2019 10:04:46 +0000 [thread overview] Message-ID: <d0a78e2a-7114-de25-4515-01844087ddbb@citrix.com> (raw) In-Reply-To: <20190123115402.GB3227@zn.tnic> On 1/23/19 11:54 AM, Borislav Petkov wrote: > On Tue, Jan 22, 2019 at 04:09:12PM +0000, Ross Lagerwall wrote: >> When checking a generic status block, we iterate over all the generic >> data blocks. The loop condition only checks that the start of the >> generic data block is valid (within estatus->data_length) but not the >> whole block. Because the size of data blocks (excluding error data) may >> vary depending on the revision and the revision is contained within the >> data block, ensure that enough of the current data block is valid before >> dereferencing any members otherwise an OOB access may occur if snip >> - data_len -= acpi_hest_get_record_size(gdata); >> + record_len = acpi_hest_get_record_size(gdata); > > record_size so that it matches the function name it is used to compute > this. > > Btw, trying to grok this code is making my head spin. > >> + if (record_len > data_len) >> + return -EINVAL; > > <---- newline here. > > Btw, those checks in the loop you can abstract away into a separate > function so that you end up with something more readable like: > > apei_estatus_for_each_section(estatus, gdata) { > record_size = check_hest_record_size(gdata, data_len); > if (!record_size) > return -EINVAL; > > data_len -= record_size; > } > > for example. > There are only two if statements in the loop body -- I don't think it is necessary to abstract this into a separate function (which still requires having one if statement in the loop body). I've made the other changes you suggested and sent a V2. Thanks, -- Ross Lagerwall
next prev parent reply other threads:[~2019-01-28 10:04 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-22 16:09 [PATCH 0/2] Fix crash in cper_estatus_check() Ross Lagerwall 2019-01-22 16:09 ` Ross Lagerwall 2019-01-22 16:09 ` [PATCH 1/2] acpi/apei: Avoid possible OOB when accessing BERT region Ross Lagerwall 2019-01-22 16:09 ` Ross Lagerwall 2019-01-22 16:09 ` [PATCH 2/2] efi/cper: Avoid possible OOB when checking generic data block Ross Lagerwall 2019-01-22 16:09 ` Ross Lagerwall 2019-01-23 11:54 ` Borislav Petkov 2019-01-28 10:04 ` Ross Lagerwall [this message] 2019-01-28 10:04 ` Ross Lagerwall
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=d0a78e2a-7114-de25-4515-01844087ddbb@citrix.com \ --to=ross.lagerwall@citrix.com \ --cc=bp@alien8.de \ --cc=lenb@kernel.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rjw@rjwysocki.net \ --cc=tony.luck@intel.com \ --cc=ying.huang@intel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.