Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932860AbcDTODd (ORCPT ); Wed, 20 Apr 2016 10:03:33 -0400 Received: from mga04.intel.com ([192.55.52.120]:9039 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754350AbcDTODc (ORCPT ); Wed, 20 Apr 2016 10:03:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,509,1455004800"; d="scan'208";a="962729989" From: Jani Nikula To: Chris Wilson , Peter Jones Cc: linux-efi@vger.kernel.org, Jason Andryuk , Matt Fleming , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, Matthew Garrett , Laszlo Ersek Subject: Re: [Intel-gfx] [PATCH] lib: Always NUL terminate ucs2_as_utf8 In-Reply-To: <1461141427-16361-1-git-send-email-chris@chris-wilson.co.uk> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <1461141427-16361-1-git-send-email-chris@chris-wilson.co.uk> User-Agent: Notmuch/0.21+91~gada1e33 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Wed, 20 Apr 2016 17:03:28 +0300 Message-ID: <871t60nzrj.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2509 Lines: 46 On Wed, 20 Apr 2016, Chris Wilson wrote: > If the caller, in this case efivarfs_callback(), only provides sufficent > room for the expanded utf8 and not enough to include the terminating NUL > byte, that NUL byte is skipped. When the caller then interprets it as a > string, it may then read from past its allocated memory: > > [ 170.605647] WARNING: kmemcheck: Caught 8-bit read from uninitialized memory (ffff8804079ae786) > [ 170.605677] 436f6e4f757400004c44322d35363062663538612d316530642d346437652d39 > [ 170.606037] i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u u u > [ 170.606236] ^ > [ 170.606243] RIP: 0010:[] [] efivar_variable_is_removable+0xaf/0xf0 > [ 170.606346] RSP: 0018:ffff880408e73c20 EFLAGS: 00010206 > [ 170.606352] RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000000006 > [ 170.606359] RDX: 0000000000000000 RSI: 0000000000000074 RDI: ffff880408e73c30 > [ 170.606365] RBP: ffff880408e73c80 R08: 0000000000000006 R09: 000000000000008c > [ 170.606371] R10: 0000000000000006 R11: 0000000000000000 R12: ffffffff8166ed20 > [ 170.606378] R13: 11d293ca8be4df61 R14: ffffffff81773834 R15: ffff8804079ae780 > [ 170.606385] FS: 0000000000000000(0000) GS:ffff88041ca00000(0000) knlGS:0000000000000000 > [ 170.606392] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 170.606399] CR2: ffff880409cbe4c0 CR3: 00000004085fd000 CR4: 00000000001406f0 > [ 170.606405] [] efivarfs_callback+0xf8/0x275 > [ 170.606418] [] efivar_init+0x248/0x2e0 > [ 170.606440] [] efivarfs_fill_super+0xb4/0xf0 > [ 170.606452] [] mount_single+0x87/0xb0 > [ 170.606463] [] efivarfs_mount+0x13/0x20 > [ 170.606475] [] mount_fs+0x10/0x90 > [ 170.606497] [] vfs_kern_mount+0x62/0x100 > [ 170.606508] [] do_mount+0x1e0/0xcd0 > [ 170.606519] [] SyS_mount+0x8f/0xd0 > [ 170.606530] [] entry_SYSCALL_64_fastpath+0x17/0x93 > [ 170.606542] [] 0xffffffffffffffff So I eyeballed the code a bit, and came across efivar_validate(), which calls variable_matches(), which definitely can access off by one beyond the passed in var_name on that call path. However I can't match that up with your backtrace, so may be another bug. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center