From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752706AbcAZVy2 (ORCPT ); Tue, 26 Jan 2016 16:54:28 -0500 Received: from mail-pf0-f176.google.com ([209.85.192.176]:34209 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbcAZVyJ (ORCPT ); Tue, 26 Jan 2016 16:54:09 -0500 Message-ID: <1453845246.2633.17.camel@slavad-ubuntu-14.04> Subject: Re: [patch] hfs: fix hfs_readdir() From: Viacheslav Dubeyko To: Dan Carpenter Cc: Chengyu Song , Andrew Morton , David Howells , Al Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Date: Tue, 26 Jan 2016 13:54:06 -0800 In-Reply-To: <20160126191835.GD5273@mwanda> References: <20160126092611.GD15717@mwanda> <1453832336.2633.10.camel@slavad-ubuntu-14.04> <20160126191835.GD5273@mwanda> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.