Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp209575pxb; Tue, 28 Sep 2021 19:43:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzqbMHF4iht6Q8DNqUhwgvWHbmGFSW4v0Mm7UBce4TyQINRG6vgDS6r3x4f9Sd2/D5eXSla X-Received: by 2002:a17:90a:c913:: with SMTP id v19mr3748707pjt.169.1632883390297; Tue, 28 Sep 2021 19:43:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632883390; cv=none; d=google.com; s=arc-20160816; b=Uy4jsqkXHKFzgDdy5QiDTUNZQ0SoJMlKVHIQpaiERlhimvGuIgOCVnKsufuczzDgWn VHiNfBwJzfHWtMq+A9P0bZgIwBwm8JZdAYRP9E2yckFjDd8hfOZQPoUBv7JDp6WxGTFV xooH927sWf37DanU/q8jVYNh9R5fwUFh759BLKBwOMs8wOizzg0DeJZtRZd0erUUlLpW NVPy8RQX4w2hCgGSbjzYI8sD8cmNDCjv8TnNIq+/Zt72OyNEhY9YYX3KOPyjpib02IDi Uhwg7Bb/gglzp4C+MfJNs8teQTfj9aEYVecP2MsABByp2UDRragOGE4MMngBPTqa22eX kQFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=zEi35MFZus0jDEF9lIChTIxgKO0NYxKD1XWckBa1ukU=; b=BPtDwuCsd+H8HXpk0abx/wmnoPMD3NOjcgyjgxyvI1ePeTwJO9+LQRJJO69+NsBga5 0wWBk9gZc6gjjQ+qjcSQqwVFHHZd5NA+QhBae0NcJ1q+xKPwxAAl58sFdGxybHPCumuh w6hfG2MlPyWposBI3Nr1TG7pbVQCqKgpNY1MTr6R38HBn4FWE3/aSg5xSse/qw4Kls9+ x5NfJcvDur+DVCPxAjZxiS4m6rUbc000sVME92g+ZZoWu9wBZRcLKfwFUFJBr7Q9fEmh 2g4Yt7NnFJLe0Uy6WMObwwiZJ/3SC7BW7k/sp2DPTbu8E99NdvPXI6SxzAZ0m0e8F4Fh GcXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z10si1084321pgi.529.2021.09.28.19.42.35; Tue, 28 Sep 2021 19:43:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243807AbhI2Ckn (ORCPT + 99 others); Tue, 28 Sep 2021 22:40:43 -0400 Received: from out30-44.freemail.mail.aliyun.com ([115.124.30.44]:37784 "EHLO out30-44.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243800AbhI2Ckn (ORCPT ); Tue, 28 Sep 2021 22:40:43 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=joseph.qi@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0UpzQBf1_1632883139; Received: from B-D1K7ML85-0059.local(mailfrom:joseph.qi@linux.alibaba.com fp:SMTPD_---0UpzQBf1_1632883139) by smtp.aliyun-inc.com(127.0.0.1); Wed, 29 Sep 2021 10:39:00 +0800 Subject: Re: [PATCH] ocfs2: mount fails with buffer overflow in strlen To: =?UTF-8?Q?Valentin_Vidi=c4=87?= Cc: Mark Fasheh , Joel Becker , ocfs2-devel@oss.oracle.com, linux-kernel@vger.kernel.org References: <20210927154459.15976-1-vvidic@valentin-vidic.from.hr> <00850aed-2027-a0ab-e801-c6498a5a49f8@linux.alibaba.com> <20210928131450.GM28341@valentin-vidic.from.hr> From: Joseph Qi Message-ID: <212f878e-1bbe-347c-ba43-e4ffb9b4afbe@linux.alibaba.com> Date: Wed, 29 Sep 2021 10:38:59 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20210928131450.GM28341@valentin-vidic.from.hr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Okay, you are right, strlen(src) is indeed wrong here. But please note that in strlcpy(): if (size) { size_t len = (ret >= size) ? size - 1 : ret; memcpy(dest, src, len); dest[len] = '\0'; } Take ci_stack "o2cb" for example, strlen("o2cb") may return wrong if the coming byte is not null, say it is 10. The input size is 5, so len will finally be 4. So dest is still correct ending with null byte. No overflow happens. So the problem here is the wrong return value, but it is discarded in ocfs2_initialize_super(). Thanks, Joseph On 9/28/21 9:14 PM, Valentin Vidić wrote: > On Tue, Sep 28, 2021 at 08:05:22PM +0800, Joseph Qi wrote: >> strlcpy in ocfs2_initialize_super() is introduced 8 years ago, so I >> don't understand why you've mentioned that the issues starts from >> v5.11. > > v5.11 introduced the overflow checks to string functions so that is > when the mount started to fail. > >> osb->osb_cluster_stack and osb->osb_cluster_name is always larger by >> 1 than which in ocfs2_cluster_info, and the input size of strlcpy does >> the same, so I don't see how it overflows. > > strlcpy internally calls strlen on the source argument, in this case > that is ci_stack array with size of 4. That array stores the value > "o2cb" so the strlen continues reading into the union until it reaches > a zero byte somewhere. The same would happen with ci_cluster if the > cluster name is long enough. > > struct ocfs2_cluster_info { > /*00*/ __u8 ci_stack[OCFS2_STACK_LABEL_LEN]; > union { > __le32 ci_reserved; > struct { > __u8 ci_stackflags; > __u8 ci_reserved1; > __u8 ci_reserved2; > __u8 ci_reserved3; > }; > }; > /*08*/ __u8 ci_cluster[OCFS2_CLUSTER_NAME_LEN]; > /*18*/ > }; >