From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762836AbcLSQXE (ORCPT ); Mon, 19 Dec 2016 11:23:04 -0500 Received: from casper.infradead.org ([85.118.1.10]:47230 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752849AbcLSQXD (ORCPT ); Mon, 19 Dec 2016 11:23:03 -0500 Date: Mon, 19 Dec 2016 16:22:58 +0000 (GMT) From: James Simmons To: Kees Cook cc: linux-kernel@vger.kernel.org, Oleg Drokin , Andreas Dilger , Greg Kroah-Hartman , "John L. Hammond" , Emoly Liu , Vitaly Fertman , Bruno Faccini , Bruce Korb , lustre-devel@lists.lustre.org, devel@driverdev.osuosl.org Subject: Re: [PATCH] staging: lustre: ldlm: use designated initializers In-Reply-To: <20161217010045.GA140343@beast> Message-ID: References: <20161217010045.GA140343@beast> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.4.1 on casper.infradead.org summary: Content analysis details: (-1.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 NO_RELAYS Informational: message was not relayed via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from grsecurity. > > Signed-off-by: Kees Cook > --- > drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > index 722160784f83..f815827532dc 100644 > --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c > @@ -143,7 +143,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock *req, __u64 *flags, > int added = (mode == LCK_NL); > int overlaps = 0; > int splitted = 0; > - const struct ldlm_callback_suite null_cbs = { NULL }; > + const struct ldlm_callback_suite null_cbs = { }; > > CDEBUG(D_DLMTRACE, > "flags %#llx owner %llu pid %u mode %u start %llu end %llu\n", Nak. Filling null_cbs with random data is a bad idea. If you look at ldlm_lock_create() where this is used you have if (cbs) { lock->l_blocking_ast = cbs->lcs_blocking; lock->l_completion_ast = cbs->lcs_completion; lock->l_glimpse_ast = cbs->lcs_glimpse; } Having lock->l_* point to random addresses is a bad idea. What really needs to be done is proper initialization of that structure. A bunch of patches will be coming to address this.