From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Chengyu Song <csong84@gatech.edu>,
Andrew Morton <akpm@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org
Subject: Re: [patch] hfs: fix hfs_readdir()
Date: Tue, 26 Jan 2016 10:18:56 -0800 [thread overview]
Message-ID: <1453832336.2633.10.camel@slavad-ubuntu-14.04> (raw)
In-Reply-To: <20160126092611.GD15717@mwanda>
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.
next prev parent reply other threads:[~2016-01-26 18:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 9:26 [patch] hfs: fix hfs_readdir() Dan Carpenter
2016-01-26 18:18 ` Viacheslav Dubeyko [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1453832336.2633.10.camel@slavad-ubuntu-14.04 \
--to=slava@dubeyko.com \
--cc=akpm@linux-foundation.org \
--cc=csong84@gatech.edu \
--cc=dan.carpenter@oracle.com \
--cc=dhowells@redhat.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).