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;
Date:   Tue, 28 Sep 2021 15:14:50 +0200
From:   Valentin =?utf-8?B?VmlkacSH?= <vvidic@valentin-vidic.from.hr>
To:     Joseph Qi <joseph.qi@linux.alibaba.com>
Cc:     Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
        ocfs2-devel@oss.oracle.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ocfs2: mount fails with buffer overflow in strlen
Message-ID: <20210928131450.GM28341@valentin-vidic.from.hr>
References: <20210927154459.15976-1-vvidic@valentin-vidic.from.hr>
 <00850aed-2027-a0ab-e801-c6498a5a49f8@linux.alibaba.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00850aed-2027-a0ab-e801-c6498a5a49f8@linux.alibaba.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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*/
};

-- 
Valentin