Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1559784 > unrolled thread

Re: [patch] hfs: fix hfs_readdir()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [patch] hfs: fix hfs_readdir() Dan Carpenter <dan.carpenter@oracle.com> - 2017-01-16 15:30 +0100
    Re: [patch] hfs: fix hfs_readdir() Viacheslav Dubeyko <slava@dubeyko.com> - 2017-01-16 23:50 +0100

#1559784 — Re: [patch] hfs: fix hfs_readdir()

I was reviewing old warnings and I stumbled across this one again.
Although I wrote that &fd.key->cat and "fd.key" are equivalent, I feel
that actually we should be doing the former.  fd.key is a union but we
want the ->cat member of the union.

On Tue, Jan 26, 2016 at 01:54:06PM -0800, Viacheslav Dubeyko wrote:
> On Tue, 2016-01-26 at 22:18 +0300, Dan Carpenter wrote:
> > Hm, I completely didn't see that it was a union instead of a struct.  I
> > still think my fix is actually correct though.  Now that you point out
> > the union, I see that my change is equivalent to just removing the '&'
> > char.
> > 
> > -	memcpy(&rd->key, &fd.key, sizeof(struct hfs_cat_key));
> > +	memcpy(&rd->key, fd.key, sizeof(struct hfs_cat_key));
> > 
> 
> Yeahh, it looks correct right now. The rd is the pointer that includes
> struct hfs_cat_key object. So, we need to use &rd->key. But on another
> side we have struct hfs_find_data object on the stack. And this object
> includes the pointer on union btree_key. We want to copy struct
> hfs_cat_key object and we should use sizeof(struct hfs_cat_key).

I've read this paragraph several times now and I think you are saying
that the patch is correct.

> 
> > We don't want to copy sizeof(*fd.key) because that would write past the
> > end of the destination struct.
> > 
> > On Tue, Jan 26, 2016 at 10:18:56AM -0800, Viacheslav Dubeyko wrote:
> > > Another worry could be the "search_key" field of the struct
> > > hfs_find_data.
> > 
> > I don't understand what you mean here.
> > 
> 
> I mean here that we could have another incorrect copy operations for
> "search_key" field. That's all.

I don't see the bugs you are saying might exist...  ;)

regards,
dan carpenter

[toc] | [next] | [standalone]

#1560145

On Mon, 2017-01-16 at 17:22 +0300, Dan Carpenter wrote:
> I was reviewing old warnings and I stumbled across this one again.
> Although I wrote that &fd.key->cat and "fd.key" are equivalent, I
> feel
> that actually we should be doing the former.  fd.key is a union but
> we
> want the ->cat member of the union.
> 
> On Tue, Jan 26, 2016 at 01:54:06PM -0800, Viacheslav Dubeyko wrote:
> > 
> > On Tue, 2016-01-26 at 22:18 +0300, Dan Carpenter wrote:
> > > 
> > > Hm, I completely didn't see that it was a union instead of a
> > > struct.  I
> > > still think my fix is actually correct though.  Now that you
> > > point out
> > > the union, I see that my change is equivalent to just removing
> > > the '&'
> > > char.
> > > 
> > > -	memcpy(&rd->key, &fd.key, sizeof(struct hfs_cat_key));
> > > +	memcpy(&rd->key, fd.key, sizeof(struct hfs_cat_key));
> > > 
> > Yeahh, it looks correct right now. The rd is the pointer that
> > includes
> > struct hfs_cat_key object. So, we need to use &rd->key. But on
> > another
> > side we have struct hfs_find_data object on the stack. And this
> > object
> > includes the pointer on union btree_key. We want to copy struct
> > hfs_cat_key object and we should use sizeof(struct hfs_cat_key).
> I've read this paragraph several times now and I think you are saying
> that the patch is correct.
> 

Yes, I've said that patch looks good. I think it's better to resend the
patch again.

Thanks,
Vyacheslav Dubeyko.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web