[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160609172452.GA32327@jazz.nc.intel.com>
Date: Thu, 9 Jun 2016 19:24:52 +0200
From: Vincent Stehlé <vincent.stehle@...el.com>
To: Darren Hart <dvhart@...radead.org>
Cc: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
Sujith Thomas <sujith.thomas@...el.com>,
Zhang Rui <rui.zhang@...el.com>,
Len Brown <len.brown@...el.com>,
Rafael Wysocki <rjw@...ysocki.net>
Subject: Re: [PATCH] intel_menlow: prevent NULL pointer dereference
On Wed, Jun 08, 2016 at 01:38:46PM -0700, Darren Hart wrote:
> Under what circumstances can the .remove op be called with a NULL struct
> acpi_device * as a parameter? From what I can see, most acpi_* calls accpeting
> an acpi_device rely on it not being null, and they are regularly called from
> driver remove functions.
> Did you observe an explicit failure or can you describe a call path where this
> can occur?
Hi Darren,
Thank you for reviewing.
I am not sure about when the .remove() functions are called with a NULL
pointer, or if that can ever happen. I just noticed that dereferencing the
pointer and checking for NULL after did not seem to be the right thing to
do. So I wanted to replicate instead the same construct as e.g.
xen_acpi_processor_remove().
Your remark encouraged me to do some more digging into the sources and it
appears that 13 .remove() functions do indeed check their input device
pointer for NULL, while 26 do not (the remaining do not use their input
pointer at all). Now I am puzzled about the necessity to check the pointer
for NULL or not, and there does not seem to be a definitive answer in the
docs either...
Best regards,
Vincent.
Powered by blists - more mailing lists