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 21B2FC3DA4A for ; Fri, 2 Aug 2024 11:06:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A3B36B007B; Fri, 2 Aug 2024 07:06:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 952AF6B0083; Fri, 2 Aug 2024 07:06:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81AA56B0085; Fri, 2 Aug 2024 07:06:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 623C46B007B for ; Fri, 2 Aug 2024 07:06:39 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 05B14C0F51 for ; Fri, 2 Aug 2024 11:06:39 +0000 (UTC) X-FDA: 82407027318.16.1E31967 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf09.hostedemail.com (Postfix) with ESMTP id 2038914003A for ; Fri, 2 Aug 2024 11:06:36 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Q825vhm6; spf=pass (imf09.hostedemail.com: domain of jannh@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jannh@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=1722596768; 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=KRR6BpufkDTMSbKYLs5P5x4tc4mghVB2+YjYQfPNLdg=; b=3ed+idxOmIlV/I2f722hzIwDWZ1ysnlfC/oMc2/FlWwMB1CcjhYTEynj6Q4yONY5ihCpIv dq93fWDSKMcqflJ2bw23lKDAnc2WybaUWhF/EZzYzUIyiFgIrlqp4G7szmAvyJZFN4Ey1J +vaSNKO6gMsWCMs+I9ztnIowLD4U7jU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Q825vhm6; spf=pass (imf09.hostedemail.com: domain of jannh@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722596768; a=rsa-sha256; cv=none; b=G1GidFhC+nUm9ZZFwYaOC0pW8IerwrVcnXOXFCHEc2Z3xt7SvrI1PRzds4yksO8vdNCaIe gntFzGEZSto4ZXhSYXtAtcFnlzx+ENhs8tESO1wtErYyfSJgJjAnH6vxhyjGR4gJ3CGCN2 rdmqdQCyzxjSa5cnrVoyfptdHjP/PHM= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5a869e3e9dfso50793a12.0 for ; Fri, 02 Aug 2024 04:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722596795; x=1723201595; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KRR6BpufkDTMSbKYLs5P5x4tc4mghVB2+YjYQfPNLdg=; b=Q825vhm6q7MBax02t/IZb6RZRtayUxfPXIfXZBI1cKN3FEGdTFMFr8XKOUu4FTwOo6 XmLb9OyXCpYBZUrX1MK0EDD+xYk8qyxitHpJm4R1b3X1k5oAoAVEPQUNrNTFyVdcYdh6 /wOVdiYp9Mvb/kKd+rm5LvkJ43fsRJZrkuhW1nBVgNYn/mvyNZ5+rSRxYL3aKoKWTJ2P cKhzHuyLLnVkJ2lZxt2wapT7bNOcZJneqWVDakBA3GtcGwaGuD0stToXqw0sInki01F9 3bCbAf2E9vhP59Xtk1ancIMVZhlCpAHJlDqmk5CFKMIf5Llxs3WvlQpHxOQWZxra/0CP RrdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722596795; x=1723201595; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KRR6BpufkDTMSbKYLs5P5x4tc4mghVB2+YjYQfPNLdg=; b=mtOpLQ+vY4KzAQ5qymTpg5/8XZ7UHQGCPz4Z6i5J6w4SdkLlO6vflyJN2G5sl4rtIe 9wf5Z+PE3oXNplu6M1qRPmjU4MWLIgcgBJZ0dHF4OLDrv8j1yMISwqADPUAiDi47SOPI CL20r7Pr31hk90lEsLLLC0XljR4EmNvErTc69dTotHzij9Okj/YoUGA7ua8VNEuhN14b z9zrTs/AH36XhkeSyolFDYBXVBjsdVOzB8oudEwXBTckuyR1kqUTplDE4Hd/Czm/KhDs k9UX7zwyKo2UK6hG32Zi1HoAPU7oUua/C9Tm3+BUDJnwY31QO0lZE8KldF9/jbzwPcUo r/pw== X-Forwarded-Encrypted: i=1; AJvYcCVCdDcIyYHcxpFzQViND+l2KfCQy74LXKWRahQ8QEjr6hi8p8iuJ8tGk0K/VlmGlncwCRcvDWnGWkt/HdYcsfYIjKM= X-Gm-Message-State: AOJu0YxKSYscG70kOjonArhlGLvMsMS6wW+P8Y6qDQA0Kqtz8YUYZcY2 sH8eSsX/C2Hs6ch/1qG1WeTmeNuGN+ZWly9x8mdEBLvJU8l8pGV4j7bMBqouXmOe9LzMMQbSUcr 4D23CCi9dFL2toiZog5muvZXXVQE2TpOC2d1R X-Google-Smtp-Source: AGHT+IGWFqch3T7ul+u9DuiIi+aNMgGuXM7yxoPAhtJNXlh8CEGVVKTP3eKfrIKv3A6mn7sHx0ibWwdH19lgz2vXcKE= X-Received: by 2002:a05:6402:5206:b0:58b:90c6:c59e with SMTP id 4fb4d7f45d1cf-5b8713605e3mr112092a12.7.1722596794707; Fri, 02 Aug 2024 04:06:34 -0700 (PDT) MIME-Version: 1.0 References: <20240730-kasan-tsbrcu-v5-0-48d3cbdfccc5@google.com> <20240730-kasan-tsbrcu-v5-1-48d3cbdfccc5@google.com> In-Reply-To: From: Jann Horn Date: Fri, 2 Aug 2024 13:05:58 +0200 Message-ID: Subject: Re: [PATCH v5 1/2] kasan: catch invalid free before SLUB reinitializes the object To: Andrey Konovalov Cc: Marco Elver , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 2038914003A X-Stat-Signature: ujngg9apr7mkejx5q8ywq9bo17u1ze98 X-HE-Tag: 1722596796-771342 X-HE-Meta: U2FsdGVkX184+TeawGiUEQprn9cubr4gY/3dRS35LlnuJbTXDqjrtJMVSXaJQhTTC+gHYfJwcnLwt6bt4GANe8iQwUS6aJAWSKjtdgnZUe/YgsLt1p0fWHzCjJ9SEzdbHmu+Z4eMIgYzba59DgZMmMrRJ3FPRqnyEL45eBpFHbvAsdGdDBwYp3f9LPSTdwyItk7D/Ut6ItgWDAkHCKGi3wGm2UIvDks8Ieiico4m85MqWmUQw2q4RV1rLKkiy2RDlEWLrGT3fXv15xx7kuBFMr+neGmVbOjs3OE3O50+ZjV2FxLFJl644PRk7hk8qpdoB3luWyZwdgtkmdo1iE25fJv1Ih3fO6wH5rjprNHsgePsQD+JSJfOxv1uOqX9Als8sPbWnLJeynl3FpcCLwzGYqMWCNf6exmoxKgoGrkwmTaPK8YoC9BpMXupawJCEfNWHiX4DpHlSEOva+O60zohJOFa/e7IvcPKN+huoD0FpZDRsH5+3ZY1zTulfKhYyusRbF50S1iu/T90fiGgPYVQ4C0XnX2rxxx3fTfMyV3USRh7DUGXlqKWukBfp2e8uBpOwrTcK49zwDocgFuTK92+ohVzPG4nUDPPiQ8u2jS9p+Rh4VJH/CAhqhy2+7MR93UwZGC99giFnDFqsbZ1bUrL2LG+0bs+ohkBq4qDLqnVzMuEFI97V3mBi8bwyhAqLwquK4m2cah67znqH+lXfnC7MoQUyjlC5qWsI1Aqe41wCzxp8KDYFnaOXo7+zGwPG9e1t8HmHO17KDpCSan/4VVd3zCG21boHe7obClyFXUFAMwADqikmzy4fm3388onZiPlHpXTZ1Dg1iue4vRkGz/aj3jCKLugYj56qGvl0LjIVsAcWONVS54bBrwT2HYiDwSpDuVHh/WzCC5g976JjnT44fIiQSRvAeDTHzqT8Uht0Ul0tm1hZwXQzjzcybYq8HtiN50k38P6FILx8RyUh6g 7CPLRbkP TqSc7z59c5GshPhyeKHcyzkupjcGIUywLtxMX/HIFoCvQ+Wp9DKBDpQR/pzT1Xsfb6Pjeij8JbaRhrfBro49n88NkSO857yAZf8eHPSebL8YrsVumpyhLYpA6Ua3IYEhuHyTbv/ciz/21NSjQhFDGWnJNOHuwRlFrbVDQS4kFQ0oKIv1jgjlIpqsCAXMm9ChhNvZw5b8mVO3ruuHMYHTvvgYFexSPQOV3mYIaMIaVqmb+pEHO5jJfv/pyHl8GdBufKR2rBeKepj09PmyjeDBeD3JKmTflymIhZNi6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000239, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Aug 1, 2024 at 2:54=E2=80=AFPM Andrey Konovalov wrote: > On Thu, Aug 1, 2024 at 6:01=E2=80=AFAM Jann Horn wrote= : > > > > > > @@ -503,15 +509,22 @@ bool __kasan_mempool_poison_object(void *ptr,= unsigned long ip) > > > > kasan_poison(ptr, folio_size(folio), KASAN_PAGE_FRE= E, false); > > > > return true; > > > > } > > > > > > > > if (is_kfence_address(ptr)) > > > > return false; > > > > + if (!kasan_arch_is_ready()) > > > > + return true; > > > > > > Hm, I think we had a bug here: the function should return true in bot= h > > > cases. This seems reasonable: if KASAN is not checking the object, th= e > > > caller can do whatever they want with it. > > > > But if the object is a kfence allocation, we maybe do want the caller > > to free it quickly so that kfence can catch potential UAF access? So > > "return false" in that case seems appropriate. > > Return false would mean: allocation is buggy, do not use it and do not > free it (note that the return value meaning here is inverse compared > to the newly added check_slab_allocation()). And this doesn't seem > like something we want for KFENCE-managed objects. But regardless of > the return value here, the callers tend not to free these allocations > to the slab allocator, that's the point of mempools. So KFENCE won't > catch a UAF either way. Oooh, right, I misunderstood the semantics of the function. I'll change it in v6.