Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3383945pxb; Mon, 17 Jan 2022 19:13:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJx2zKmh6aMI58qQHDPEito2yYxx5fQ9+/8R+n82qDYPqIZ7Q0FyQ35zvOiNQ3K88rpgxEeg X-Received: by 2002:a62:cecc:0:b0:4be:c057:ad12 with SMTP id y195-20020a62cecc000000b004bec057ad12mr24505537pfg.56.1642475598899; Mon, 17 Jan 2022 19:13:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642475598; cv=none; d=google.com; s=arc-20160816; b=vV08KDzGLGxrzpRArHh/thiuoCKyiaSFR8yWoJHiys9Rb/BI1cGKpDNQ7KtRl/kVmi ZksF0yfpz7pqWb1j5NqHD7vvannM+cSC7wATauuNjKVEcjPeqRuf75oe/RvvuCCsTo9v uHLZj/+Z4yUWNdju0dytRXQoFKp4kTh3YRAxWAPi0f+Fq9W0n6YKppE3A2xKEpPgiw9L +5uGtA7wjTFT5P5JcCh01efUsSFnTmYRpZvu+x3CwSnu8LnytwQ5uwbDTarHk/5y1qXR V3EqZ+R7q9973XZwhe90sjy+DoA7O5WTqqXqeI0Teo5bdcQTVbWtWJbD6p5NERWmWq33 Lu9w== 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=vNwQxx3MFrSZtcP0r3ip4f6JT5Qv7o1YhIAHFkCCdlk=; b=SNUHFA99bv+XGibD9qegYwly7Rg9OKBBJRDTmHX8eBVh79J7DcZG/+Pt3ajzs2jXYX yEQMzjd8sB7tjP37P4FszJY+1duIz/kdzMR82HZtXCP2dfsRfSppzQjzPfNhq3KH57n1 sHxjrZ9KzP6uQ8ChKVuYQ0NwiSbu59Bwjww4hBY8btyrpr8nx9DjwI9MhaKQt5orkusR hT0LfcOWr2/jlKl11zolMkk3AIpuJlzcvtOq8c2ROQOD+CKBnv4uze9IcNek1pSyHJU0 sHiyqhqLaUTou6WzI6xeo4kbplhuo3Jv6TFfY/I7eogWzE8i7GuL5QVy1HY+GKXQhkYS hYcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qga7cYTK; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x23si14499428pln.65.2022.01.17.19.13.07; Mon, 17 Jan 2022 19:13:18 -0800 (PST) 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=@kernel.org header.s=k20201202 header.b=qga7cYTK; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244418AbiARCU0 (ORCPT + 99 others); Mon, 17 Jan 2022 21:20:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244388AbiARCT4 (ORCPT ); Mon, 17 Jan 2022 21:19:56 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEEA3C06161C; Mon, 17 Jan 2022 18:19:55 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 86A53B81232; Tue, 18 Jan 2022 02:19:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72425C36AF2; Tue, 18 Jan 2022 02:19:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642472393; bh=uJoyLqhseUQJo0ZE3D2WIiitPdPERSXYICGFZS49XR4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qga7cYTKCuRVmi67Jh0yGzLi7WsrbEw8NZGYzl2y+dt/dolNln+79eTDspqbydT7U VyG33sQpD1kRq4A2ZOhuNJaf/ruPlnneHDR3GDkj/p3Oxy17XwZrMEA6aQNWUR6KQL Oxjv+ug39Soja+dCqayOnUGTtYDhmykMZ5+GTQCD6hGbSmlN46XEYlpICEM4iOy6Jz jCWQnAWS+rCH5zdjZ0sjhtXlxl619Rlw5abfIKaRm/9fCyBS1D51BugB0fMQjoSwF0 Ax2pyGbUdKfxP3jPp83kcIJKomcO1BE6QL3vI5kdw8F9nwS6Mfbra0dH2JIR/cnZWq BflhVqdVkvQlA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alexander Aring , David Teigland , Sasha Levin , ccaulfie@redhat.com, cluster-devel@redhat.com Subject: [PATCH AUTOSEL 5.16 007/217] fs: dlm: filter user dlm messages for kernel locks Date: Mon, 17 Jan 2022 21:16:10 -0500 Message-Id: <20220118021940.1942199-7-sashal@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220118021940.1942199-1-sashal@kernel.org> References: <20220118021940.1942199-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Alexander Aring [ Upstream commit 6c2e3bf68f3e5e5a647aa52be246d5f552d7496d ] This patch fixes the following crash by receiving a invalid message: [ 160.672220] ================================================================== [ 160.676206] BUG: KASAN: user-memory-access in dlm_user_add_ast+0xc3/0x370 [ 160.679659] Read of size 8 at addr 00000000deadbeef by task kworker/u32:13/319 [ 160.681447] [ 160.681824] CPU: 10 PID: 319 Comm: kworker/u32:13 Not tainted 5.14.0-rc2+ #399 [ 160.683472] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.14.0-1.module+el8.6.0+12648+6ede71a5 04/01/2014 [ 160.685574] Workqueue: dlm_recv process_recv_sockets [ 160.686721] Call Trace: [ 160.687310] dump_stack_lvl+0x56/0x6f [ 160.688169] ? dlm_user_add_ast+0xc3/0x370 [ 160.689116] kasan_report.cold.14+0x116/0x11b [ 160.690138] ? dlm_user_add_ast+0xc3/0x370 [ 160.690832] dlm_user_add_ast+0xc3/0x370 [ 160.691502] _receive_unlock_reply+0x103/0x170 [ 160.692241] _receive_message+0x11df/0x1ec0 [ 160.692926] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 160.693700] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 160.694427] ? lock_acquire+0x175/0x400 [ 160.695058] ? do_purge.isra.51+0x200/0x200 [ 160.695744] ? lock_acquired+0x360/0x5d0 [ 160.696400] ? lock_contended+0x6a0/0x6a0 [ 160.697055] ? lock_release+0x21d/0x5e0 [ 160.697686] ? lock_is_held_type+0xe0/0x110 [ 160.698352] ? lock_is_held_type+0xe0/0x110 [ 160.699026] ? ___might_sleep+0x1cc/0x1e0 [ 160.699698] ? dlm_wait_requestqueue+0x94/0x140 [ 160.700451] ? dlm_process_requestqueue+0x240/0x240 [ 160.701249] ? down_write_killable+0x2b0/0x2b0 [ 160.701988] ? do_raw_spin_unlock+0xa2/0x130 [ 160.702690] dlm_receive_buffer+0x1a5/0x210 [ 160.703385] dlm_process_incoming_buffer+0x726/0x9f0 [ 160.704210] receive_from_sock+0x1c0/0x3b0 [ 160.704886] ? dlm_tcp_shutdown+0x30/0x30 [ 160.705561] ? lock_acquire+0x175/0x400 [ 160.706197] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 160.706941] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 160.707681] process_recv_sockets+0x32/0x40 [ 160.708366] process_one_work+0x55e/0xad0 [ 160.709045] ? pwq_dec_nr_in_flight+0x110/0x110 [ 160.709820] worker_thread+0x65/0x5e0 [ 160.710423] ? process_one_work+0xad0/0xad0 [ 160.711087] kthread+0x1ed/0x220 [ 160.711628] ? set_kthread_struct+0x80/0x80 [ 160.712314] ret_from_fork+0x22/0x30 The issue is that we received a DLM message for a user lock but the destination lock is a kernel lock. Note that the address which is trying to derefence is 00000000deadbeef, which is in a kernel lock lkb->lkb_astparam, this field should never be derefenced by the DLM kernel stack. In case of a user lock lkb->lkb_astparam is lkb->lkb_ua (memory is shared by a union field). The struct lkb_ua will be handled by the DLM kernel stack but on a kernel lock it will contain invalid data and ends in most likely crashing the kernel. It can be reproduced with two cluster nodes. node 2: dlm_tool join test echo "862 fooobaar 1 2 1" > /sys/kernel/debug/dlm/test_locks echo "862 3 1" > /sys/kernel/debug/dlm/test_waiters node 1: dlm_tool join test python: foo = DLM(h_cmd=3, o_nextcmd=1, h_nodeid=1, h_lockspace=0x77222027, \ m_type=7, m_flags=0x1, m_remid=0x862, m_result=0xFFFEFFFE) newFile = open("/sys/kernel/debug/dlm/comms/2/rawmsg", "wb") newFile.write(bytes(foo)) Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin --- fs/dlm/lock.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index c502c065d0075..28d1f35b11a4d 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -3973,6 +3973,14 @@ static int validate_message(struct dlm_lkb *lkb, struct dlm_message *ms) int from = ms->m_header.h_nodeid; int error = 0; + /* currently mixing of user/kernel locks are not supported */ + if (ms->m_flags & DLM_IFL_USER && ~lkb->lkb_flags & DLM_IFL_USER) { + log_error(lkb->lkb_resource->res_ls, + "got user dlm message for a kernel lock"); + error = -EINVAL; + goto out; + } + switch (ms->m_type) { case DLM_MSG_CONVERT: case DLM_MSG_UNLOCK: @@ -4001,6 +4009,7 @@ static int validate_message(struct dlm_lkb *lkb, struct dlm_message *ms) error = -EINVAL; } +out: if (error) log_error(lkb->lkb_resource->res_ls, "ignore invalid message %d from %d %x %x %x %d", -- 2.34.1