Received: by 2002:ab2:1689:0:b0:1f7:5705:b850 with SMTP id d9csp1271651lqa; Mon, 29 Apr 2024 03:49:17 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUAAw07gOK/v6Pf2d63rjXxXTtHlMONSR8xotBXNxvnvW9TPedoraPbjFwoX7ap5catAlHBB3FzDPVUpf+wmyPGr2IbySZo9A6bThl6NA== X-Google-Smtp-Source: AGHT+IETpa7rXUtkq2svrjR2CGRhht3cPimfYe3i4J2MCMcHR3ZeIo2c1UMq6xKd6/bS/FPbpH1s X-Received: by 2002:a05:6a20:9692:b0:1ad:3d92:fdcc with SMTP id hp18-20020a056a20969200b001ad3d92fdccmr8365368pzc.33.1714387757286; Mon, 29 Apr 2024 03:49:17 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714387757; cv=pass; d=google.com; s=arc-20160816; b=tj3nhpjKpqoe7fM4BfjIm0vsLOjgIngKTyg4B1VQGCafmP/CNNih+XGxYz51S+D7XG tHKTHKoVz109LYNHxQR5uQMcc5YZ4O6CccFnaGqnKLZXpOourB5Xnih0eV+ccwJM28me hhCMT8GYmpHFMRpKsfnfeX+DKG72K1ymGz1ZnBhnPG95emkG3Rlqzx3ZQL6YxKyK+Wro 7xf6Ua65FzcgP/xfWUTIHNnG5NoF+MnjKumdsEyWxHVP8l2E/lttBmpoU8gQYqUBNQ3u ONN43jZVmZOlQiEbpZn6U/tAq9MQt1Ed+5J3AmA34YlWH6w1iIh/WDgu+bFZnHZgOMSY raWA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from; bh=4P5BROAyhrkc4HdoTDNxiCneJaC37pDgiSLsxe7LRPM=; fh=NQFuGxiyfvDG7cj3iFAWNfJqtert4OPmD5tAQjzYz4c=; b=ow049X0c78V1ChywFNBgA2LZhe6kRhxaIUQO+9wIL9iBfXLY6vnfOTRmYOPD5xfqA0 pyzNWtPadKw6pJi6nSMU9aD2h+zPxBVb60JhJPhKCCFmsDDyz2iVDlzxxP2N6DF1RWn4 kIO5AQEH8DrDXM9C7NGwolaQkaFYv+e6MSUVrOzwxR8b4rCe1RrAxLjqtQMVhLIo/gWM h00H77XkdlTgggkmNizbXIC9984fd2PGiXu2xU/7COaXl9Z5kS3quOBppFpR6TrqW2Gm fOGlDzEgIvsp20Rq6MO/3V4WYIJrUcoGF2gbMMZZmkQqH8Z7Jn15OGEIGdG6Q8/Ywuo5 nZ4g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=sina.com); spf=pass (google.com: domain of linux-kernel+bounces-162078-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-162078-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id l190-20020a6391c7000000b006043ae69969si10880038pge.386.2024.04.29.03.49.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Apr 2024 03:49:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-162078-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=sina.com); spf=pass (google.com: domain of linux-kernel+bounces-162078-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-162078-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 9C106B24225 for ; Mon, 29 Apr 2024 10:39:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 26CE33715E; Mon, 29 Apr 2024 10:39:40 +0000 (UTC) Received: from mail115-118.sinamail.sina.com.cn (mail115-118.sinamail.sina.com.cn [218.30.115.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 069A425740 for ; Mon, 29 Apr 2024 10:39:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=218.30.115.118 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714387179; cv=none; b=XR19415ipnGXzIx0I9Nzkp1oqWaXSHDvOBD6IAU12S3YPkYUoYEYBX4XZAqPVnENv2f96Gfg7ZrSaUqh5DWCuPxAVn+AF4jd7HuNmVCtBKo2NQyj+qcoJbElMFLpOnBKlxhUnEKRQNah1LDsTX7hvrN8SBy7m3INAlWxKUu4n8Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714387179; c=relaxed/simple; bh=9jE0GTm5P/uqv9uO3+erZmYd5H6Mc3PC/JSw9IABH5o=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=SwxLQjE6trZ5oPfv65CD6nn17P51dtxs9kJ5lqyiEpIAvLl4fuYrZeQPka5u7YRJmk2nPB7HMl3JgJ4fHC/kPiHATMdo93vHwPbiR1Z/bsGAboUiOoJjY9F1ruM0nUeXz/XpMbRU9zeoEBprqu6eEZG5VDhJtHdqEV7iwC4UNYI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; arc=none smtp.client-ip=218.30.115.118 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([116.24.11.20]) by sina.com (172.16.235.25) with ESMTP id 662F78DB000022C8; Mon, 29 Apr 2024 18:39:26 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 33368534210209 X-SMAIL-UIID: 37F82A1DCBD9407ABD847B8711193A14-20240429-183926-1 From: Hillf Danton To: Linus Torvalds Cc: syzbot , Ingo Molnar , Tetsuo Handa , andrii@kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [bpf?] [trace?] possible deadlock in force_sig_info_to_task Date: Mon, 29 Apr 2024 18:39:28 +0800 Message-Id: <20240429103928.4166-1-hdanton@sina.com> In-Reply-To: References: <0000000000009dfa6d0617197994@google.com> <20240427231321.3978-1-hdanton@sina.com> <20240428232302.4035-1-hdanton@sina.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Sun, 28 Apr 2024 18:33:41 -0700 Linus Torvalds wrote: > I cannot find it in myself to care, since I do not believe that > anybody should be running with vsyscall=emulate in 2024 in the first > place, much less if you are doing things like UML. But let's see if > somebody screams. > > Also, somebody should obviously test my COMPLETELY UNTESTED patch. #syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 5eb4573ea63d arch/x86/entry/vsyscall/vsyscall_64.c | 25 ++----------------------- arch/x86/include/asm/processor.h | 1 - arch/x86/mm/fault.c | 33 +-------------------------------- 3 files changed, 3 insertions(+), 56 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c index a3c0df11d0e6..3b0f61b2ea6d 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -98,11 +98,6 @@ static int addr_to_vsyscall_nr(unsigned long addr) static bool write_ok_or_segv(unsigned long ptr, size_t size) { - /* - * XXX: if access_ok, get_user, and put_user handled - * sig_on_uaccess_err, this could go away. - */ - if (!access_ok((void __user *)ptr, size)) { struct thread_struct *thread = ¤t->thread; @@ -123,7 +118,6 @@ bool emulate_vsyscall(unsigned long error_code, struct task_struct *tsk; unsigned long caller; int vsyscall_nr, syscall_nr, tmp; - int prev_sig_on_uaccess_err; long ret; unsigned long orig_dx; @@ -234,12 +228,8 @@ bool emulate_vsyscall(unsigned long error_code, goto do_ret; /* skip requested */ /* - * With a real vsyscall, page faults cause SIGSEGV. We want to - * preserve that behavior to make writing exploits harder. + * With a real vsyscall, page faults cause SIGSEGV. */ - prev_sig_on_uaccess_err = current->thread.sig_on_uaccess_err; - current->thread.sig_on_uaccess_err = 1; - ret = -EFAULT; switch (vsyscall_nr) { case 0: @@ -262,23 +252,12 @@ bool emulate_vsyscall(unsigned long error_code, break; } - current->thread.sig_on_uaccess_err = prev_sig_on_uaccess_err; - check_fault: if (ret == -EFAULT) { /* Bad news -- userspace fed a bad pointer to a vsyscall. */ warn_bad_vsyscall(KERN_INFO, regs, "vsyscall fault (exploit attempt?)"); - - /* - * If we failed to generate a signal for any reason, - * generate one here. (This should be impossible.) - */ - if (WARN_ON_ONCE(!sigismember(&tsk->pending.signal, SIGBUS) && - !sigismember(&tsk->pending.signal, SIGSEGV))) - goto sigsegv; - - return true; /* Don't emulate the ret. */ + goto sigsegv; } regs->ax = ret; diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 811548f131f4..78e51b0d6433 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -472,7 +472,6 @@ struct thread_struct { unsigned long iopl_emul; unsigned int iopl_warn:1; - unsigned int sig_on_uaccess_err:1; /* * Protection Keys Register for Userspace. Loaded immediately on diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 622d12ec7f08..bba4e020dd64 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -723,39 +723,8 @@ kernelmode_fixup_or_oops(struct pt_regs *regs, unsigned long error_code, WARN_ON_ONCE(user_mode(regs)); /* Are we prepared to handle this kernel fault? */ - if (fixup_exception(regs, X86_TRAP_PF, error_code, address)) { - /* - * Any interrupt that takes a fault gets the fixup. This makes - * the below recursive fault logic only apply to a faults from - * task context. - */ - if (in_interrupt()) - return; - - /* - * Per the above we're !in_interrupt(), aka. task context. - * - * In this case we need to make sure we're not recursively - * faulting through the emulate_vsyscall() logic. - */ - if (current->thread.sig_on_uaccess_err && signal) { - sanitize_error_code(address, &error_code); - - set_signal_archinfo(address, error_code); - - if (si_code == SEGV_PKUERR) { - force_sig_pkuerr((void __user *)address, pkey); - } else { - /* XXX: hwpoison faults will set the wrong code. */ - force_sig_fault(signal, si_code, (void __user *)address); - } - } - - /* - * Barring that, we can do the fixup and be happy. - */ + if (fixup_exception(regs, X86_TRAP_PF, error_code, address)) return; - } /* * AMD erratum #91 manifests as a spurious page fault on a PREFETCH --