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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8CD32C433EF for ; Mon, 29 Nov 2021 14:13:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vt0UP0+yw+VS2VXsset1+vPQFEpjwuUynJq1ZjFnqAA=; b=R/F2LpW8brPraR DiObURcNvnqR+EF6hpLUEdHRBqjn4Lo1LU8wDVSpqKWVnfva155SrNdMsyK2qFknXvVlX2YqYacGd oNWjyokrHH+Tt+48IWGSGYOlAw7q0X/OO7Irr9eJlO9P9SdEMSe9KPldfxo5mX/Amh/dzqSMQ7kDo A9dakslsMScTwLbXT13LuWOtL5hzM8vRJg4yYLq433S2DEUoshpRIjVhAo7MDjwDt0vFLQC3NL3JQ +/vxWnrw+kiUsjqyKvqLSQgeiFv9PFKR4K6sfQWSZzboupbPPWD/QPS7fRbQR6Y8w2J2jrH/2gA1v evlx3z5IrzR7NZLnbADA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mrhNc-000xHq-4w; Mon, 29 Nov 2021 14:11:40 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mrhNM-000xG8-Rr for linux-arm-kernel@lists.infradead.org; Mon, 29 Nov 2021 14:11:26 +0000 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 dfw.source.kernel.org (Postfix) with ESMTPS id C653D61523 for ; Mon, 29 Nov 2021 14:11:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 386BFC004E1 for ; Mon, 29 Nov 2021 14:11:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638195083; bh=x7gANHXCj9D2jHArSELv0y5uHzyFEQHNRCPsvkTF7Ig=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iNUsntFyxDfkFs/HGTqojPv+3tLdNcEC6oBQRPlXoTB0CVQRJHniOMQeocKDGbXez z9Kohzcm3ftOZyq3oRq0RZyVqSrwR1v3ou7PwWIayS/KGeuLASLNyz4LyVWhHV6fZ3 SDhocSeSec8g+jR3FuQb+zPyG0HKsoWvxg6IZ0bDU+8HPjKfOSpK3666oQazAX5+rf caj7GS2Q3UTzyy1DhQmh25AOzdaoF+qC6wQoTjf/s7aMyUolupsQ3V8SYsHh7xsDS0 Q95zfpdOIv6fyH6fBt2lR70PKnjGdWJjK13izpyWbWcxyP6qpr63haYXwnRGWH0lMB q6jmDDVZ14xGQ== Received: by mail-ot1-f43.google.com with SMTP id h19-20020a9d3e53000000b0056547b797b2so25664102otg.4 for ; Mon, 29 Nov 2021 06:11:23 -0800 (PST) X-Gm-Message-State: AOAM531gbDSKA9Ye9KO+ZP6mod+pdO7HkS3yz/7VvwR33D/8YIiXiOHh wdOH7AgsKIBbOph3dUlYOyQ2l1Z4xOYNYbAgTVA= X-Google-Smtp-Source: ABdhPJy+sCJisvcqc004QkFyRiHpYJFr+ExQOffMyO3CNLI9sMiM9JhpV7VLeTt4wPEZ2Wa4UwdsXjGAF7oyGrkMt9Q= X-Received: by 2002:a05:6830:1514:: with SMTP id k20mr43746692otp.147.1638195082500; Mon, 29 Nov 2021 06:11:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Mon, 29 Nov 2021 15:11:11 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: KASAN Arm: global-out-of-bounds in load_module To: Andrey Konovalov Cc: Miguel Ojeda , Linux ARM , kasan-dev , linux-kernel , Linus Walleij , Florian Fainelli , Ahmad Fatoum , Dmitry Vyukov X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211129_061125_022427_033D31D6 X-CRM114-Status: GOOD ( 26.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On Mon, 29 Nov 2021 at 13:56, Andrey Konovalov wrote: > > On Mon, Nov 29, 2021 at 7:37 AM 'Dmitry Vyukov' via kasan-dev > wrote: > > > > On Sun, 28 Nov 2021 at 01:43, Miguel Ojeda > > wrote: > > > > > > Hi KASAN / Arm folks, > > > > > > I noticed in our CI that inserting and removing a module, and then > > > inserting it again, e.g.: > > > > > > insmod bcm2835_thermal.ko > > > rmmod bcm2835_thermal.ko > > > insmod bcm2835_thermal.ko > > > > > > deterministically triggers the report below in v5.16-rc2. I also tried > > > it on v5.12 to see if it was a recent thing, but same story. > > > > > > I could find this other report from May, which may be related: > > > https://lore.kernel.org/lkml/20210510202653.gjvqsxacw3hcxfvr@pengutronix.de/ > > > > > > Cheers, > > > Miguel > > > > HI Miguel, > > > > 0xf9 is redzone for global variables: > > #define KASAN_GLOBAL_REDZONE 0xF9 /* redzone for global variable */ > > > > I would assume this is caused by not clearing shadow of unloaded > > modules, so that the next module loaded hits these leftover redzones. > > Hi Miguel, > > Adding to what Dmitry mentioned: > > The code that's responsible for allocating&clearing/freeing shadow for > modules is at the very end of mm/kasan/shadow.c. It's only required > when CONFIG_KASAN_VMALLOC is not supported/enabled. > > As 32-bit arm doesn't select HAVE_ARCH_KASAN_VMALLOC, perhaps it needs > something along the lines of what kasan_module_alloc() does with > regards to clearing shadow? I assume arm doesn't call that function > directly due to a different shadow allocation scheme. > Side note: vmap'ed stacks support is being added to ARM, so it would be worth it to investigate whether we can support HAVE_ARCH_KASAN_VMALLOC on ARM as well, otherwise we cannot enable vmap'ed stacks and KASAN at the same time. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2B61C433F5 for ; Mon, 29 Nov 2021 16:09:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344060AbhK2QMt (ORCPT ); Mon, 29 Nov 2021 11:12:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344117AbhK2QKr (ORCPT ); Mon, 29 Nov 2021 11:10:47 -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 B0B6DC08EA74 for ; Mon, 29 Nov 2021 06:11:25 -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 77A89B8111B for ; Mon, 29 Nov 2021 14:11:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 411B6C53FCE for ; Mon, 29 Nov 2021 14:11:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638195083; bh=x7gANHXCj9D2jHArSELv0y5uHzyFEQHNRCPsvkTF7Ig=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iNUsntFyxDfkFs/HGTqojPv+3tLdNcEC6oBQRPlXoTB0CVQRJHniOMQeocKDGbXez z9Kohzcm3ftOZyq3oRq0RZyVqSrwR1v3ou7PwWIayS/KGeuLASLNyz4LyVWhHV6fZ3 SDhocSeSec8g+jR3FuQb+zPyG0HKsoWvxg6IZ0bDU+8HPjKfOSpK3666oQazAX5+rf caj7GS2Q3UTzyy1DhQmh25AOzdaoF+qC6wQoTjf/s7aMyUolupsQ3V8SYsHh7xsDS0 Q95zfpdOIv6fyH6fBt2lR70PKnjGdWJjK13izpyWbWcxyP6qpr63haYXwnRGWH0lMB q6jmDDVZ14xGQ== Received: by mail-ot1-f54.google.com with SMTP id 98-20020a9d086b000000b0057a403bbd4eso1037954oty.13 for ; Mon, 29 Nov 2021 06:11:23 -0800 (PST) X-Gm-Message-State: AOAM5307u4E/zXQ3+OawqU86QU49eiTaMmBhMx00GtNyBMQmR5un3ijv G7QqDiKR1XqSbixnrCe7jclzAnbf/YQgpSnIyJM= X-Google-Smtp-Source: ABdhPJy+sCJisvcqc004QkFyRiHpYJFr+ExQOffMyO3CNLI9sMiM9JhpV7VLeTt4wPEZ2Wa4UwdsXjGAF7oyGrkMt9Q= X-Received: by 2002:a05:6830:1514:: with SMTP id k20mr43746692otp.147.1638195082500; Mon, 29 Nov 2021 06:11:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Mon, 29 Nov 2021 15:11:11 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: KASAN Arm: global-out-of-bounds in load_module To: Andrey Konovalov Cc: Miguel Ojeda , Linux ARM , kasan-dev , linux-kernel , Linus Walleij , Florian Fainelli , Ahmad Fatoum , Dmitry Vyukov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Nov 2021 at 13:56, Andrey Konovalov wrote: > > On Mon, Nov 29, 2021 at 7:37 AM 'Dmitry Vyukov' via kasan-dev > wrote: > > > > On Sun, 28 Nov 2021 at 01:43, Miguel Ojeda > > wrote: > > > > > > Hi KASAN / Arm folks, > > > > > > I noticed in our CI that inserting and removing a module, and then > > > inserting it again, e.g.: > > > > > > insmod bcm2835_thermal.ko > > > rmmod bcm2835_thermal.ko > > > insmod bcm2835_thermal.ko > > > > > > deterministically triggers the report below in v5.16-rc2. I also tried > > > it on v5.12 to see if it was a recent thing, but same story. > > > > > > I could find this other report from May, which may be related: > > > https://lore.kernel.org/lkml/20210510202653.gjvqsxacw3hcxfvr@pengutronix.de/ > > > > > > Cheers, > > > Miguel > > > > HI Miguel, > > > > 0xf9 is redzone for global variables: > > #define KASAN_GLOBAL_REDZONE 0xF9 /* redzone for global variable */ > > > > I would assume this is caused by not clearing shadow of unloaded > > modules, so that the next module loaded hits these leftover redzones. > > Hi Miguel, > > Adding to what Dmitry mentioned: > > The code that's responsible for allocating&clearing/freeing shadow for > modules is at the very end of mm/kasan/shadow.c. It's only required > when CONFIG_KASAN_VMALLOC is not supported/enabled. > > As 32-bit arm doesn't select HAVE_ARCH_KASAN_VMALLOC, perhaps it needs > something along the lines of what kasan_module_alloc() does with > regards to clearing shadow? I assume arm doesn't call that function > directly due to a different shadow allocation scheme. > Side note: vmap'ed stacks support is being added to ARM, so it would be worth it to investigate whether we can support HAVE_ARCH_KASAN_VMALLOC on ARM as well, otherwise we cannot enable vmap'ed stacks and KASAN at the same time.