lkml.org 
[lkml]   [2018]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] acpi / apei: fix NULL deref during init
From
Date
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.


\
 
 \ /
  Last update: 2018-12-14 23:43    [W:0.060 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site