Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp292307imm; Tue, 24 Jul 2018 19:29:15 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeoIhPsKvuoZSzTi609UNg1zcfbgFMgcn0p/sXGdQrHtIzeMlo/dBqQzwoprpjRYJfScxss X-Received: by 2002:a17:902:7c12:: with SMTP id x18-v6mr14640654pll.23.1532485755061; Tue, 24 Jul 2018 19:29:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532485755; cv=none; d=google.com; s=arc-20160816; b=q/qpBJcG+frFJOqioHp6IEocEtmHph4IfB0NOZGeRZk+HrvUTIpvpe38EnezRHCwef RJSDePkpnmNkYW45m3cwbNB8Zt99+hh3GcGFXaSaVSC0fSBigG0h76g0MckeS0oEfLvV J16EMCb2B5MlkghEROR3hU5yrhBqvdyBUmp0v8muaxyHy362510ChX68YfEbpkBwODfV WH6Bc9hZwTiOS/2+sj6Q4ziHdGKmncWcO6uXJGF2zA2buCbkB1rEJ0cV2l2+CgeydFry 2619/1a8sCqnIxZ2t6WxG0JNYE7+RofYhKlCA++bjrrWB3Na8e4zoA698rchKxsUYxGH nXgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=QL90FRsf3uxtb9FjaBZ3QjUhXS60d+7wm7Zm4DQMNlQ=; b=VfEhQL1UtMIe/9FNR6fFOTBNpTtB2hRCIYRBxMRyFTWeWCnGGinc8w15k0fVJ9hovp s0uxMXJGqeTv4oBv6vp0t5ZvL/K4GYeWaxta2MJwIvvA530VLula3lHWtxCgFaq3ayRX aEpUA05MEOgC6ieJBg5cimUmOqdXICN3XlvNnic1AUUFhqwpZwPCdEk64lut53Zesta/ G3qik54ssZH/i0UnQDxfJGD/4/K0Jm3Oyin16ocAMxyYAgyZy1vkVfFDWVQWyiP5fTKo ndC0BLAruKvuwMj70ySnTIE69dcHBRtrWUOZxn/i2ZRHB+89AMKifk3OXAgt33x7wpuw 7+AA== 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 k14-v6si12645034pga.149.2018.07.24.19.29.00; Tue, 24 Jul 2018 19:29:15 -0700 (PDT) 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 S2388483AbeGYDhc (ORCPT + 99 others); Tue, 24 Jul 2018 23:37:32 -0400 Received: from mxhk.zte.com.cn ([63.217.80.70]:44290 "EHLO mxhk.zte.com.cn" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728051AbeGYDhc (ORCPT ); Tue, 24 Jul 2018 23:37:32 -0400 Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id A4063608350672B43A95; Wed, 25 Jul 2018 10:28:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id w6P2RwRb059532; Wed, 25 Jul 2018 10:27:58 +0800 (GMT-8) (envelope-from wang.yi59@zte.com.cn) Received: from fox-host8.localdomain ([10.74.120.8]) by szsmtp06.zte.com.cn (Lotus Domino Release 8.5.3FP6) with ESMTP id 2018072510280235-1661324 ; Wed, 25 Jul 2018 10:28:02 +0800 From: Yi Wang To: paul@paul-moore.com Cc: eparis@redhat.com, linux-audit@redhat.com, linux-kernel@vger.kernel.org, jiang.biao2@zte.com.cn, wang.yi59@zte.com.cn, zhong.weidong@zte.com.cn Subject: [PATCH v2] audit: fix potential null dereference 'context->module.name' Date: Wed, 25 Jul 2018 10:26:19 +0800 Message-Id: <1532485579-34431-1-git-send-email-wang.yi59@zte.com.cn> X-Mailer: git-send-email 1.8.3.1 X-MIMETrack: Itemize by SMTP Server on SZSMTP06/server/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2018-07-25 10:28:02, Serialize by Router on notes_smtp/zte_ltd(Release 9.0.1FP7|August 17, 2016) at 2018-07-25 10:27:50, Serialize complete at 2018-07-25 10:27:50 X-MAIL: mse01.zte.com.cn w6P2RwRb059532 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The variable 'context->module.name' may be null pointer when kmalloc return null, so it's better to check it before using to avoid null dereference. Another one more thing this patch does is using kstrdup instead of (kmalloc + strcpy), and signal a lost record via audit_log_lost. Signed-off-by: Yi Wang Reviewed-by: Jiang Biao --- v2: use kstrdup instead of kmalloc + strcpy, and signal a lost record. Thanks to Eric and Paul. kernel/auditsc.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index e80459f..713386a 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -1272,8 +1272,12 @@ static void show_special(struct audit_context *context, int *call_panic) break; case AUDIT_KERN_MODULE: audit_log_format(ab, "name="); - audit_log_untrustedstring(ab, context->module.name); - kfree(context->module.name); + if (context->module.name) { + audit_log_untrustedstring(ab, context->module.name); + kfree(context->module.name); + } else + audit_log_format(ab, "(null)"); + break; } audit_log_end(ab); @@ -2408,8 +2412,9 @@ void __audit_log_kern_module(char *name) { struct audit_context *context = current->audit_context; - context->module.name = kmalloc(strlen(name) + 1, GFP_KERNEL); - strcpy(context->module.name, name); + context->module.name = kstrdup(name, GFP_KERNEL); + if (!context->module.name) + audit_log_lost("out of memory in __audit_log_kern_module"); context->type = AUDIT_KERN_MODULE; } -- 1.8.3.1