From: Cong Wang <xiyou.wangcong@gmail.com> To: linux-kernel@vger.kernel.org Cc: linux-edac@vger.kernel.org, Cong Wang <xiyou.wangcong@gmail.com>, Tony Luck <tony.luck@intel.com>, Borislav Petkov <bp@alien8.de>, Thomas Gleixner <tglx@linutronix.de> Subject: [v2,1/2] ras: fix an off-by-one error in __find_elem() Date: Tue, 16 Apr 2019 14:33:50 -0700 [thread overview] Message-ID: <20190416213351.28999-1-xiyou.wangcong@gmail.com> (raw) ce_arr.array[] is always within the range [0, ce_arr.n-1]. However, the binary search code in __find_elem() uses ce_arr.n as the maximum index, which could lead to an off-by-one out-of-bound access right after the while loop. In this case, we should not even read it, just return -ENOKEY instead. Note, this could cause a kernel crash if ce_arr.n is exactly MAX_ELEMS. Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector") Cc: Tony Luck <tony.luck@intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> --- drivers/ras/cec.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c index 2d9ec378a8bc..a4ff54e50673 100644 --- a/drivers/ras/cec.c +++ b/drivers/ras/cec.c @@ -204,10 +204,11 @@ static int __find_elem(struct ce_array *ca, u64 pfn, unsigned int *to) if (to) *to = min; - this_pfn = PFN(ca->array[min]); - - if (this_pfn == pfn) - return min; + if (min < ca->n) { + this_pfn = PFN(ca->array[min]); + if (this_pfn == pfn) + return min; + } return -ENOKEY; }
WARNING: multiple messages have this Message-ID (diff)
From: Cong Wang <xiyou.wangcong@gmail.com> To: linux-kernel@vger.kernel.org Cc: linux-edac@vger.kernel.org, Cong Wang <xiyou.wangcong@gmail.com>, Tony Luck <tony.luck@intel.com>, Borislav Petkov <bp@alien8.de>, Thomas Gleixner <tglx@linutronix.de> Subject: [PATCH v2 1/2] ras: fix an off-by-one error in __find_elem() Date: Tue, 16 Apr 2019 14:33:50 -0700 [thread overview] Message-ID: <20190416213351.28999-1-xiyou.wangcong@gmail.com> (raw) Message-ID: <20190416213350.ppqhWO6g1EQc5K3on5YdH5YiamNHQMfG_6IitB2wUtw@z> (raw) ce_arr.array[] is always within the range [0, ce_arr.n-1]. However, the binary search code in __find_elem() uses ce_arr.n as the maximum index, which could lead to an off-by-one out-of-bound access right after the while loop. In this case, we should not even read it, just return -ENOKEY instead. Note, this could cause a kernel crash if ce_arr.n is exactly MAX_ELEMS. Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector") Cc: Tony Luck <tony.luck@intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> --- drivers/ras/cec.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c index 2d9ec378a8bc..a4ff54e50673 100644 --- a/drivers/ras/cec.c +++ b/drivers/ras/cec.c @@ -204,10 +204,11 @@ static int __find_elem(struct ce_array *ca, u64 pfn, unsigned int *to) if (to) *to = min; - this_pfn = PFN(ca->array[min]); - - if (this_pfn == pfn) - return min; + if (min < ca->n) { + this_pfn = PFN(ca->array[min]); + if (this_pfn == pfn) + return min; + } return -ENOKEY; } -- 2.20.1
next reply other threads:[~2019-04-16 21:33 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-16 21:33 Cong Wang [this message] 2019-04-16 21:33 ` [PATCH v2 1/2] ras: fix an off-by-one error in __find_elem() Cong Wang 2019-04-16 21:33 ` [v2,2/2] ras: close the race condition with timer Cong Wang 2019-04-16 21:33 ` [PATCH v2 2/2] " Cong Wang 2019-06-08 15:28 ` [tip:ras/urgent] RAS/CEC: Convert the timer callback to a workqueue tip-bot for Cong Wang 2019-04-16 21:46 ` [v2,1/2] ras: fix an off-by-one error in __find_elem() Borislav Petkov 2019-04-16 21:46 ` [PATCH v2 1/2] " Borislav Petkov 2019-04-16 23:16 ` [v2,1/2] " Cong Wang 2019-04-16 23:16 ` [PATCH v2 1/2] " Cong Wang 2019-04-20 11:34 ` [v2,1/2] " Borislav Petkov 2019-04-20 11:34 ` [PATCH v2 1/2] " Borislav Petkov 2019-04-20 18:25 ` [v2,1/2] " Cong Wang 2019-04-20 18:25 ` [PATCH v2 1/2] " Cong Wang 2019-04-20 19:04 ` [v2,1/2] " Borislav Petkov 2019-04-20 19:04 ` [PATCH v2 1/2] " Borislav Petkov 2019-04-20 19:15 ` [v2,1/2] " Cong Wang 2019-04-20 19:15 ` [PATCH v2 1/2] " Cong Wang 2019-04-21 8:27 ` [v2,1/2] " Borislav Petkov 2019-04-21 8:27 ` [PATCH v2 1/2] " Borislav Petkov
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=20190416213351.28999-1-xiyou.wangcong@gmail.com \ --to=xiyou.wangcong@gmail.com \ --cc=bp@alien8.de \ --cc=linux-edac@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=tglx@linutronix.de \ --cc=tony.luck@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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).