* [PATCH] block: sed-opal: Fix a couple off by one bugs
@ 2018-06-20 10:41 Dan Carpenter
2018-06-20 17:28 ` Scott Bauer
2018-06-20 18:04 ` Jens Axboe
0 siblings, 2 replies; 3+ messages in thread
From: Dan Carpenter @ 2018-06-20 10:41 UTC (permalink / raw)
To: Scott Bauer; +Cc: Jonathan Derrick, Jens Axboe, linux-block, kernel-janitors
resp->num is the number of tokens in resp->tok[]. It gets set in
response_parse(). So if n == resp->num then we're reading beyond the
end of the data.
Fixes: 455a7b238cd6 ("block: Add Sed-opal library")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Static analysis. Not tested. This matches the checking in
response_get_token().
My other concern is that there isn't checking in response_parse() to
ensure that we don't go over MAX_TOKS (64) entries. If the firmware
is buggy we're probably very screwed already, so it doesn't necessarily
make a lot of difference at runtime but it might make static analysis
easier if we knew the value of resp->num was in the 1-64 range.
diff --git a/block/sed-opal.c b/block/sed-opal.c
index 945f4b8610e0..e0de4dd448b3 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -877,7 +877,7 @@ static size_t response_get_string(const struct parsed_resp *resp, int n,
return 0;
}
- if (n > resp->num) {
+ if (n >= resp->num) {
pr_debug("Response has %d tokens. Can't access %d\n",
resp->num, n);
return 0;
@@ -916,7 +916,7 @@ static u64 response_get_u64(const struct parsed_resp *resp, int n)
return 0;
}
- if (n > resp->num) {
+ if (n >= resp->num) {
pr_debug("Response has %d tokens. Can't access %d\n",
resp->num, n);
return 0;
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] block: sed-opal: Fix a couple off by one bugs
2018-06-20 10:41 [PATCH] block: sed-opal: Fix a couple off by one bugs Dan Carpenter
@ 2018-06-20 17:28 ` Scott Bauer
2018-06-20 18:04 ` Jens Axboe
1 sibling, 0 replies; 3+ messages in thread
From: Scott Bauer @ 2018-06-20 17:28 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Jonathan Derrick, Jens Axboe, linux-block, kernel-janitors
nOn Wed, Jun 20, 2018 at 01:41:51PM +0300, Dan Carpenter wrote:
> resp->num is the number of tokens in resp->tok[]. It gets set in
> response_parse(). So if n == resp->num then we're reading beyond the
> end of the data.
>
> Fixes: 455a7b238cd6 ("block: Add Sed-opal library")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
Reviewed-by: Scott Bauer <scott.bauer@intel.com>
Tested-by: Scott Bauer <scott.bauer@intel.com>
> Static analysis. Not tested. This matches the checking in
> response_get_token().
>
> My other concern is that there isn't checking in response_parse() to
> ensure that we don't go over MAX_TOKS (64) entries. If the firmware
> is buggy we're probably very screwed already, so it doesn't necessarily
> make a lot of difference at runtime but it might make static analysis
> easier if we knew the value of resp->num was in the 1-64 range.
Do you want to send this patch or do you want me todo it? Im all for never
trusting firmware... I've seen it.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] block: sed-opal: Fix a couple off by one bugs
2018-06-20 10:41 [PATCH] block: sed-opal: Fix a couple off by one bugs Dan Carpenter
2018-06-20 17:28 ` Scott Bauer
@ 2018-06-20 18:04 ` Jens Axboe
1 sibling, 0 replies; 3+ messages in thread
From: Jens Axboe @ 2018-06-20 18:04 UTC (permalink / raw)
To: Dan Carpenter, Scott Bauer; +Cc: Jonathan Derrick, linux-block, kernel-janitors
On 6/20/18 4:41 AM, Dan Carpenter wrote:
> resp->num is the number of tokens in resp->tok[]. It gets set in
> response_parse(). So if n == resp->num then we're reading beyond the
> end of the data.
Applied, thanks Dan.
--
Jens Axboe
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-06-20 18:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-20 10:41 [PATCH] block: sed-opal: Fix a couple off by one bugs Dan Carpenter
2018-06-20 17:28 ` Scott Bauer
2018-06-20 18:04 ` Jens Axboe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox