Re: [PATCH] acpi / apei: fix NULL deref during init

From: Thomas SchÃbel-Theuer
Date: Fri Dec 14 2018 - 17:42:25 EST

On 12/14/18 22:27, Thomas Schoebel-Theuer wrote:
On 12/14/18 21:24, Borislav Petkov wrote:

Because apei_resources_fini() happens under the same condition check and
if arch_apei_filter_addr was false, it should not become true, all of a
sudden. Or?

please take a look at the stacktrace. For some reason, and only at that specific hardware, the condition is false, there but later the indicated error exit is taken whose message you can see immediately before the stack trace.

Ah, I overlooked that commit e56c92565dfe2 is already providing a different solution to the same problem in newer kernels _only_, as a _side_ effect (not clear to me from the description, but clear from reading the code).

But this patch is not present at the 4.4.166 kernel where I found the problem and fixed it internally in a different way.

The 4.4.166 code looks like this, without the if-statement you are mentioning, unconditionally trying to free the unitinialized variable under certain circumstances:

d91525eb8ee6a (Chen, GongÂÂÂÂ 2014-12-10 13:53:26 -0800 553) arch_res_fini:
d91525eb8ee6a (Chen, GongÂÂÂÂ 2014-12-10 13:53:26 -0800 554) apei_resources_fini(&arch_res);
d91525eb8ee6a (Chen, GongÂÂÂÂ 2014-12-10 13:53:26 -0800 555) nvs_res_fini:
4134b8c8811f2 (Huang YingÂÂÂÂ 2011-12-08 11:25:50 +0800 556) apei_resources_fini(&nvs_resources);
23f124ca3dda9 (Huang YingÂÂÂÂ 2010-09-29 19:53:54 +0800 557) return rc;

So another alternative would be backporting e56c92565dfe2 to the 4.4 LTS series. Also fine for me.