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 8025DC433EF for ; Mon, 11 Jul 2022 16:15:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 199EB94000E; Mon, 11 Jul 2022 12:15:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 14B208E0002; Mon, 11 Jul 2022 12:15:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 012A494000E; Mon, 11 Jul 2022 12:15:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E6A3F8E0002 for ; Mon, 11 Jul 2022 12:15:01 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A6D902044D for ; Mon, 11 Jul 2022 16:15:01 +0000 (UTC) X-FDA: 79675318002.26.EC72832 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf07.hostedemail.com (Postfix) with ESMTP id 2F2724003E for ; Mon, 11 Jul 2022 16:14:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657556100; x=1689092100; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=95nOb3V1KKqq1c3e8OArM4orPLvj7Ko/hX8oKXIFz4k=; b=GmMi165b2d3gg3HGXfMXJwhG4q9VdFUc7Ug5QJoSr60fiuMRZeuwPdn2 b6dC0G2XQBM5mBmR2eTjsdaUbozAk321djgWVGUdEuQDGgtcFmMuIK9LC aXkRH406JV2QkfI0vs9gWeTVS7vrl4/M78Cxr2lePd1aFImJUeBI0z84l HI5ziKTdM2gfo/GspOqhs5HsyBn81xhWHI7W8d9G2DkmTpH4mZxEGQnz/ Fftme9CAatRPOX1UYwRAWNrS8qBJvYN7eSG2quRxz4WGdLdIhlnv2tizg ze7E8R5wno2CsVaf+z8V4kJjHBwVj8A53ilhrUqdI1ahJ1RcpuoHXMsBk w==; X-IronPort-AV: E=McAfee;i="6400,9594,10405"; a="265112658" X-IronPort-AV: E=Sophos;i="5.92,263,1650956400"; d="scan'208";a="265112658" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jul 2022 09:14:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,263,1650956400"; d="scan'208";a="652517910" Received: from irvmail001.ir.intel.com ([10.43.11.63]) by fmsmga008.fm.intel.com with ESMTP; 11 Jul 2022 09:14:55 -0700 Received: from newjersey.igk.intel.com (newjersey.igk.intel.com [10.102.20.203]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id 26BGErbR005796; Mon, 11 Jul 2022 17:14:54 +0100 From: Alexander Lobakin To: Andy Shevchenko Cc: Alexander Lobakin , kernel test robot , Yury Norov , Mark Rutland , LKML , Linux Memory Management List , linux-alpha@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-arch@vger.kernel.org, lkp@lists.01.org, lkp@intel.com Subject: Re: [bitops] 0e862838f2: BUG:KASAN:wild-memory-access_in_dmar_parse_one_rhsa Date: Mon, 11 Jul 2022 18:13:41 +0200 Message-Id: <20220711161341.21605-1-alexandr.lobakin@intel.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657556101; a=rsa-sha256; cv=none; b=qmC2m2zqWst2ouLwvT2qET9kVqSSDC/KzWswP/4YA7DYXVQ2ScYNM2ewfx34Z96yCnd4vC EdFTuynXrfE9498oe+MAzABJBjKRSi3N64PNbrB57Cp1Z7SZ90wODk6UIYeaKJ/O+ibHEc XpnHGOAJsSe1+rxGqewpypniTfnBDUM= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=GmMi165b; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf07.hostedemail.com: domain of alexandr.lobakin@intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=alexandr.lobakin@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657556101; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qE5Hfv5VCwLSYsk0/A6ehAj58zxnaUA1xN7mzAEjQ1M=; b=LiPs9QBdepKonks5PTGCaj+scni6a2E3aIqkot/ZTtf2+LKXAy0EeILVdxWcNt+MlatS53 dOGl1u21X+F2vqNfL/0uzWhGse9epV+FYFzFAGC5EkOa16ND+C/PXMjLKBUKgc5KqEgSRE GPlIQ80/ZflgqRlOVpcu7LFqp13/6DU= X-Stat-Signature: fpfkgh3h4r36age4btcrfnmxw669g6uk Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=GmMi165b; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf07.hostedemail.com: domain of alexandr.lobakin@intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=alexandr.lobakin@intel.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2F2724003E X-Rspam-User: X-HE-Tag: 1657556099-871734 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: From: Andy Shevchenko Date: Fri, 8 Jul 2022 15:17:40 +0300 > On Thu, Jul 07, 2022 at 10:10:20PM +0800, kernel test robot wrote: > > > > (please be noted we reported > > "[bitops] 001bea109d: BUG:KASAN:wild-memory-access_in_dmar_parse_one_rhsa" > > on > > https://lore.kernel.org/all/YrnGLtDXAveqXGok@xsang-OptiPlex-9020/ > > now we noticed this commit has already been merged into linux-next/master, > > and the issue is still existing. report again FYI) > > > > Greeting, > > > > FYI, we noticed the following commit (built with gcc-11): > > > > commit: 0e862838f290147ea9c16db852d8d494b552d38d ("bitops: unify non-atomic bitops prototypes across architectures") > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master > > > > in testcase: xfstests > > version: xfstests-x86_64-c1144bf-1_20220627 > > with following parameters: > > > > disk: 2pmem > > fs: ext4 > > test: ext4-dax > > ucode: 0x700001c > > > > test-description: xfstests is a regression test suite for xfs and other files ystems. > > test-url: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git > > > > > > on test machine: 16 threads 1 sockets Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz with 48G memory > > > > caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace): > > > > > > > > If you fix the issue, kindly add following tag > > Reported-by: kernel test robot > > > > > > [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) > > [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0 > > [ 4.683454][ T0] > > [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1 > > [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016 > > [ 4.703196][ T0] Call Trace: > > [ 4.706334][ T0] > > [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) > > [ 4.714272][ T0] dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) > > [ 4.718632][ T0] kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493) > > [ 4.722903][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) > > [ 4.728042][ T0] kasan_check_range (mm/kasan/generic.c:190) > > [ 4.732750][ T0] dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) > > [ 4.737715][ T0] dmar_walk_remapping_entries (drivers/iommu/intel/dmar.c:609) > > [ 4.743375][ T0] parse_dmar_table (drivers/iommu/intel/dmar.c:671) > > [ 4.748079][ T0] ? dmar_table_detect (drivers/iommu/intel/dmar.c:633) > > [ 4.752872][ T0] ? dmar_free_dev_scope (drivers/iommu/intel/dmar.c:408) > > [ 4.758010][ T0] ? init_dmars (drivers/iommu/intel/iommu.c:3359) > > [ 4.762370][ T0] ? iommu_resume (drivers/iommu/intel/iommu.c:3419) > > [ 4.766903][ T0] ? dmar_walk_dsm_resource+0x300/0x300 > > [ 4.772909][ T0] ? dmar_acpi_insert_dev_scope (drivers/iommu/intel/dmar.c:466) > > [ 4.778655][ T0] ? dmar_check_one_atsr (drivers/iommu/intel/iommu.c:3521) > > [ 4.783795][ T0] dmar_table_init (drivers/iommu/intel/dmar.c:846) > > [ 4.788239][ T0] intel_prepare_irq_remapping (drivers/iommu/intel/irq_remapping.c:742) > > [ 4.793811][ T0] irq_remapping_prepare (drivers/iommu/irq_remapping.c:102) > > [ 4.798778][ T0] enable_IR_x2apic (arch/x86/kernel/apic/apic.c:1928) > > [ 4.803395][ T0] default_setup_apic_routing (arch/x86/kernel/apic/probe_64.c:25 (discriminator 1)) > > [ 4.808883][ T0] apic_intr_mode_init (arch/x86/kernel/apic/apic.c:1446) > > [ 4.813761][ T0] x86_late_time_init (arch/x86/kernel/time.c:101) > > [ 4.818467][ T0] start_kernel (init/main.c:1101) > > [ 4.822827][ T0] secondary_startup_64_no_verify (arch/x86/kernel/head_64.S:358) > > Seems like related to nodemask APIs. It points to arch_test_bit() (node_online() -> test_bit()), converted from a macro to a function, more precisely, to variable_test_bit(), which I didn't touch. ...oh ok I got it! pxm_to_node() can return %NUMA_NO_NODE which equals to -1. The mentioned commit converts the macro to the function which now takes `unsigned long` as @nr (bit number). So I guess it gets converted to %ULONG_MAX - 1. Now the question is: what should a bitop do if we have negative bit number? Because there are 2 solutions: 1. (I prefer it) A caller must check that bitop arguments are valid. UB for negative (== too big) bit numbers. dmar_parse_one_rhsa() must be fixed so that it will check return value of pxm_to_node(): int node = pxm_to_node(rhsa->proximity_domain); - if (!node_online(node)) + if (node != NUMA_NO_NODE && !node_online(node)) node = NUMA_NO_NODE; 2. My code is broken, I shouldn't change `long` to `unsigned long` or should change it for {constant,variable}_test_bit() as well or do something else and let it behave as it was previously (it wasn't crashing probably due to a good luck or...). > > -- > With Best Regards, > Andy Shevchenko Thanks, Olek