Messages in this thread | | | Subject | Re: [PATCH] acpi / apei: fix NULL deref during init | From | Thomas Schöbel-Theuer <> | Date | Fri, 14 Dec 2018 23:42:01 +0100 |
| |
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.
| |