Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp13572imu; Fri, 14 Dec 2018 13:28:59 -0800 (PST) X-Google-Smtp-Source: AFSGD/XJzxeLcLI8p0jci1fBySnjA9JWRMIsbJ/GrErO+FY7BwjgM1ROSzE3AIitQddTbM7NsimW X-Received: by 2002:a17:902:201:: with SMTP id 1mr4330318plc.62.1544822939703; Fri, 14 Dec 2018 13:28:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544822939; cv=none; d=google.com; s=arc-20160816; b=BgUEJRfHce83MmlG6b8jkZ7REW/cq/f3Lq2oBSAk9dIMs38AH5Cd4ykIy3f+In2mYE loNvx2vdB4X+l0WfB4vao02mLJ5VK+VbnwlgFpuVgAvadrWTA42eowL+vJ+7BthwvkBR SKHizTbDXqYwW8bbxpbWWtE4Ki5GcNxDGyHZIHjVqcC8TOmJBLLZF1x/oBe+7ySSLhwY wo1J1vNUBtQCmbXUWCyRHrqgcpduVlnrTrn2KdHNVcfuZArantgr4Ys4FNngVJO0ftOs 4fUFPvMBoizzHpQtm1yqKDrtN7mrzJcSLR0oonSHjfD2DAbxlqEJBJgjaSnkE2ZqXtkU 33MA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=igraEDlR2veK+KemOlk5P6HW2MAWtdmEClOPiyeLwUc=; b=nPrI6RbVYTRY0KwtYDzbOlp0kLAvLqCILMB8JtNBv/nUJqvQI3+B8zXO3QXqadlmf/ vT3VigSYIXazVYLlQWldvYJ4GxDT/O/HHt7erZqZ4dqpxomk2XECpNrKFA0htHbs+HF9 kJo9Qq4lu1nV6cHbZb/GtCOBK9LUpiG7YYv5ZRF4DEYYDLmvkhtLK2El0Tbv+ImVtIyg lXnA/JNNTstyugA/9qNjwFRRzahY44IxHtdu5KSXJ1NefWg4pXnQ6LZrrEHp4296AJ/R 9bpuvTz/yuAQgkpcIGeyuOne3CgJxPW6gE+IO/trR1y3ukmpFu1HmIcg1l/0Ot7xOfRP zVzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a16si4754472pls.146.2018.12.14.13.28.44; Fri, 14 Dec 2018 13:28:59 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731058AbeLNV1r (ORCPT + 99 others); Fri, 14 Dec 2018 16:27:47 -0500 Received: from mo4-p02-ob.smtp.rzone.de ([85.215.255.82]:20732 "EHLO mo4-p02-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730734AbeLNV1r (ORCPT ); Fri, 14 Dec 2018 16:27:47 -0500 X-Greylist: delayed 11543 seconds by postgrey-1.27 at vger.kernel.org; Fri, 14 Dec 2018 16:27:46 EST X-RZG-AUTH: ":OH8QVVOrc/CP6za/qRmbF3BWedPGA1vjs2e0bDjfg8OiOrPJifeRMRhMbfKobJAvSmsJbFO0KIY=" X-RZG-CLASS-ID: mo00 Received: from [192.168.2.24] by smtp.strato.de (RZmta 44.8 DYNA|AUTH) with ESMTPSA id V03c59uBELRQ6tv (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 14 Dec 2018 22:27:26 +0100 (CET) Subject: Re: [PATCH] acpi / apei: fix NULL deref during init To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, Laura Abbott , "Rafael J. Wysocki" , Len Brown , Tony Luck , linux-acpi@vger.kernel.org References: <20181214181514.29891-1-tst@schoebel-theuer.de> <20181214202406.GI11710@zn.tnic> From: Thomas Schoebel-Theuer Message-ID: Date: Fri, 14 Dec 2018 22:27:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20181214202406.GI11710@zn.tnic> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Hi Borislav, 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. So this should documents the one observed case where the NULL deref is actually happening. Of course, it would be possible to develop another solution, but this one appears the simplest and safest to me (minimum changes to the logic). I have tested the patch on that specifc hardware: I have verified that the patch does not trigger the NULL deref anymore. Of course, on any other hardware we have tested, the bug did not trigger at all. If you don't have that specific hardware, you probably cannot easily trigger / verify the problem. If you need access to the specfic hardware, talk to me in a private conversation. Cheers, Thomas