From: Andrew Morton <akpm@linux-foundation.org>
To: Borislav Petkov <bp@amd64.org>
Cc: Denis Kirjanov <kirjanov@gmail.com>,
linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] edac: fix buffer overrun if no suitable bandwidth found
Date: Tue, 23 Oct 2012 14:09:39 -0700 [thread overview]
Message-ID: <20121023140939.28ed0df4.akpm@linux-foundation.org> (raw)
In-Reply-To: <20121023204926.GA20787@aftab.osrc.amd.com>
On Tue, 23 Oct 2012 22:49:26 +0200
Borislav Petkov <bp@amd64.org> wrote:
> Now you only need to give me a proper patch with your S-O-B and we're
> ready to go :).
who, me, what?!?! Sounds stressful.
umm, OK here we go.
What I don't understand is the effects of the bug. If the present code
can indeed start using the n+1th element of the array then it's writing
random garbage into the hardware. If this can ever happen then I
suspect that yes, a cc:stable is needed?
From: Andrew Morton <akpm@linux-foundation.org>
Subject: drivers/edac/amd64_edac.c:__amd64_set_scrub_rate(): avoid overindexing scrubrates[]
If none of the elements in scrubrates[] matches, this loop will cause
__amd64_set_scrub_rate() to incorrectly use the n+1th element.
As the function is designed to use the final scrubrates[] element in the
case of no match, we can fix this bug by simply terminating the array
search at the n-1th element.
Reported-by: Denis Kirjanov <kirjanov@gmail.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/edac/amd64_edac.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff -puN drivers/edac/amd64_edac.c~drivers-edac-amd64_edacc-__amd64_set_scrub_rate-avoid-overindexing-scrubrates drivers/edac/amd64_edac.c
--- a/drivers/edac/amd64_edac.c~drivers-edac-amd64_edacc-__amd64_set_scrub_rate-avoid-overindexing-scrubrates
+++ a/drivers/edac/amd64_edac.c
@@ -170,8 +170,11 @@ static int __amd64_set_scrub_rate(struct
* memory controller and apply to register. Search for the first
* bandwidth entry that is greater or equal than the setting requested
* and program that. If at last entry, turn off DRAM scrubbing.
+ *
+ * If no suitable bandwidth is found, turn off DRAM scrubbing entirely
+ * by falling back to the last element in scrubrates[].
*/
- for (i = 0; i < ARRAY_SIZE(scrubrates); i++) {
+ for (i = 0; i < ARRAY_SIZE(scrubrates) - 1; i++) {
/*
* skip scrub rates which aren't recommended
* (see F10 BKDG, F3x58)
@@ -181,12 +184,6 @@ static int __amd64_set_scrub_rate(struct
if (scrubrates[i].bandwidth <= new_bw)
break;
-
- /*
- * if no suitable bandwidth found, turn off DRAM scrubbing
- * entirely by falling back to the last element in the
- * scrubrates array.
- */
}
scrubval = scrubrates[i].scrubval;
_
next prev parent reply other threads:[~2012-10-23 21:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 15:30 [PATCH] edac: fix buffer overrun if no suitable bandwidth found Denis Kirjanov
2012-10-23 15:39 ` Borislav Petkov
2012-10-23 19:10 ` Andrew Morton
2012-10-23 20:26 ` Borislav Petkov
2012-10-23 20:37 ` Andrew Morton
2012-10-23 20:49 ` Borislav Petkov
2012-10-23 21:09 ` Andrew Morton [this message]
2012-10-23 21:38 ` Borislav Petkov
2012-10-23 21:58 ` Andrew Morton
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=20121023140939.28ed0df4.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bp@amd64.org \
--cc=kirjanov@gmail.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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 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.