From mboxrd@z Thu Jan 1 00:00:00 1970 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=-8.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=unavailable 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 29E16C2D0E4 for ; Mon, 23 Nov 2020 14:27:50 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9A15520758 for ; Mon, 23 Nov 2020 14:27:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1EMGWJ32" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A15520758 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=vqaoy+Sqzu/KxHeVeLSjZr5jtSfLN641GH1cqqo0V5M=; b=1EMGWJ32v83sWPlD17OMO/iEE XnwuZa00y8i7SHhxbE+Cg467Gge3gWopOwUCvJJqpyf5V8t1WNOH7zfKcRp4xGdOd3fU5Vc9TCJPy BDh62O3dh2NMtTMonpH3HiPbfmLAggDpwXKkv4jNRIPCsK+rrlyQWsilDzbVwwYUxu0na4hTOlG5r eZhnpSIq0hxzTvYlFbel/7HCoAXW/cnov4zCM04ATWGMS6HQM9QDjd3mC5Pkkf8BhvdNQREY7b/8V O88cPgl04a3gp0J7fu0n5qlir24hufvJPGf3jFfdgvVhivUIYOb8z7laBAq+BCtDODpP3rOYdv85d 1e1EWin7w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khCnX-00068Z-EG; Mon, 23 Nov 2020 14:26:31 +0000 Received: from bhuna.collabora.co.uk ([46.235.227.227]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khCnV-00067b-Cu for linux-arm-kernel@lists.infradead.org; Mon, 23 Nov 2020 14:26:30 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 7711D1F44CB9 From: Gabriel Krisman Bertazi To: Jann Horn Subject: Re: [arm64] kernel BUG at kernel/seccomp.c:1309! Organization: Collabora References: Date: Mon, 23 Nov 2020 09:26:20 -0500 In-Reply-To: (Jann Horn's message of "Mon, 23 Nov 2020 15:02:10 +0100") Message-ID: <87h7pgqhdf.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_092629_546863_7C814AE5 X-CRM114-Status: GOOD ( 23.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sumit Semwal , Arnd Bergmann , Song Liu , Kees Cook , Daniel Borkmann , YiFei Zhu , Netdev , Naresh Kamboju , open list , lkft-triage@lists.linaro.org, Andy Lutomirski , Arnd Bergmann , Andy Lutomirski , Yonghong Song , Thomas Gleixner , Andrii Nakryiko , bpf , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Jann Horn writes: > On Mon, Nov 23, 2020 at 2:45 PM Arnd Bergmann wrote: >> On Mon, Nov 23, 2020 at 12:15 PM Naresh Kamboju >> wrote: >> > >> > While booting arm64 kernel the following kernel BUG noticed on several arm64 >> > devices running linux next 20201123 tag kernel. >> > >> > >> > $ git log --oneline next-20201120..next-20201123 -- kernel/seccomp.c >> > 5c5c5fa055ea Merge remote-tracking branch 'seccomp/for-next/seccomp' >> > bce6a8cba7bf Merge branch 'linus' >> > 7ef95e3dbcee Merge branch 'for-linus/seccomp' into for-next/seccomp >> > fab686eb0307 seccomp: Remove bogus __user annotations >> > 0d8315dddd28 seccomp/cache: Report cache data through /proc/pid/seccomp_cache >> > 8e01b51a31a1 seccomp/cache: Add "emulator" to check if filter is constant allow >> > f9d480b6ffbe seccomp/cache: Lookup syscall allowlist bitmap for fast path >> > 23d67a54857a seccomp: Migrate to use SYSCALL_WORK flag >> > >> > >> > Please find these easy steps to reproduce the kernel build and boot. >> >> Adding Gabriel Krisman Bertazi to Cc, as the last patch (23d67a54857a) here >> seems suspicious: it changes >> >> diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h >> index 02aef2844c38..47763f3999f7 100644 >> --- a/include/linux/seccomp.h >> +++ b/include/linux/seccomp.h >> @@ -42,7 +42,7 @@ struct seccomp { >> extern int __secure_computing(const struct seccomp_data *sd); >> static inline int secure_computing(void) >> { >> - if (unlikely(test_thread_flag(TIF_SECCOMP))) >> + if (unlikely(test_syscall_work(SECCOMP))) >> return __secure_computing(NULL); >> return 0; >> } >> >> which is in the call chain directly before >> >> int __secure_computing(const struct seccomp_data *sd) >> { >> int mode = current->seccomp.mode; >> >> ... >> switch (mode) { >> case SECCOMP_MODE_STRICT: >> __secure_computing_strict(this_syscall); /* may call do_exit */ >> return 0; >> case SECCOMP_MODE_FILTER: >> return __seccomp_filter(this_syscall, sd, false); >> default: >> BUG(); >> } >> } >> >> Clearly, current->seccomp.mode is set to something other >> than SECCOMP_MODE_STRICT or SECCOMP_MODE_FILTER >> while the test_syscall_work(SECCOMP) returns true, and this >> must have not been the case earlier. > > Ah, I think the problem is actually in > 3136b93c3fb2b7c19e853e049203ff8f2b9dd2cd ("entry: Expose helpers to > migrate TIF to SYSCALL_WORK flag"). In the !GENERIC_ENTRY case, it > adds this code: > > +#define set_syscall_work(fl) \ > + set_ti_thread_flag(current_thread_info(), SYSCALL_WORK_##fl) > +#define test_syscall_work(fl) \ > + test_ti_thread_flag(current_thread_info(), SYSCALL_WORK_##fl) > +#define clear_syscall_work(fl) \ > + clear_ti_thread_flag(current_thread_info(), SYSCALL_WORK_##fl) > + > +#define set_task_syscall_work(t, fl) \ > + set_ti_thread_flag(task_thread_info(t), TIF_##fl) > +#define test_task_syscall_work(t, fl) \ > + test_ti_thread_flag(task_thread_info(t), TIF_##fl) > +#define clear_task_syscall_work(t, fl) \ > + clear_ti_thread_flag(task_thread_info(t), TIF_##fl) > > but the SYSCALL_WORK_FLAGS are not valid on !GENERIC_ENTRY, we'll mix > up (on arm64) SYSCALL_WORK_BIT_SECCOMP (==0) and TIF_SIGPENDING (==0). > > As part of fixing this, it might be a good idea to put "enum > syscall_work_bit" behind a "#ifdef CONFIG_GENERIC_ENTRY" to avoid > future accidents like this? Hi Jan, Arnd, That is correct. This is a copy pasta mistake. My apologies. I didn't have a !GENERIC_ENTRY device to test, but just the ifdef would have caught it. -- Gabriel Krisman Bertazi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel