netdev - Re: [PATCH net-next] devlink: refactor end checks in devlink_nl_cmd_region_read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200513141924.486bae36@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Wed, 13 May 2020 14:19:24 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     davem@...emloft.net, jiri@...nulli.us, netdev@...r.kernel.org,
        kernel-team@...com
Subject: Re: [PATCH net-next] devlink: refactor end checks in
 devlink_nl_cmd_region_read_dumpit

On Wed, 13 May 2020 13:56:40 -0700 Jacob Keller wrote:
> > @@ -4294,8 +4289,21 @@ static int devlink_nl_cmd_region_read_dumpit(struct sk_buff *skb,
> >  		goto out_unlock;
> >  	}
> >  
> > +	if (attrs[DEVLINK_ATTR_REGION_CHUNK_ADDR] &&
> > +	    attrs[DEVLINK_ATTR_REGION_CHUNK_LEN]) {
> > +		if (!start_offset)
> > +			start_offset =
> > +				nla_get_u64(attrs[DEVLINK_ATTR_REGION_CHUNK_ADDR]);
> > +
> > +		end_offset = nla_get_u64(attrs[DEVLINK_ATTR_REGION_CHUNK_ADDR]);  
> 
> At  first, reading this confused me a bit, but it makes sense. The end
> is always "beginning + length".
> 
> If the start_offset is set before, this simply means that we needed to
> read over multiple buffers. Ok.

Yup, I just moved this from below, didn't seem bad enough to rewrite.

> > +		end_offset += nla_get_u64(attrs[DEVLINK_ATTR_REGION_CHUNK_LEN]);
> > +	}
> > +
> > +	if (end_offset > region->size)
> > +		end_offset = region->size;
> > +
> >  	/* return 0 if there is no further data to read */
> > -	if (start_offset >= region->size) {
> > +	if (start_offset == end_offset) {  
> 
> Why change this to ==? isn't it possible to specify a start_offset that
> is out of bounds? I think this should still be >=

See 5 lines above :) I moved the capping of end_offset from
devlink_nl_region_read_snapshot_fill() to here. We can keep
it greater equal, but that reads a little defensive.

> >  		err = 0;
> >  		goto out_unlock;
> >  	}