Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp977469pxb; Wed, 29 Sep 2021 14:00:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxb8iSumn7wCY5M3tT+VOGJiS4nLEG+RAc8XLJuC5//mUCOHNNrs2/Ag2QurYfPNSCqYDfx X-Received: by 2002:a63:1444:: with SMTP id 4mr1613411pgu.381.1632949255595; Wed, 29 Sep 2021 14:00:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632949255; cv=none; d=google.com; s=arc-20160816; b=hi3jsYYGeKTqCCaMIXKIKvNW0CoiIlEMj/aB3cUBVd3p5RxQg7gCg57e41+dJh4Jh1 bEYZrlgxOt0LiDGVXZhD82JEWe/rfvKeDSXS1JmeypDLwgMy5rgNyxuANai8kaJKe53h 2EA56dGMQN8jMUpFR6uMcvn7kuXI0oxzBQdUWUYVGhKnfJyRhyYpAjZhme9ahZJbDb1L 4pfhTIqZL+fIDl6EfdwVod0k3ztlrfvM0/iyM2PJyOZUCCIaT6XZoF/mHZPqL90T8BKn iT9zdS/v5VNGzlBoTw7CtTqx1xiuq9ujt7+GdLSij7mn3m/cUx4Zz5YuZzb+s3TiIuBr hmRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=a4hgCGqLnOw4G78VKKZ4rKp4IkCN+FVD1nc+E4fDymY=; b=J01951F3i4Ux52+yrb7NJKalSPiF7QczvIq056PruiVtZ2jkcHbrN9WlnmArJtr2Zp SaM2ixpTf3tuFKqnJTsDdCjIgfIyf+UvJa5faKBlxSsUAlk00WcpNrq1v4Wv3D3QnVH+ ptBF8WwH3lGyZyWdM3lQiBeUwiIZuq+y4C5KZUSIh8NgOHw62PowyXaZVK6WMhvMW1nc 9lb36pNlsLoFi5Gc4wtPS37JZNixshKsaF9d+z8Y0QPjiANXtMDszbxcDxMnfvlBfmjJ +9wy64auvqkoTCjuZ9i2Xix6rXkLjjX7Mk60Qd271bJydQ5ZUxIqPLkUiyP6wwYp0jH0 xSYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@valentin-vidic.from.hr header.s=2020 header.b=sdS2bbQB; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=valentin-vidic.from.hr Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i1si989483pgt.343.2021.09.29.14.00.40; Wed, 29 Sep 2021 14:00:55 -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; dkim=pass header.i=@valentin-vidic.from.hr header.s=2020 header.b=sdS2bbQB; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=valentin-vidic.from.hr Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344304AbhI2SJ2 (ORCPT + 99 others); Wed, 29 Sep 2021 14:09:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344935AbhI2SJ1 (ORCPT ); Wed, 29 Sep 2021 14:09:27 -0400 Received: from valentin-vidic.from.hr (valentin-vidic.from.hr [IPv6:2001:470:1f0b:3b7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90DC9C061765 for ; Wed, 29 Sep 2021 11:07:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at valentin-vidic.from.hr Received: by valentin-vidic.from.hr (Postfix, from userid 1000) id 8E8D270E4; Wed, 29 Sep 2021 20:07:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valentin-vidic.from.hr; s=2020; t=1632938853; bh=a4hgCGqLnOw4G78VKKZ4rKp4IkCN+FVD1nc+E4fDymY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sdS2bbQB9uPYAZo21xxdKc66KYqEP4/cqU1xWRvfIUmc+JSkrePKVBZE+33WnULTg A092ivEz9xBe+QWnxKY/4Ogu/muIrZCYCbgy36rvMopygg8nh9DRLh2bNtYpfghtI9 8kUYzks+EfhGQPCAN2CEskpZdli/42er4qjDiMK6hjHjFfvBPk1FKHaDQxWJkL+Twm COvgI658MLmREAFhFSV3u2IKDiTZU0NuXUnq+kkNwuKfF+G+o+tnBbQcHGaxbrw6jg 2EQ5p5LvRUnyGH/BbORo9seeLtk5feEdDPVs4l92W59WmrZJ1zUoLvyq6ZCDYb1Rrm owuB5SqnMc/dSI/GQGogGY7sEBQDX3sRcEVXw8TgIo44PnxnNjoBHSX2/ckfpBu+iR QdlYHFlvk+t0zSn+UZPvGDpYmH/BT6lYIDe4yKRXwQ/hQAYBM7adhrlbx9L4JCKk+G 2sjvn1vBCutEEDmzyt+f7l/mpNgvE0AHtsBdyABkGICg0RcCJ0hOcv+cJTI7VHcSu7 RWyonXgDD+udaOvuWHbNvskTOK7YV5+OCoiRntLDG61iyn/aecdWMVPPZloFM5/mQx eKST4jGW8Y2MzhsooCSW45Nqi5tkDg5eCAgI9/3Kt0N6v+Ql4IL2alC+xdaDE9pLI5 bXpMPF7xYBWsUy/iLOICzMm4= From: Valentin Vidic To: Joseph Qi Cc: Mark Fasheh , Joel Becker , ocfs2-devel@oss.oracle.com, linux-kernel@vger.kernel.org, Valentin Vidic Subject: [PATCH v2] ocfs2: mount fails with buffer overflow in strlen Date: Wed, 29 Sep 2021 20:06:54 +0200 Message-Id: <20210929180654.32460-1-vvidic@valentin-vidic.from.hr> X-Mailer: git-send-email 2.20.1 In-Reply-To: <1ab61ba3-8c9b-092c-7843-9c45b58e3987@linux.alibaba.com> References: <1ab61ba3-8c9b-092c-7843-9c45b58e3987@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the trace below. Problem seems to be that strings for cluster stack and cluster name are not guaranteed to be null terminated in the disk representation, while strlcpy assumes that the source string is always null terminated. This causes a read outside of the source string triggering the buffer overflow detection. detected buffer overflow in strlen ------------[ cut here ]------------ kernel BUG at lib/string.c:1149! invalid opcode: 0000 [#1] SMP PTI CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1 Debian 5.14.6-2 RIP: 0010:fortify_panic+0xf/0x11 ... Call Trace: ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2] ocfs2_fill_super+0x359/0x19b0 [ocfs2] mount_bdev+0x185/0x1b0 ? ocfs2_remount+0x440/0x440 [ocfs2] legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 path_mount+0x454/0xa20 __x64_sys_mount+0x103/0x140 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Valentin Vidic --- v2: update description, add comment, drop null termination fs/ocfs2/super.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c index c86bd4e60e20..5c914ce9b3ac 100644 --- a/fs/ocfs2/super.c +++ b/fs/ocfs2/super.c @@ -2167,11 +2167,17 @@ static int ocfs2_initialize_super(struct super_block *sb, } if (ocfs2_clusterinfo_valid(osb)) { + /* + * ci_stack and ci_cluster in ocfs2_cluster_info may not be null + * terminated, so make sure no overflow happens here by using + * memcpy. Destination strings will always be null terminated + * because osb is allocated using kzalloc. + */ osb->osb_stackflags = OCFS2_RAW_SB(di)->s_cluster_info.ci_stackflags; - strlcpy(osb->osb_cluster_stack, + memcpy(osb->osb_cluster_stack, OCFS2_RAW_SB(di)->s_cluster_info.ci_stack, - OCFS2_STACK_LABEL_LEN + 1); + OCFS2_STACK_LABEL_LEN); if (strlen(osb->osb_cluster_stack) != OCFS2_STACK_LABEL_LEN) { mlog(ML_ERROR, "couldn't mount because of an invalid " @@ -2180,9 +2186,9 @@ static int ocfs2_initialize_super(struct super_block *sb, status = -EINVAL; goto bail; } - strlcpy(osb->osb_cluster_name, + memcpy(osb->osb_cluster_name, OCFS2_RAW_SB(di)->s_cluster_info.ci_cluster, - OCFS2_CLUSTER_NAME_LEN + 1); + OCFS2_CLUSTER_NAME_LEN); } else { /* The empty string is identical with classic tools that * don't know about s_cluster_info. */ -- 2.30.2