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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A0EBC38145 for ; Wed, 7 Sep 2022 07:17:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 009086B0072; Wed, 7 Sep 2022 03:17:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EFB196B0073; Wed, 7 Sep 2022 03:17:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D79878D0002; Wed, 7 Sep 2022 03:17:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C46276B0072 for ; Wed, 7 Sep 2022 03:17:38 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8DB5614102D for ; Wed, 7 Sep 2022 07:17:38 +0000 (UTC) X-FDA: 79884434196.08.4424084 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf04.hostedemail.com (Postfix) with ESMTP id 47ECA40079 for ; Wed, 7 Sep 2022 07:17:38 +0000 (UTC) Received: by mail-lj1-f173.google.com with SMTP id y18so144167ljh.12 for ; Wed, 07 Sep 2022 00:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=89+MkwCQRLAHkFEhXocRBmWuzdBCcd8GcaLlx6vSdK4=; b=mWUos+G4meLEIpM5B5tSJgqfGT5qpSbpn+rdZVeadkZnBWLelim7TPaMEtKqFnCb5x qaQW4+1W6y5PwSJsJP64h6SkRokfUsQdjuIXt2Bij29/dOMLg/gQeohNaCdr7nzHmfZV Fdk75ophPXB+Bwugz3NNgr4gm51+NMBslWWEShVW08npuscO1IaDvOHL55rQrp71rEK4 3hldg8EwPFDOB05fqVcITdL8Zrx0NKe7zHfQdX0kNTFlbfwfrdu4CYqCM68eMo/vqwcO jbzJJT5GRMI8YXbkiTJUHzQO/4gQU1XAXIRyGIq7HnR3D942NJCM+51TcEX/Mp1VNhF6 qH7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=89+MkwCQRLAHkFEhXocRBmWuzdBCcd8GcaLlx6vSdK4=; b=fA/uANqYXWDJq1gqas2VASuInRTMt4M0REG2Ivj/myXK9j8y69gvx9XVLTk18LOEun DQqEpLuw3CmCYJECfU350IeUF/AUO4c2saiWPZgVpzg6K1x15nBKIgIxzAvfy8aPjb5/ 2DUFQ+C4JnWMgIpl6JZ/2Nh3FaeSPnWNKFUydfIY64/QVRwKOJh2F5+WeHQhuy4lvGcU nZ9hi9mPY9nhx6Yw6CqCH+9+1qXlUU77aEDKNCP6Nf2UKMdIOUkcrD4Ub8nkB8DHDZ05 wAgso1X79ySFkNcyje22Ot3XY2l0kdTTZGur0yC6jPukHrSX4hroi5M64ivdaxzKUpR5 pxUQ== X-Gm-Message-State: ACgBeo3dZbe4UgltVy2P7LJG95TaHn2eE3Hg7hjsPIDT9LQN79n/h2Dd NSV53MZVR4Dmtr0K+dTtHhC5oObXQZ9Xb3gC/CThlw== X-Google-Smtp-Source: AA6agR71di9AUXjm1EUAWrxZPkPvbGJ5UTGC0woWSGfCPIomzzbd6bY/6fvZKlDkb7mw8EwP1pyMQz6gziNPl5xaI/o= X-Received: by 2002:a2e:a589:0:b0:261:b223:488b with SMTP id m9-20020a2ea589000000b00261b223488bmr592996ljp.33.1662535056337; Wed, 07 Sep 2022 00:17:36 -0700 (PDT) MIME-Version: 1.0 References: <000000000000974e2805e802137e@google.com> <20220906173154.6f2664c8fc6b83470c5dfea1@linux-foundation.org> <20220906225312.263c4493a744cbcb66288283@linux-foundation.org> In-Reply-To: <20220906225312.263c4493a744cbcb66288283@linux-foundation.org> From: Dmitry Vyukov Date: Wed, 7 Sep 2022 09:17:24 +0200 Message-ID: Subject: Re: [syzbot] linux-next boot error: KASAN: slab-out-of-bounds Read in _find_next_bit To: Andrew Morton Cc: Yury Norov , syzbot , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-next@vger.kernel.org, sfr@canb.auug.org.au, syzkaller-bugs@googlegroups.com, Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Vincenzo Frascino Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662535058; a=rsa-sha256; cv=none; b=RJkhrisUL+NpQg1/M2djxwNdKdfahFte6Q2/9c4EGXk88KU8PPpGbytRkDTSl5cY3Jelgn ZD6PP1AfzlAZlA6TyhZPqob+N4LJBHiSiSUptyMLKCbj88SFShi+PM3SDwMGNMN7lSu9Ov IqoQ+JZa0LVBqfw9kdPRu08tMP9yu9Y= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=mWUos+G4; spf=pass (imf04.hostedemail.com: domain of dvyukov@google.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662535058; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=89+MkwCQRLAHkFEhXocRBmWuzdBCcd8GcaLlx6vSdK4=; b=fVWOwFdoajPAie1QEIkMzgjFyTKPqNSqFZK7u2LqbDXZ7q132+PF6CkBGjeRB10ChPqkwn T6kR5m1NQ1Q2MbPOykjZnVdLy9wvPYS5jtelYSHKZSEe5CL6VnGIG9VlJq9eweRDAsK9Ba QMwT3eYGFcCvB/0ZMRBPzu1728iw7zg= X-Stat-Signature: rcn3bz3wzzxr1dubwaudt7i1ozomu9bi X-Rspamd-Queue-Id: 47ECA40079 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=mWUos+G4; spf=pass (imf04.hostedemail.com: domain of dvyukov@google.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1662535058-456463 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 7 Sept 2022 at 07:53, Andrew Morton wrote: > > > > The buggy address belongs to the object at ffff888017576600 > > > > which belongs to the cache kmalloc-192 of size 192 > > > > The buggy address is located 184 bytes inside of > > > > 192-byte region [ffff888017576600, ffff8880175766c0) > > > > > > At offset 184 of a 192-byte region. > > > > > > So what's wrong with doing that? Does KASAN have an off-by-one? > > > > Hi Andrew, all, > > > > This is a bug in FIND_NEXT_BIT(). It should be > > if (idx >= sz / BITS_PER_LONG) \ > > goto out; \ > > > > instead of > > if (idx > sz / BITS_PER_LONG) \ > > goto out; \ > > > > The fix is in bitmap-for-next, expected to be in -next by tomorrow. > > Sorry for the noise. > > OK... but why is KASAN reporting a bad access from an area > which appears to be OK? Hi Andrew, Good point. Filed https://bugzilla.kernel.org/show_bug.cgi?id=216457 for this. Copy-pasting description below: KASAN says: ================================================================== BUG: KASAN: slab-out-of-bounds in _find_next_bit+0x143/0x160 lib/find_bit.c:109 Read of size 8 at addr ffff8880175766b8 by task kworker/1:1/26 ... The buggy address belongs to the object at ffff888017576600 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 184 bytes inside of 192-byte region [ffff888017576600, ffff8880175766c0) ... Memory state around the buggy address: >ffff888017576680: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ^ ================================================================== This "address is located 184 bytes inside of 192-byte region" is confusing b/c it does not look like an out-of-bounds access. What happens here is that the allocation request was for 184 bytes, so the last 8 bytes in the 192-byte slab are poisoned. But KASAN does not store the requested size in the object header, so it just prints the full slab size everywhere. User-space ASAN does store 48-bit requested size in the header. But KASAN uses additional bytes in the header for: struct kasan_alloc_meta { depot_stack_handle_t aux_stack[2]; So we don't have space for requested size w/o increasing header size (currently should be 16 bytes). We could either try to infer requested size from the shadow (count poisoned bytes at the end); or improve wording of the message at least to make it clear that 192 is just full slab size. For context see: https://lore.kernel.org/all/20220906173154.6f2664c8fc6b83470c5dfea1@linux-foundation.org/