linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [patch] hfs: fix hfs_readdir()
@ 2016-01-26  9:26 Dan Carpenter
  2016-01-26 18:18 ` Viacheslav Dubeyko
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Carpenter @ 2016-01-26  9:26 UTC (permalink / raw)
  To: Chengyu Song
  Cc: Andrew Morton, David Howells, Al Viro, linux-fsdevel,
	linux-kernel, kernel-janitors

I was looking through static analysis warnings and we seem to be copying
garbage into &rd->key.  This goes back to before the start of git...

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Not tested.  Please review carefully.

diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
index 70788e0..66485d7 100644
--- a/fs/hfs/dir.c
+++ b/fs/hfs/dir.c
@@ -163,7 +163,7 @@ static int hfs_readdir(struct file *file, struct dir_context *ctx)
 		rd->file = file;
 		list_add(&rd->list, &HFS_I(inode)->open_dir_list);
 	}
-	memcpy(&rd->key, &fd.key, sizeof(struct hfs_cat_key));
+	memcpy(&rd->key, &fd.key->cat, sizeof(struct hfs_cat_key));
 out:
 	hfs_find_exit(&fd);
 	return err;

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [patch] hfs: fix hfs_readdir()
  2016-01-26  9:26 [patch] hfs: fix hfs_readdir() Dan Carpenter
@ 2016-01-26 18:18 ` Viacheslav Dubeyko
  2016-01-26 19:18   ` Dan Carpenter
  0 siblings, 1 reply; 8+ messages in thread
From: Viacheslav Dubeyko @ 2016-01-26 18:18 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Chengyu Song, Andrew Morton, David Howells, Al Viro,
	linux-fsdevel, linux-kernel, kernel-janitors

On Tue, 2016-01-26 at 12:26 +0300, Dan Carpenter wrote:
> I was looking through static analysis warnings and we seem to be copying
> garbage into &rd->key.  This goes back to before the start of git...
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Not tested.  Please review carefully.
> 
> diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
> index 70788e0..66485d7 100644
> --- a/fs/hfs/dir.c
> +++ b/fs/hfs/dir.c
> @@ -163,7 +163,7 @@ static int hfs_readdir(struct file *file, struct dir_context *ctx)
>  		rd->file = file;
>  		list_add(&rd->list, &HFS_I(inode)->open_dir_list);
>  	}
> -	memcpy(&rd->key, &fd.key, sizeof(struct hfs_cat_key));
> +	memcpy(&rd->key, &fd.key->cat, sizeof(struct hfs_cat_key));

The field "key" is union:

164 typedef union hfs_btree_key {
165         u8 key_len;                     /* number of bytes in the key */
166         struct hfs_cat_key cat;
167         struct hfs_ext_key ext;
168 } hfs_btree_key;

The struct hfs_cat_key is the biggest item. So, size of this structure
is dominating in the union:

157 struct hfs_ext_key {
158         u8 key_len;             /* number of bytes in the key */
159         u8 FkType;              /* HFS_FK_{DATA,RSRC} */
160         __be32 FNum;            /* The File ID of the file */
161         __be16 FABN;            /* allocation blocks number*/
162 } __packed;

149 struct hfs_cat_key {
150         u8 key_len;             /* number of bytes in the key */
151         u8 reserved;            /* padding */
152         __be32 ParID;           /* CNID of the parent dir */
153         struct hfs_name CName;  /* The filename of the entry */
154 } __packed;

because:

27 #define HFS_NAMELEN             31     /* maximum length of an HFS filename */

87 struct hfs_name {
88         u8 len;
89         u8 name[HFS_NAMELEN];
90 } __packed;

If we are using sizeof(struct hfs_cat_key) then it looks like that we
could potentially miss one byte of the union during catalog key copying.
But if we will copy struct hfs_ext_key then we will copy some amount of
"garbage" anyway. So, I don't think that it's good fix of the issue.
What do you think?

Another worry could be the "search_key" field of the struct
hfs_find_data.

Thanks,
Vyacheslav Dubeyko.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] hfs: fix hfs_readdir()
  2016-01-26 18:18 ` Viacheslav Dubeyko
@ 2016-01-26 19:18   ` Dan Carpenter
  2016-01-26 21:54     ` Viacheslav Dubeyko
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Carpenter @ 2016-01-26 19:18 UTC (permalink / raw)
  To: Viacheslav Dubeyko
  Cc: Chengyu Song, Andrew Morton, David Howells, Al Viro,
	linux-fsdevel, linux-kernel, kernel-janitors

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));

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.

regards,
dan carpenter

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] hfs: fix hfs_readdir()
  2016-01-26 19:18   ` Dan Carpenter
@ 2016-01-26 21:54     ` Viacheslav Dubeyko
  2017-01-16 14:22       ` Dan Carpenter
  0 siblings, 1 reply; 8+ messages in thread
From: Viacheslav Dubeyko @ 2016-01-26 21:54 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Chengyu Song, Andrew Morton, David Howells, Al Viro,
	linux-fsdevel, linux-kernel, kernel-janitors

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).

> 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.

Thanks,
Vyacheslav Dubeyko.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] hfs: fix hfs_readdir()
  2016-01-26 21:54     ` Viacheslav Dubeyko
