From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753447AbbJPGUR (ORCPT ); Fri, 16 Oct 2015 02:20:17 -0400 Received: from smtp02.smtpout.orange.fr ([80.12.242.124]:60652 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751854AbbJPGUP (ORCPT ); Fri, 16 Oct 2015 02:20:15 -0400 X-ME-Helo: [127.0.0.1] X-ME-Date: Fri, 16 Oct 2015 08:20:14 +0200 X-ME-IP: 92.140.185.80 Subject: Re: [PATCH v2] powerpc/mpc5xxx: Avoid dereferencing potentially freed memory To: Michael Ellerman References: <20151014040011.8AB1514110A@ozlabs.org> <1444888580-12966-1-git-send-email-christophe.jaillet@wanadoo.fr> <1444890977.5970.4.camel@ellerman.id.au> Cc: benh@kernel.crashing.org, paulus@samba.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Newsgroups: gmane.linux.kernel,gmane.linux.ports.ppc64.devel,gmane.linux.kernel.janitors From: Christophe JAILLET Message-ID: <5620971D.8040103@wanadoo.fr> Date: Fri, 16 Oct 2015 08:20:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1444890977.5970.4.camel@ellerman.id.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 151015-3, 15/10/2015), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 15/10/2015 08:36, Michael Ellerman a écrit : > On Thu, 2015-10-15 at 07:56 +0200, Christophe JAILLET wrote: >> Use 'of_property_read_u32()' instead of 'of_get_property()'+pointer >> dereference in order to avoid access to potentially freed memory. >> >> Use 'of_get_next_parent()' to simplify the while() loop and avoid the >> need of a temp variable. >> >> Signed-off-by: Christophe JAILLET >> --- >> v2: Use of_property_read_u32 instead of of_get_property+pointer dereference >> *** Untested *** > Thanks. > > Can someone with an mpc5xxx test this? > > cheers > Hi, I don't think it is an issue, but while looking at another similar patch, I noticed that the proposed patch adds a call to be32_to_cpup() (within of_property_read_u32). Apparently, powerPC is a BE architecture, so this call should be a no-op. Just wanted to point it out, in case of. Best regards, CJ