From patchwork Thu May 21 00:47:04 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 225511 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3D3BC433E0 for ; Thu, 21 May 2020 00:47:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BD613207C4 for ; Thu, 21 May 2020 00:47:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590022027; bh=TIeCM9HRLKGl2MiR6xyahDh34ipHsgtuhK8ve9sGlHs=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=vSow0VFoL5YUPuBL14gIsEvtOCI7oSDwCtTW+3ta7WKNSWnIjtTvXNqbLUoYoebKm Vt5apZfWGjXYpU8TtBjaBJ8p2OVAUqYlEZ9xZ2zBJbB3ggZsKd7VR1P+kGNCM4kp8L Y4Uh387HHKqPmufZsJA3URsFg2WXuPp+HskH7j+c= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726791AbgEUArG (ORCPT ); Wed, 20 May 2020 20:47:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:35266 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726819AbgEUArF (ORCPT ); Wed, 20 May 2020 20:47:05 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9E3DB2070A; Thu, 21 May 2020 00:47:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590022024; bh=TIeCM9HRLKGl2MiR6xyahDh34ipHsgtuhK8ve9sGlHs=; h=Date:From:To:Subject:In-Reply-To:From; b=GsMfpHVlB/PDwVf/bCK2jrr8OFNzLAeb2kzv/46VYHW0IiF2VrE6/6rc2aue4AHQz H44FXiZRMFQrahfJ6w1X8J+0gghwf0E33Difm+mOuO231M9VHrvY5kXjqSf4leSVyb 8k3W+QDCSrG7o7RMZl4S7iqiEbngwkbFVfHYHC04= Date: Wed, 20 May 2020 17:47:04 -0700 From: Andrew Morton To: cai@lca.pw, mm-commits@vger.kernel.org, shentino@gmail.com, stable@vger.kernel.org, uladzislau.rezki@sony.com, vitaly.wool@konsulko.com Subject: + z3fold-fix-use-after-free-when-freeing-handles.patch added to -mm tree Message-ID: <20200521004704.PNIP1YkNw%akpm@linux-foundation.org> In-Reply-To: <20200513175005.1f4839360c18c0238df292d1@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch titled Subject: z3fold: fix use-after-free when freeing handles has been added to the -mm tree. Its filename is z3fold-fix-use-after-free-when-freeing-handles.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/z3fold-fix-use-after-free-when-freeing-handles.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/z3fold-fix-use-after-free-when-freeing-handles.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Uladzislau Rezki Subject: z3fold: fix use-after-free when freeing handles free_handle() for a foreign handle may race with inter-page compaction, what can lead to memory corruption. To avoid that, take write lock not read lock in free_handle to be synchronized with __release_z3fold_page(). For example KASAN can detect it: [ 33.723357] ================================================================== [ 33.723401] BUG: KASAN: use-after-free in LZ4_decompress_safe+0x2c4/0x3b8 [ 33.723418] Read of size 1 at addr ffffffc976695ca3 by task GoogleApiHandle/4121 [ 33.723428] [ 33.723449] CPU: 0 PID: 4121 Comm: GoogleApiHandle Tainted: P S OE 4.19.81-perf+ #162 [ 33.723461] Hardware name: Sony Mobile Communications. PDX-203(KONA) (DT) [ 33.723473] Call trace: [ 33.723495] dump_backtrace+0x0/0x288 [ 33.723512] show_stack+0x14/0x20 [ 33.723533] dump_stack+0xe4/0x124 [ 33.723551] print_address_description+0x80/0x2e0 [ 33.723566] kasan_report+0x268/0x2d0 [ 33.723584] __asan_load1+0x4c/0x58 [ 33.723601] LZ4_decompress_safe+0x2c4/0x3b8 [ 33.723619] lz4_decompress_crypto+0x3c/0x70 [ 33.723636] crypto_decompress+0x58/0x70 [ 33.723656] zcomp_decompress+0xd4/0x120 ... Apart from that, initialize zhdr->mapped_count in init_z3fold_page() and remove "newpage" variable because it is not used anywhere. Link: http://lkml.kernel.org/r/20200520082100.28876-1-vitaly.wool@konsulko.com Signed-off-by: Uladzislau Rezki Signed-off-by: Vitaly Wool Cc: Qian Cai Cc: Raymond Jennings Cc: Signed-off-by: Andrew Morton --- mm/z3fold.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/mm/z3fold.c~z3fold-fix-use-after-free-when-freeing-handles +++ a/mm/z3fold.c @@ -318,16 +318,16 @@ static inline void free_handle(unsigned slots = handle_to_slots(handle); write_lock(&slots->lock); *(unsigned long *)handle = 0; - write_unlock(&slots->lock); - if (zhdr->slots == slots) + if (zhdr->slots == slots) { + write_unlock(&slots->lock); return; /* simple case, nothing else to do */ + } /* we are freeing a foreign handle if we are here */ zhdr->foreign_handles--; is_free = true; - read_lock(&slots->lock); if (!test_bit(HANDLES_ORPHANED, &slots->pool)) { - read_unlock(&slots->lock); + write_unlock(&slots->lock); return; } for (i = 0; i <= BUDDY_MASK; i++) { @@ -336,7 +336,7 @@ static inline void free_handle(unsigned break; } } - read_unlock(&slots->lock); + write_unlock(&slots->lock); if (is_free) { struct z3fold_pool *pool = slots_to_pool(slots); @@ -422,6 +422,7 @@ static struct z3fold_header *init_z3fold zhdr->start_middle = 0; zhdr->cpu = -1; zhdr->foreign_handles = 0; + zhdr->mapped_count = 0; zhdr->slots = slots; zhdr->pool = pool; INIT_LIST_HEAD(&zhdr->buddy); From patchwork Thu May 14 00:50:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 225905 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8134AC433E0 for ; Thu, 14 May 2020 00:50:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 959922065D for ; Thu, 14 May 2020 00:50:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589417450; bh=cyxWQd0GdMNFqFcobEzn6Kiq0AZWUu6yL4nHjzOM57M=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=kW6lYCYB1nZsUGHjamwJqo0woiiaPRq/W2q2ue/x2y8Hp2S2sm/ZW81lCnUpNkixn OPnrstvBdW9Tb/0HTyrD81we9WlhBCIwNYAuv/EPrfo5JOPkb0GVLXt+zH5fDAThkt wSx5wUKp+mIAVvyVMyXie8p4qQeNnR5PMEdnyl2w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730570AbgENAuu (ORCPT ); Wed, 13 May 2020 20:50:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:56128 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728313AbgENAut (ORCPT ); Wed, 13 May 2020 20:50:49 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0FA2E2065C; Thu, 14 May 2020 00:50:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589417449; bh=cyxWQd0GdMNFqFcobEzn6Kiq0AZWUu6yL4nHjzOM57M=; h=Date:From:To:Subject:In-Reply-To:From; b=DadiJEPIKXXomoYyy+zwrkDTfnq0K31kLI/uB3E/plUZ4J9/5aoBQQDrv9uBryF0r V6lADcjnctYjh2IIVo7qvzWoLu8Y7v7xZvux1od0OaJdVuH/XkIRIkmDVBEOjGxAQ9 N+O34UrAHAAlZcu6gwKnodMbmbAuebIlaapr3VIE= Date: Wed, 13 May 2020 17:50:48 -0700 From: Andrew Morton To: akpm@linux-foundation.org, dave@stgolabs.net, linux-mm@kvack.org, longman@redhat.com, manfred@colorfullife.com, mingo@redhat.com, mm-commits@vger.kernel.org, neilb@suse.com, oberpar@linux.ibm.com, rostedt@goodmis.org, schwab@suse.de, stable@vger.kernel.org, torvalds@linux-foundation.org, vvs@virtuozzo.com Subject: [patch 5/7] ipc/util.c: sysvipc_find_ipc() incorrectly updates position index Message-ID: <20200514005048.N5zHLNCxr%akpm@linux-foundation.org> In-Reply-To: <20200513175005.1f4839360c18c0238df292d1@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Vasily Averin Subject: ipc/util.c: sysvipc_find_ipc() incorrectly updates position index Commit 89163f93c6f9 ("ipc/util.c: sysvipc_find_ipc() should increase position index") is causing this bug (seen on 5.6.8): # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages # ipcmk -Q Message queue id: 0 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x82db8127 0 root 644 0 0 # ipcmk -Q Message queue id: 1 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x82db8127 0 root 644 0 0 0x76d1fb2a 1 root 644 0 0 # ipcrm -q 0 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x76d1fb2a 1 root 644 0 0 0x76d1fb2a 1 root 644 0 0 # ipcmk -Q Message queue id: 2 # ipcrm -q 2 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x76d1fb2a 1 root 644 0 0 0x76d1fb2a 1 root 644 0 0 # ipcmk -Q Message queue id: 3 # ipcrm -q 1 # ipcs -q ------ Message Queues -------- key msqid owner perms used-bytes messages 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 0x7c982867 3 root 644 0 0 Whenever an IPC item with a low id is deleted, the items with higher ids are duplicated, as if filling a hole. new_pos should jump through hole of unused ids, pos can be updated inside "for" cycle. Link: http://lkml.kernel.org/r/4921fe9b-9385-a2b4-1dc4-1099be6d2e39@virtuozzo.com Fixes: 89163f93c6f9 ("ipc/util.c: sysvipc_find_ipc() should increase position index") Signed-off-by: Vasily Averin Reported-by: Andreas Schwab Acked-by: Waiman Long Cc: NeilBrown Cc: Steven Rostedt Cc: Ingo Molnar Cc: Peter Oberparleiter Cc: Davidlohr Bueso Cc: Manfred Spraul Cc: Signed-off-by: Andrew Morton --- ipc/util.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/ipc/util.c~ipc-utilc-sysvipc_find_ipc-incorrectly-updates-position-index +++ a/ipc/util.c @@ -764,21 +764,21 @@ static struct kern_ipc_perm *sysvipc_fin total++; } - *new_pos = pos + 1; + ipc = NULL; if (total >= ids->in_use) - return NULL; + goto out; for (; pos < ipc_mni; pos++) { ipc = idr_find(&ids->ipcs_idr, pos); if (ipc != NULL) { rcu_read_lock(); ipc_lock_object(ipc); - return ipc; + break; } } - - /* Out of range - return NULL to terminate iteration */ - return NULL; +out: + *new_pos = pos + 1; + return ipc; } static void *sysvipc_proc_next(struct seq_file *s, void *it, loff_t *pos)