Received: by 10.223.185.116 with SMTP id b49csp1319097wrg; Wed, 21 Feb 2018 16:36:35 -0800 (PST) X-Google-Smtp-Source: AH8x225yXJQmnfZbrGXSa6Me2yiSBw9GtB/YoaO3Or5ryVkb/d5ANRpcp52UO/mMkaBKLVy+CJlH X-Received: by 10.98.56.150 with SMTP id f144mr5045258pfa.150.1519259795241; Wed, 21 Feb 2018 16:36:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519259795; cv=none; d=google.com; s=arc-20160816; b=ABluYJmyJcRmLsUJPAa8/hkfKM3a5crcUByeSxyoJfhgbHaHOrzGZrP3XpvTrLP7tt 27oS7zlRICDBgIl2zbmeZmYPQ4yrBue7Yf/w7Obys1lAIKQ3deOm12hNxE4/vJ5rGqDW Rb4+iCQlYCd04oAEDyK72FmqPIid+XkY7AP2tV3W5P8/CInVNhnhvnJjQjyRadGjdWOi BQLyPhv19yZAazWPHXWW8FaAfoUNrHTECEK0RKhuYSIYG6s5/LQGHfi250+jDZOD8Cl3 GWdod2PnIFHUkcf+AP4Po5pvsy7u+KOFY6LV/Gp4b8gMd/Em6VzShEgUIVaJlwa6O2sa MIxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=xr3gVBothffVSelUap9qWUKcYUAvOTKLpGVHMOA+7Co=; b=mXECiAd9xo0nMVRgv1EECX4bUnpranRm12XNgy8oPaBfwAFfaqeY8aAFpLAUP3t6Jo ayiFIFVnVH7ascK7bppLRS6HW6b+EQIOWVpSSnVGEe//m7l7NQN8DPcHiHHUcvDCH0tg F2wFGXq4PMx5PfiZc1MM2clBaqN5FpazgxTAXH45FLPYnQ/+Y7eG+noEeCX78cFe/Jnw icTXdTMp6ipb7ltKmG1tcQcEgd/gZP3zBGFQv25Pr00466NlvZc/BvtGa92aPKfPK57t UBmu8h6Wlz7dLRSAgkp03Tvs9fxD3yu0ScLRQhM/d8pj+j0yfIZ/F7AfoacvbmgkUOGl Io4g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y72si431953pfd.88.2018.02.21.16.36.20; Wed, 21 Feb 2018 16:36:35 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751518AbeBVAeQ (ORCPT + 99 others); Wed, 21 Feb 2018 19:34:16 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43302 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751270AbeBVAeP (ORCPT ); Wed, 21 Feb 2018 19:34:15 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A14BD4027CA8; Thu, 22 Feb 2018 00:34:14 +0000 (UTC) Received: from ovpn-112-11.rdu2.redhat.com (ovpn-112-11.rdu2.redhat.com [10.10.112.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id 76CFBAF018; Thu, 22 Feb 2018 00:34:09 +0000 (UTC) Message-ID: <1519259648.3171.43.camel@redhat.com> Subject: Re: [PATCH] audit: return on memory error to avoid null pointer dereference From: Eric Paris To: Paul Moore , Richard Guy Briggs Cc: Linux-Audit Mailing List , LKML , Steve Grubb Date: Wed, 21 Feb 2018 16:34:08 -0800 In-Reply-To: References: <2000f6951431b4f19947d7aa41bb8efd2fe3f15b.1519196084.git.rgb@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 22 Feb 2018 00:34:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 22 Feb 2018 00:34:14 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'eparis@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I think if we went back and looked at history we'd see that all of the code originally had none of the if(!ab) checks after allocation and they just sorta slowly crept in over time. I prefer this pattern, but it used to be the opposite everywhere. On Wed, 2018-02-21 at 19:02 -0500, Paul Moore wrote: > On Wed, Feb 21, 2018 at 6:49 PM, Paul Moore > wrote: > > On Wed, Feb 21, 2018 at 4:30 AM, Richard Guy Briggs > > wrote: > > > If there is a memory allocation error when trying to change an > > > audit > > > kernel feature value, the ignored allocation error will trigger a > > > NULL > > > pointer dereference oops on subsequent use of that > > > pointer. Return > > > instead. > > > > > > Passes audit-testsuite. > > > See: https://github.com/linux-audit/audit-kernel/issues/76 > > > Signed-off-by: Richard Guy Briggs > > > --- > > > kernel/audit.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > Thanks, merged. > > > > In the future a "[PATCH v2]" prefix would be appreciated for > > patches > > like this, it makes things a little easier in my inbox. > > After merging this I went through all the other callers to see if > they > suffered the same mistake and everyone except for IMA was checking > the > returned pointer for NULL. Upon looking at the IMA code, and the > audit code which is called, I realized we are actually "ok" as > audit_log_task_info(), audit_log_format(), audit_log_end(), and > others > all check for a NULL audit_buffer at the very top of the functions. > I'm going to leave this patch merged, it's a good practice after all, > but I don't believe that unpatched systems are in any danger of > oops'ing here. > > > > diff --git a/kernel/audit.c b/kernel/audit.c > > > index 5c25449..2de74be 100644 > > > --- a/kernel/audit.c > > > +++ b/kernel/audit.c > > > @@ -1059,6 +1059,8 @@ static void audit_log_feature_change(int > > > which, u32 old_feature, u32 new_feature > > > return; > > > > > > ab = audit_log_start(NULL, GFP_KERNEL, > > > AUDIT_FEATURE_CHANGE); > > > + if (!ab) > > > + return; > > > audit_log_task_info(ab, current); > > > audit_log_format(ab, " feature=%s old=%u new=%u > > > old_lock=%u new_lock=%u res=%d", > > > audit_feature_names[which], > > > !!old_feature, !!new_feature, > > > -- > > > 1.8.3.1 > >