@ 2017-01-16 14:22       ` Dan Carpenter
  2017-01-16 22:34         ` Viacheslav Dubeyko
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Carpenter @ 2017-01-16 14:22 UTC (permalink / raw)
  To: Viacheslav Dubeyko
  Cc: Chengyu Song, Andrew Morton, David Howells, Al Viro,
	linux-fsdevel, linux-kernel, kernel-janitors

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [patch] hfs: fix hfs_readdir()
  2017-01-16 14:22       ` Dan Carpenter
@ 2017-01-16 22:34         ` Viacheslav Dubeyko
  2017-01-18 11:13           ` [patch resend] hfs: fix " Dan Carpenter
  0 siblings, 1 reply; 8+ messages in thread
From: Viacheslav Dubeyko @ 2017-01-16 22:34 UTC (permalink / raw)
  To: Dan Carpenter
  Cc: Chengyu Song, Andrew Morton, David Howells, Al Viro,
	linux-fsdevel, linux-kernel, kernel-janitors

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [patch resend] hfs: fix fix hfs_readdir()
  2017-01-16 22:34         ` Viacheslav Dubeyko
@ 2017-01-18 11:13           ` Dan Carpenter
  2017-01-18 17:28             ` Viacheslav Dubeyko
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Carpenter @ 2017-01-18 11:13 UTC (permalink / raw)
  To: Al Viro, Andrew Morton
  Cc: Jan Kara, Miklos Szeredi, Bob Copeland, Boaz Harrosh,
	Deepa Dinamani, Viacheslav Dubeyko, linux-fsdevel,
	kernel-janitors

I was looking through static analysis warnings and there is a bug here
that goes all the way back to the start of git.  Basically we're copying
the pointer and nearby garbage instead of the data the fd.key pointer is
pointing to.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
I sent this a year ago, and we had a thread about it, but in the end
decided that the original patch was correct.  Not tested.

diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
index 5de5c48..75b2542 100644
--- a/fs/hfs/dir.c
+++ b/fs/hfs/dir.c
@@ -169,7 +169,7 @@ static int hfs_readdir(struct file *file, struct dir_context *ctx)
 	 * Can be done after the list insertion; exclusion with
 	 * hfs_delete_cat() is provided by directory lock.
 	 */
-	memcpy(&rd->key, &fd.key, sizeof(struct hfs_cat_key));
+	memcpy(&rd->key, &fd.key->cat, sizeof(struct hfs_cat_key));
 out:
 	hfs_find_exit(&fd);
 	return err;

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [patch resend] hfs: fix fix hfs_readdir()
  2017-01-18 11:13           ` [patch resend] hfs: fix " Dan Carpenter
@ 2017-01-18 17:28             ` Viacheslav Dubeyko
  0 siblings, 0 replies; 8+ messages in thread
From: Viacheslav Dubeyko @ 2017-01-18 17:28 UTC (permalink / raw)
  To: Dan Carpenter, Al Viro, Andrew Morton
  Cc: Jan Kara, Miklos Szeredi, Bob Copeland, Boaz Harrosh,
	Deepa Dinamani, linux-fsdevel, kernel-janitors

On Wed, 2017-01-18 at 14:13 +0300, Dan Carpenter wrote:
> I was looking through static analysis warnings and there is a bug
> here
> that goes all the way back to the start of git.  Basically we're
> copying
> the pointer and nearby garbage instead of the data the fd.key pointer
> is
> pointing to.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> I sent this a year ago, and we had a thread about it, but in the end
> decided that the original patch was correct.  Not tested.
> 
> diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
> index 5de5c48..75b2542 100644
> --- a/fs/hfs/dir.c
> +++ b/fs/hfs/dir.c
> @@ -169,7 +169,7 @@ static int hfs_readdir(struct file *file, struct
> dir_context *ctx)
>  	 * Can be done after the list insertion; exclusion with
>  	 * hfs_delete_cat() is provided by directory lock.
>  	 */
> -	memcpy(&rd->key, &fd.key, sizeof(struct hfs_cat_key));
> +	memcpy(&rd->key, &fd.key->cat, sizeof(struct hfs_cat_key));
>  out:
>  	hfs_find_exit(&fd);
>  	return err;

Looks good.

Reviewed-by: Vyacheslav Dubeyko <slava@dubeyko.com>

Thanks,
Vyacheslav Dubeyko.


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-01-18 17:29 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-26  9:26 [patch] hfs: fix hfs_readdir() Dan Carpenter
2016-01-26 18:18 ` Viacheslav Dubeyko
2016-01-26 19:18   ` Dan Carpenter
2016-01-26 21:54     ` Viacheslav Dubeyko
2017-01-16 14:22       ` Dan Carpenter
2017-01-16 22:34         ` Viacheslav Dubeyko
2017-01-18 11:13           ` [patch resend] hfs: fix " Dan Carpenter
2017-01-18 17:28             ` Viacheslav Dubeyko

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).