2017-05-09 13:31:26

by Colin King

[permalink] [raw]
Subject: [PATCH] nfsd: avoid out of bounds read on array nfsd4_layout_ops

From: Colin Ian King <[email protected]>

Array nfsd4_layout_ops has LAYOUT_TYPE_MAX elements (which is currently
just 6), so check for this upper bound rather than the hard coded upper
bound of 32 to avoid an out of bounds read on array nfsd4_layout_ops.

Detected by CoverityScan, CID#1433518 ("Out-of-bounds read")

Fixes: e79104c9bd2d26 ("nfsd: fix undefined behavior in nfsd4_layout_verify")
Signed-off-by: Colin Ian King <[email protected]>
---
fs/nfsd/nfs4proc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index 1dbf62190bee..c453a1998e00 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1259,7 +1259,8 @@ nfsd4_layout_verify(struct svc_export *exp, unsigned int layout_type)
return NULL;
}

- if (layout_type >= 32 || !(exp->ex_layout_types & (1 << layout_type))) {
+ if (layout_type >= LAYOUT_TYPE_MAX ||
+ !(exp->ex_layout_types & (1 << layout_type))) {
dprintk("%s: layout type %d not supported\n",
__func__, layout_type);
return NULL;
--
2.11.0



2017-05-09 14:04:33

by Dan Carpenter

[permalink] [raw]
Subject: Re: [PATCH] nfsd: avoid out of bounds read on array nfsd4_layout_ops

On Tue, May 09, 2017 at 02:31:21PM +0100, Colin King wrote:
> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> index 1dbf62190bee..c453a1998e00 100644
> --- a/fs/nfsd/nfs4proc.c
> +++ b/fs/nfsd/nfs4proc.c
> @@ -1259,7 +1259,8 @@ nfsd4_layout_verify(struct svc_export *exp, unsigned int layout_type)
> return NULL;
> }
>
> - if (layout_type >= 32 || !(exp->ex_layout_types & (1 << layout_type))) {
> + if (layout_type >= LAYOUT_TYPE_MAX ||
> + !(exp->ex_layout_types & (1 << layout_type))) {

The 32 is there to prevent a shift wrapping bug. The bit test prevents
a buffer overflow so this can't actually overflow. But this change
doesn't hurt and is probably cleaner.

exp->ex_layout_types is set in nfsd4_setup_layout_type().

regards,
dan carpenter


2017-05-09 19:57:46

by Christoph Hellwig

[permalink] [raw]

2017-05-09 21:03:51

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH] nfsd: avoid out of bounds read on array nfsd4_layout_ops

On Tue, May 09, 2017 at 05:04:14PM +0300, Dan Carpenter wrote:
> On Tue, May 09, 2017 at 02:31:21PM +0100, Colin King wrote:
> > diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> > index 1dbf62190bee..c453a1998e00 100644
> > --- a/fs/nfsd/nfs4proc.c
> > +++ b/fs/nfsd/nfs4proc.c
> > @@ -1259,7 +1259,8 @@ nfsd4_layout_verify(struct svc_export *exp, unsigned int layout_type)
> > return NULL;
> > }
> >
> > - if (layout_type >= 32 || !(exp->ex_layout_types & (1 << layout_type))) {
> > + if (layout_type >= LAYOUT_TYPE_MAX ||
> > + !(exp->ex_layout_types & (1 << layout_type))) {
>
> The 32 is there to prevent a shift wrapping bug. The bit test prevents
> a buffer overflow so this can't actually overflow.

Yes, looks like a false positive for coverity.

> But this change doesn't hurt and is probably cleaner.

Sure. Hope it's OK if I just merge this into the previous commit:

--b.

commit 16b6f81d8ed9
Author: Ari Kauppi <[email protected]>
Date: Fri May 5 16:07:55 2017 -0400

nfsd: fix undefined behavior in nfsd4_layout_verify

UBSAN: Undefined behaviour in fs/nfsd/nfs4proc.c:1262:34
shift exponent 128 is too large for 32-bit type 'int'

Depending on compiler+architecture, this may cause the check for
layout_type to succeed for overly large values (which seems to be the
case with amd64). The large value will be later used in de-referencing
nfsd4_layout_ops for function pointers.

Reported-by: Jani Tuovila <[email protected]>
Signed-off-by: Ari Kauppi <[email protected]>
[[email protected]: use LAYOUT_TYPE_MAX instead of 32]
Reviewed-by: Dan Carpenter <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>

diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index d86031b6ad79..c453a1998e00 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1259,7 +1259,8 @@ nfsd4_layout_verify(struct svc_export *exp, unsigned int layout_type)
return NULL;
}

- if (!(exp->ex_layout_types & (1 << layout_type))) {
+ if (layout_type >= LAYOUT_TYPE_MAX ||
+ !(exp->ex_layout_types & (1 << layout_type))) {
dprintk("%s: layout type %d not supported\n",
__func__, layout_type);
return NULL;

2017-05-09 21:14:51

by Colin King

[permalink] [raw]
Subject: Re: [PATCH] nfsd: avoid out of bounds read on array nfsd4_layout_ops

On 09/05/17 22:03, J . Bruce Fields wrote:
> On Tue, May 09, 2017 at 05:04:14PM +0300, Dan Carpenter wrote:
>> On Tue, May 09, 2017 at 02:31:21PM +0100, Colin King wrote:
>>> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
>>> index 1dbf62190bee..c453a1998e00 100644
>>> --- a/fs/nfsd/nfs4proc.c
>>> +++ b/fs/nfsd/nfs4proc.c
>>> @@ -1259,7 +1259,8 @@ nfsd4_layout_verify(struct svc_export *exp, unsigned int layout_type)
>>> return NULL;
>>> }
>>>
>>> - if (layout_type >= 32 || !(exp->ex_layout_types & (1 << layout_type))) {
>>> + if (layout_type >= LAYOUT_TYPE_MAX ||
>>> + !(exp->ex_layout_types & (1 << layout_type))) {
>>
>> The 32 is there to prevent a shift wrapping bug. The bit test prevents
>> a buffer overflow so this can't actually overflow.
>
> Yes, looks like a false positive for coverity.
>
>> But this change doesn't hurt and is probably cleaner.
>
> Sure. Hope it's OK if I just merge this into the previous commit:

Fine by me. Colin

>
> --b.
>
> commit 16b6f81d8ed9
> Author: Ari Kauppi <[email protected]>
> Date: Fri May 5 16:07:55 2017 -0400
>
> nfsd: fix undefined behavior in nfsd4_layout_verify
>
> UBSAN: Undefined behaviour in fs/nfsd/nfs4proc.c:1262:34
> shift exponent 128 is too large for 32-bit type 'int'
>
> Depending on compiler+architecture, this may cause the check for
> layout_type to succeed for overly large values (which seems to be the
> case with amd64). The large value will be later used in de-referencing
> nfsd4_layout_ops for function pointers.
>
> Reported-by: Jani Tuovila <[email protected]>
> Signed-off-by: Ari Kauppi <[email protected]>
> [[email protected]: use LAYOUT_TYPE_MAX instead of 32]
> Reviewed-by: Dan Carpenter <[email protected]>
> Signed-off-by: J. Bruce Fields <[email protected]>
>
> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> index d86031b6ad79..c453a1998e00 100644
> --- a/fs/nfsd/nfs4proc.c
> +++ b/fs/nfsd/nfs4proc.c
> @@ -1259,7 +1259,8 @@ nfsd4_layout_verify(struct svc_export *exp, unsigned int layout_type)
> return NULL;
> }
>
> - if (!(exp->ex_layout_types & (1 << layout_type))) {
> + if (layout_type >= LAYOUT_TYPE_MAX ||
> + !(exp->ex_layout_types & (1 << layout_type))) {
> dprintk("%s: layout type %d not supported\n",
> __func__, layout_type);
> return NULL;
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>


2017-05-10 05:24:59

by Ari Kauppi

[permalink] [raw]
Subject: Re: [PATCH] nfsd: avoid out of bounds read on array nfsd4_layout_ops


> On 10.5.2017, at 0.14, Colin Ian King <[email protected]> wrote:
>
> On 09/05/17 22:03, J . Bruce Fields wrote:
>> On Tue, May 09, 2017 at 05:04:14PM +0300, Dan Carpenter wrote:
>>> On Tue, May 09, 2017 at 02:31:21PM +0100, Colin King wrote:
>>>> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
>>>> index 1dbf62190bee..c453a1998e00 100644
>>>> --- a/fs/nfsd/nfs4proc.c
>>>> +++ b/fs/nfsd/nfs4proc.c
>>>> @@ -1259,7 +1259,8 @@ nfsd4_layout_verify(struct svc_export *exp, unsigned int layout_type)
>>>> return NULL;
>>>> }
>>>>
>>>> - if (layout_type >= 32 || !(exp->ex_layout_types & (1 << layout_type))) {
>>>> + if (layout_type >= LAYOUT_TYPE_MAX ||
>>>> + !(exp->ex_layout_types & (1 << layout_type))) {
>>>
>>> The 32 is there to prevent a shift wrapping bug. The bit test prevents
>>> a buffer overflow so this can't actually overflow.
>>
>> Yes, looks like a false positive for coverity.
>>
>>> But this change doesn't hurt and is probably cleaner.
>>
>> Sure. Hope it's OK if I just merge this into the previous commit:
>
> Fine by me. Colin

Looks good to me.

Thanks,

--
Ari