From patchwork Sun Mar 20 22:23:46 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 8628701 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Original-To: patchwork-linux-crypto@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 6841D9F372 for ; Sun, 20 Mar 2016 22:23:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8520A20268 for ; Sun, 20 Mar 2016 22:23:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9829D20225 for ; Sun, 20 Mar 2016 22:23:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751066AbcCTWXx (ORCPT ); Sun, 20 Mar 2016 18:23:53 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:34568 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750987AbcCTWXw (ORCPT ); Sun, 20 Mar 2016 18:23:52 -0400 Received: by mail-wm0-f66.google.com with SMTP id p65so18650480wmp.1; Sun, 20 Mar 2016 15:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=tUpfRQ/g4oFXLUb3R/GGfvVp2SpxQaMGnDqei3GC4RI=; b=dILBgnDpvDlDmtxBM3SFtPRXVXhALwWGNirDWGS74SBxIgLEwcJ0B3tBeUDFiWgHNU rHCpgqzeM17VOaC74wL7GPJM1YNfi30vbT/SNgy1xnQjDeYAjqce1+yZcOO520eNkTl8 MJJqEpHlN16VBg/KHdeJC5Ex8lM3fweX0cpDKowyBtvld9bQeOb+Mhqpm1AxHKWFbyit 4QMTAzbAtXXznWeCSLfAPpxmH9CL2djkm7r5DF3XYVGHk1b/Uhhg2bpcrajxNb3X9G/t Zi0RAruehp2XKbswiialB18GOlHIdioS7vozGesEtmaqep0hlRx+50g9UDtdf1gd9qan pZHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=tUpfRQ/g4oFXLUb3R/GGfvVp2SpxQaMGnDqei3GC4RI=; b=EBUlsiuVW3zSdnrbF4y589LokCR5oFFpHMh6OhvEXQNnK1XD2reANiFV8foV/TTjAZ JALxVHimWy+LkKOvGFi4upzhsQBQdIYIs9LflrusEWm+voph3dZFNEnJhWEB2nks6GZ/ XZQQi9lStuslMEIsByYHgwpydv49YG+aJFTKD+gkne/IS8O+32vn9118SxchRS+qGPVP 8DRPS/bT5GHjPWlrUfhD0jj8T0cc102ELMzadgBXowK3+E5gKSNEAk0Zvkf+N6WjN8KM h0pyxkyiJCvz+dTL12VQkG8YPDLJf4XNAXRiQpcf4IhpPU07HDk2A3fbwEmj3PPsd+hq pVdQ== X-Gm-Message-State: AD7BkJJFr9M7coYOf4eiIxoNv4lnzCUckxcougCOMPxRyimblJd8ttuIyGFwIXUZbaPKOg== X-Received: by 10.28.129.213 with SMTP id c204mr10861559wmd.89.1458512630887; Sun, 20 Mar 2016 15:23:50 -0700 (PDT) Received: from localhost (f054185001.adsl.alicedsl.de. [78.54.185.1]) by smtp.gmail.com with ESMTPSA id p191sm9894087wmb.0.2016.03.20.15.23.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Mar 2016 15:23:50 -0700 (PDT) From: Nicolai Stange To: "David S. Miller" Cc: Herbert Xu , David Howells , Tadeusz Struk , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Nicolai Stange Subject: [PATCH] PKCS#7: pkcs7_validate_trust(): initialize the _trusted output argument Date: Sun, 20 Mar 2016 23:23:46 +0100 Message-Id: <1458512626-2839-1-git-send-email-nicstange@gmail.com> X-Mailer: git-send-email 2.7.3 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Despite what the DocBook comment to pkcs7_validate_trust() says, the *_trusted argument is never set to false. pkcs7_validate_trust() only positively sets *_trusted upon encountering a trusted PKCS#7 SignedInfo block. This is quite unfortunate since its callers, system_verify_data() for example, depend on pkcs7_validate_trust() clearing *_trusted on non-trust. Indeed, UBSAN splats when attempting to load the uninitialized local variable 'trusted' from system_verify_data() in pkcs7_validate_trust(): UBSAN: Undefined behaviour in crypto/asymmetric_keys/pkcs7_trust.c:194:14 load of value 82 is not a valid value for type '_Bool' [...] Call Trace: [] dump_stack+0xbc/0x117 [] ? _atomic_dec_and_lock+0x169/0x169 [] ubsan_epilogue+0xd/0x4e [] __ubsan_handle_load_invalid_value+0x111/0x158 [] ? val_to_string.constprop.12+0xcf/0xcf [] ? x509_request_asymmetric_key+0x114/0x370 [] ? kfree+0x220/0x370 [] ? public_key_verify_signature_2+0x32/0x50 [] pkcs7_validate_trust+0x524/0x5f0 [] system_verify_data+0xca/0x170 [] ? top_trace_array+0x9b/0x9b [] ? __vfs_read+0x279/0x3d0 [] mod_verify_sig+0x1ff/0x290 [...] The implication is that pkcs7_validate_trust() effectively grants trust when it really shouldn't have. Fix this by explicitly setting *_trusted to false at the very beginning of pkcs7_validate_trust(). Signed-off-by: Nicolai Stange --- Applicable to linux-next-20160318 crypto/asymmetric_keys/pkcs7_trust.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/crypto/asymmetric_keys/pkcs7_trust.c b/crypto/asymmetric_keys/pkcs7_trust.c index 3bbdcc7..7d7a39b4 100644 --- a/crypto/asymmetric_keys/pkcs7_trust.c +++ b/crypto/asymmetric_keys/pkcs7_trust.c @@ -178,6 +178,8 @@ int pkcs7_validate_trust(struct pkcs7_message *pkcs7, int cached_ret = -ENOKEY; int ret; + *_trusted = false; + for (p = pkcs7->certs; p; p = p->next) p->seen = false;