Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2797208yba; Mon, 8 Apr 2019 05:05:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqxOOP5QhXDnFS4dxU84+I4RZix3GEkGLilb2lCXoEfYZg9WriimAdVTcdjnIuqvzGJmm1a8 X-Received: by 2002:a65:4bce:: with SMTP id p14mr28703540pgr.376.1554725138218; Mon, 08 Apr 2019 05:05:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554725138; cv=none; d=google.com; s=arc-20160816; b=E3XGMZCceajq6yXKT+B9DqOS67D+4m5nt0evHc0DktFJKHwDzr3ndgMp1fxDOg3gsU jMDexf3f+KhURubkXn1rGjQNugm0PB7LgmO6Plv/Ax8PzlSkXFWQHSLElfHosbnMXd79 /tcLZBuM8lSaMejHukJTTd9SiUDoJRSkC0EfeiULMDZdQNXr5q5wQQikdSdaFmozDOl9 eKcFaDyazPFM9SYmOsbB8qzb+TM3zDKiN9gtNgP5ygNk19OiyhR8dt+FTkc9ripOv9TI SK58AljuPT60TFsnip6JvBAJYNyvSD70ZHRBuc84GC5uRvtVw5cObJqQyqeK1yEeUlFV aA2w== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject; bh=f9UEFBrO4wWBk4sZd4cpdJTKYxP9n76PAynlw3IPhTI=; b=Ay5CUW89x6MqBy70qVNV0tzXGIxY/UHGO0T8cVaYtimCMzelW9f1yDPzkBUEIg5SOf H+IBqI43v5A1czLWPC6SpU+BcWC+lMinYGJINUH6yYY5LREMOt9wP9aqnldmDLVVdTcC 2ZlYNdX57zZjJB/jf0GZDhUfIanvuC1J9ht/JUDUWgg2LzXa2H+DtyhmWRGeaq+BQoRk RV/inxUEaZQiuDaC2rJ4PnlXlVd7FVZd4hdg8Wufs8NDeaiY7B2Y1qdr7lwKF2hk3JC1 nFi71q/cl9SMH3HTdEABklA6apMIg4fgof5gOf5ryggtxQ0s6WArZq+emeEYzI2DOWV4 eBJA== 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 f7si26988050pgg.234.2019.04.08.05.05.22; Mon, 08 Apr 2019 05:05:38 -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 S1726464AbfDHMDM (ORCPT + 99 others); Mon, 8 Apr 2019 08:03:12 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:2522 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726050AbfDHMDM (ORCPT ); Mon, 8 Apr 2019 08:03:12 -0400 Received: from DGGEMM404-HUB.china.huawei.com (unknown [172.30.72.54]) by Forcepoint Email with ESMTP id 476B3E16A1C1A2953609; Mon, 8 Apr 2019 20:03:10 +0800 (CST) Received: from dggeme763-chm.china.huawei.com (10.3.19.109) by DGGEMM404-HUB.china.huawei.com (10.3.20.212) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Apr 2019 20:03:09 +0800 Received: from [10.134.22.195] (10.134.22.195) by dggeme763-chm.china.huawei.com (10.3.19.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 8 Apr 2019 20:03:09 +0800 Subject: Re: [PATCH] f2fs: fix to avoid accessing xattr across the boundary To: Randall Huang , , , References: <20190408085016.13042-1-huangrandall@google.com> From: Chao Yu Message-ID: Date: Mon, 8 Apr 2019 20:03:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190408085016.13042-1-huangrandall@google.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-ClientProxiedBy: dggeme705-chm.china.huawei.com (10.1.199.101) To dggeme763-chm.china.huawei.com (10.3.19.109) X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Randall, On 2019/4/8 16:50, Randall Huang wrote: > When we traverse xattr entries via __find_xattr(), > if the raw filesystem content is faked or any hardware failure occurs, > out-of-bound error can be detected by KASAN. > Fix the issue by introducing boundary check. > > [ 38.402878] c7 1827 BUG: KASAN: slab-out-of-bounds in f2fs_getxattr+0x518/0x68c > [ 38.402891] c7 1827 Read of size 4 at addr ffffffc0b6fb35dc by task > [ 38.402935] c7 1827 Call trace: > [ 38.402952] c7 1827 [] dump_backtrace+0x0/0x6bc > [ 38.402966] c7 1827 [] show_stack+0x20/0x2c > [ 38.402981] c7 1827 [] dump_stack+0xfc/0x140 > [ 38.402995] c7 1827 [] print_address_description+0x80/0x2d8 > [ 38.403009] c7 1827 [] kasan_report_error+0x198/0x1fc > [ 38.403022] c7 1827 [] kasan_report_error+0x0/0x1fc > [ 38.403037] c7 1827 [] __asan_load4+0x1b0/0x1b8 > [ 38.403051] c7 1827 [] f2fs_getxattr+0x518/0x68c > [ 38.403066] c7 1827 [] f2fs_xattr_generic_get+0xb0/0xd0 > [ 38.403080] c7 1827 [] __vfs_getxattr+0x1f4/0x1fc > [ 38.403096] c7 1827 [] inode_doinit_with_dentry+0x360/0x938 > [ 38.403109] c7 1827 [] selinux_d_instantiate+0x2c/0x38 > [ 38.403123] c7 1827 [] security_d_instantiate+0x68/0x98 > [ 38.403136] c7 1827 [] d_splice_alias+0x58/0x348 > [ 38.403149] c7 1827 [] f2fs_lookup+0x608/0x774 > [ 38.403163] c7 1827 [] lookup_slow+0x1e0/0x2cc > [ 38.403177] c7 1827 [] walk_component+0x160/0x520 > [ 38.403190] c7 1827 [] path_lookupat+0x110/0x2b4 > [ 38.403203] c7 1827 [] filename_lookup+0x1d8/0x3a8 > [ 38.403216] c7 1827 [] user_path_at_empty+0x54/0x68 > [ 38.403229] c7 1827 [] SyS_getxattr+0xb4/0x18c > [ 38.403241] c7 1827 [] el0_svc_naked+0x34/0x38 > > Bug: 126558260 > > Signed-off-by: Randall Huang > --- > fs/f2fs/xattr.c | 22 ++++++++++++++++------ > 1 file changed, 16 insertions(+), 6 deletions(-) > > diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c > index 848a785abe25..0531c1e38275 100644 > --- a/fs/f2fs/xattr.c > +++ b/fs/f2fs/xattr.c > @@ -202,12 +202,17 @@ static inline const struct xattr_handler *f2fs_xattr_handler(int index) > return handler; > } > > -static struct f2fs_xattr_entry *__find_xattr(void *base_addr, int index, > - size_t len, const char *name) > +static struct f2fs_xattr_entry *__find_xattr(void *base_addr, > + int base_addr_limit, int index, unsigned int max_size, > + size_t len, const char *name) > { > struct f2fs_xattr_entry *entry; > + void *max_addr = base_addr + ENTRY_SIZE(XATTR_ENTRY(base_addr)) + > + base_addr_limit - 1; If I'm not missing something, shouldn't it be? void *max_addr = base_addr + max_size; > > list_for_each_xattr(entry, base_addr) { > + if ((void *)entry + sizeof(__u32) > max_addr) > + return NULL; > if (entry->e_name_index != index) > continue; > if (entry->e_name_len != len) > @@ -337,9 +342,9 @@ static int lookup_all_xattrs(struct inode *inode, struct page *ipage, > else > cur_addr = txattr_addr; > > - *xe = __find_xattr(cur_addr, index, len, name); > + *xe = __find_xattr(cur_addr, XATTR_PADDING_SIZE, index, len, name); max_size = *base_size - (txattr_addr - cur_addr); *xe = __find_xattr(cur_addr, max_size, index, len, name); > check: > - if (IS_XATTR_LAST_ENTRY(*xe)) { > + if (!*xe || IS_XATTR_LAST_ENTRY(*xe)) { If xattr entry across boundary of max xattr space size, maybe we'd better return -EFAULT which can be distinguished from a real -ENODATA error, latter, we can set SBI_NEED_FSCK to give a repairing hint to fsck. :) > err = -ENODATA; > goto out; > } > @@ -606,9 +611,14 @@ static int __f2fs_setxattr(struct inode *inode, int index, > return error; > > /* find entry with wanted name. */ > - here = __find_xattr(base_addr, index, len, name); > + here = __find_xattr(base_addr, inline_xattr_size(inode) + > + VALID_XATTR_BLOCK_SIZE + XATTR_PADDING_SIZE, > + index, len, name); unsigned int size = F2FS_I(inode)->i_xattr_nid ? VALID_XATTR_BLOCK_SIZE : 0; unsigned int max_size = inline_xattr_size(inode) + size + XATTR_PADDING_SIZE; here = __find_xattr(..., max_size, ...); if (!here) return -EFAULT; Thanks, > > - found = IS_XATTR_LAST_ENTRY(here) ? 0 : 1; > + if (!here) > + found = 0; > + else > + found = IS_XATTR_LAST_ENTRY(here) ? 0 : 1; > > if (found) { > if ((flags & XATTR_CREATE)) { >