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 E9731D68BDA for ; Fri, 15 Nov 2024 21:49:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D4336B00AE; Fri, 15 Nov 2024 16:49:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2827E6B00B0; Fri, 15 Nov 2024 16:49:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FCD46B00BF; Fri, 15 Nov 2024 16:49:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E423F6B00AE for ; Fri, 15 Nov 2024 16:49:45 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 983801C634B for ; Fri, 15 Nov 2024 21:49:45 +0000 (UTC) X-FDA: 82789670544.23.49198E5 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf18.hostedemail.com (Postfix) with ESMTP id 577C41C0010 for ; Fri, 15 Nov 2024 21:49:23 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2T1Z2cdb; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of yosryahmed@google.com designates 209.85.222.180 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731707204; 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=2MFOl+reVvqG3gSOiuAKMho/Jj4WzWL6vuFCI/y9WDM=; b=aGO50kk/M7RTK9rg8Laidn2UpwtMTkCg+9d8soL9+8o7HiHfNtXCtMXI6HutT1SG47Z/ye iVJUolbUcyf0jHuirmUKAXZRAr/T9FNMnJCVSJHZGFm9EKP3p6aPvvTRifQUVlnu0S8ZZ6 L8WU0M9xU7sQiUfDAcJr63lC4WLhU/I= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2T1Z2cdb; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of yosryahmed@google.com designates 209.85.222.180 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731707204; a=rsa-sha256; cv=none; b=eZPqos9zi4UqroWpOns+AQojG6JAtSzkYRvsWPNrMDMlK3DMP21sicsoKfNyGeEepWJivK 4rBNBJPQkIg+5AKLGAh8C7CrxDTfFawMyyLCuXynJFb4MZMlv5BwvdOzR2erO22HTpLt3N 0RANamjhTAwIDizDbBYE5B1NSLW1qeY= Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-7b1539faa0bso84556185a.1 for ; Fri, 15 Nov 2024 13:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731707383; x=1732312183; 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=2MFOl+reVvqG3gSOiuAKMho/Jj4WzWL6vuFCI/y9WDM=; b=2T1Z2cdbKqbA47ZmtoAFB5ixEBvJ9OfrEJfAe+t47rvKBANgCg9q9RxaA5qqwbraWQ 8lAT5pOR+w8aIuz0EVFjq1/cLJpOOxiAfGMhdEY1XFtRM3CzbkYJ+FLKgLPM+W3gVcpe BFERrS/xQCy9ntmxtBvJffG8REnRzfsEZ258A8fUhAYRwXLDDdFKAJqRgAXSCE5hKaZv fx1gqy1CMzwPqsbDBHFAxnm0VHl0aMjCekSY8S7PJ4WhJs94yS62UK7JbJ6h11kmsRoz vcifCWDIhU4zQL/45WcDYs4Xrp0WeR5K/fxhE6a4n7ESKpzIdAZMxBnF7qHac2OZyn0p D8ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731707383; x=1732312183; 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=2MFOl+reVvqG3gSOiuAKMho/Jj4WzWL6vuFCI/y9WDM=; b=N4omhDykfhGnJq7/EcouazIwEPZcGCfVhG0jXPiyiiRPl8gZ72uhoJ+VUrYZOCqPHF C5gfvtHRiaWWjPvIHU3csA5MGPAhsa5MFtaQd+kzjEb5Uoz0rM0IU98GEOI+JF9qfXfn eNjSLK8+L4dUyZbSof+ip6xYKO99z1KslzjFWpAyJYSitDwW0zyM/p/0P+1gogirU6u3 +fcypuy22qrERZbTDU7bzdnU+lOhT7XENPi6GxAtwFIj/8p5kk64u/GisyQ2Y54mWiTr BEbXfjYDYKqdzS1ee3/c8GsRgSicu2ijpNKUHOzyxg3TjC1X+RO6vKbJNMuw2b4NQfLK M7QQ== X-Forwarded-Encrypted: i=1; AJvYcCVMASAQe72opO0D/JTej0ujYZX2taLm/FTzbLZfd8Celk4HlojTAHNoFJZX7fNUcufKn0mzqbBQ4g==@kvack.org X-Gm-Message-State: AOJu0YzxSCRGaijqiz0DsRouEFUf+IUq5ZfaPLcJmdGDAc7MZeBJuhKu kluYBEsVGsGgTX9lEwntw9Ajz7tky5SYeqt5m5Xy/5VcaF4GzEQABbt9lR/ZOG0mBvlElNB9ipG Ffvn52zSiDktPXcIpP5dXmT7kkPLK2I53cT/P X-Google-Smtp-Source: AGHT+IEF6dmuT2PB7Z4+bp45BUPpk4Wd27INZddF9AtMW8EKIomFP19UzsYV0c6l3/HQXUfT11/K2tov5YMXcQrAJbo= X-Received: by 2002:a05:6214:2c06:b0:6d3:fa98:cf4a with SMTP id 6a1803df08f44-6d3fb885af6mr48930636d6.34.1731707382452; Fri, 15 Nov 2024 13:49:42 -0800 (PST) MIME-Version: 1.0 References: <20241113052413.157039-1-kanchana.p.sridhar@intel.com> <20241113213007.GB1564047@cmpxchg.org> <20241114051149.GC1564047@cmpxchg.org> <9a807484-6693-4e2a-a087-97bbc5ee4ed9@linux.dev> In-Reply-To: From: Yosry Ahmed Date: Fri, 15 Nov 2024 13:49:05 -0800 Message-ID: Subject: Re: [PATCH v1] mm: zswap: Fix a potential memory leak in zswap_decompress(). To: "Sridhar, Kanchana P" Cc: Chengming Zhou , Johannes Weiner , Nhat Pham , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "Huang, Ying" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "akpm@linux-foundation.org" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 577C41C0010 X-Stat-Signature: hudj1mxxfaqjiard78e3fk6cfdqbeu3e X-Rspam-User: X-HE-Tag: 1731707363-680821 X-HE-Meta: U2FsdGVkX18h1Bn2jog12iL2JpGTsWBUkWL8jRB0XSMPkym0EaEY+i4DyiuVKheS074kFIjNnhwRaAzZH2F2CZ0P1ir4j/lrAdIRYeB6OEm5A2HMumLBBUuxRzVo7ENFArDZrtIxCmYs3hqPir0ZPPkP0x6qlFqrf6VUY95A96CXGLE3ludwPmDyvTsOFqGO2zTkOvlbv5plz2Hn3R1xCF15kHsfK2uHYawe76MPjcTIgnXpJf2/EhTs4hZA6FPGHv7CKLnVHNNGU6qrcMHJQ1HrazIcl57vBUJOLSsV7HhUADCakz7VYD3ndvRUOHh/chGfEd4pzEJTBgkrLf2FGSDCrPGTtOWL32rx/+rqNzFXgu8NkZQPaYWSs4R5XuBUTj1hi+3f10jF/XjsgPk0Fm8vWordfAD3aqgBIvEjI1yCw7agK0y3lqaVFM2MS4moBfkMze6eLO8ZjR8sKfjIgyjVtsMVrk2sZjA++6euLSJrkuxhXA0IxpCpm4bntRseHQQslLN7wJgucmjAk0r6W6ys0Hu/raK5Ej6oJdWWTgPodW2S7WKKjtOU9TShq6j3AnLAXXRP/ApZr7MYElYlhdptAxpOnFwskNXit7+8Ie4hFKH60fyXfUTh+9Isy3GdM+B3aO0YrnelKpztkzYpLF1iC2/5si0hiLfaUbz+wGNQK9xboCpktj6gK9yuSSy8IG41sNZC+M7AvsbiNYmIGKXkydT5/yLsm557hjpZn3c97v9uxALstb3yc4XtE5wdBz0JY1S3n2k+/9Vo8gdMsTUT8WW8ea0Q+9NXvYec9Skuf2OXWkKWvhXrRxesssHJYaxsZ1rSh5hyiuqrO3QoehgL+kyCN4Ye+iqqnQzU8PLfSNPOqAo09GEX2qydWFRV4tncNSyJ+ZwEoqgH222ETyKdGMGiaMBnPnS24it0dFTyxlmm7j5ibpN4vPBkW2cZqSLYSkg9H93mU8/17/i S+nNcU+B lv/+8eD0JcqWDZb6iMzF1ntIJSgd75WSeANUcBjx1e65x++IoYmpXNIMD3ujwcuyFVv5hVqTEgz1Bd6hwseoNRSKitpPHy1D9g7oIHZcqo4mIcKgDSdNbAOVworkmtWZVXDit1Bth3jGH1qWXWlltCmH7pBmedMJmTrrxXomV0UFzFOYjjMhGFiV49hMFasiRVJlebAiXnZX6prKSucmLgBYrKYwP8pDqdebTNfdsQCET/cQSOsK6OLKJGMzzsTA7IPo+BvH7xLpyz1FQTFHGI6sipcuSARGFwqjo2rADSt0NDG446R9QmGroYMVW2HdhpuabIYug9iDw+PLhKS4zdLfRqLbb4Uv/+3vClEai94BxZB++xaSg0hA/BBFd/aujQAFxk1hp0KtMF/1O/ZJkrdZXRxzdYDhJtUuMfXVxGm54Ug4FVBJTq6e4An7MbnVT0jkkgA5EHc5VlbkCWK6Y+ILXAk79GGA6rnHRtwWzmOXjO4xAp76Vxfcw5ezQleeLGhWZjS0H2VqX+NlZTk4Q8wlCSf2QdIgeSbDnQ23k4LQFR/aX10hddiQjDAFspoaO1OX/J7cO8nkCeuKs8b1RTg1GHQgtSr2xf2S1z7udbPW2sRnS7IH0K8WxJZk7Wd9/KLxjJjtV+j3m99JU+jhu8etXjT7og4XLFW/AFWDrl8NtltA= 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: List-Subscribe: List-Unsubscribe: On Fri, Nov 15, 2024 at 1:14=E2=80=AFPM Sridhar, Kanchana P wrote: > > Hi Chengming, > > > -----Original Message----- > > From: Chengming Zhou > > Sent: Wednesday, November 13, 2024 11:24 PM > > To: Sridhar, Kanchana P ; Johannes Weiner > > > > Cc: Nhat Pham ; Yosry Ahmed > > ; linux-kernel@vger.kernel.org; linux- > > mm@kvack.org; usamaarif642@gmail.com; ryan.roberts@arm.com; Huang, > > Ying ; 21cnbao@gmail.com; akpm@linux- > > foundation.org; Feghali, Wajdi K ; Gopal, Vi= nodh > > > > Subject: Re: [PATCH v1] mm: zswap: Fix a potential memory leak in > > zswap_decompress(). > > > > Hello, > > > > On 2024/11/14 14:37, Sridhar, Kanchana P wrote: > > > > > >> -----Original Message----- > > >> From: Johannes Weiner > > >> Sent: Wednesday, November 13, 2024 9:12 PM > > >> To: Sridhar, Kanchana P > > >> Cc: Nhat Pham ; Yosry Ahmed > > >> ; linux-kernel@vger.kernel.org; linux- > > >> mm@kvack.org; chengming.zhou@linux.dev; usamaarif642@gmail.com; > > >> ryan.roberts@arm.com; Huang, Ying ; > > >> 21cnbao@gmail.com; akpm@linux-foundation.org; Feghali, Wajdi K > > >> ; Gopal, Vinodh > > >> Subject: Re: [PATCH v1] mm: zswap: Fix a potential memory leak in > > >> zswap_decompress(). > > >> > > >> On Thu, Nov 14, 2024 at 01:56:16AM +0000, Sridhar, Kanchana P wrote: > > >>> So my question was, can we prevent the migration to a different cpu > > >>> by relinquishing the mutex lock after this conditional > > >> > > >> Holding the mutex doesn't prevent preemption/migration. > > > > > > Sure, however, is this also applicable to holding the mutex of a per-= cpu > > > structure obtained via raw_cpu_ptr()? > > > > Yes, unless you use migration_disable() or cpus_read_lock() to protect > > this section. > > Ok. > > > > > > > > > Would holding the mutex prevent the acomp_ctx of the cpu prior to > > > the migration (in the UAF scenario you described) from being deleted? > > > > No, cpu offline can kick in anytime to free the acomp_ctx->buffer. > > > > > > > > If holding the per-cpu acomp_ctx's mutex isn't sufficient to prevent = the > > > UAF, I agree, we might need a way to prevent the acomp_ctx from being > > > deleted, e.g. with refcounts as you've suggested, or to not use the > > > > Right, refcount solution from Johannes is very good IMHO. > > > > > acomp_ctx at all for the check, instead use a boolean. > > > > But this is not enough to just avoid using acomp_ctx for the check, > > the usage of acomp_ctx inside the mutex is also UAF, since cpu offline > > can kick in anytime to free the acomp_ctx->buffer. > > I see. How would the refcounts work? Would this add latency to zswap > ops? In low memory situations, could the cpu offlining code over-ride > the refcounts? I think what Johannes meant is that the zswap compress/decompress paths grab a ref on the acomp_ctx before using it, and the CPU offlining code only drops the initial ref, and does not free the buffer directly. The buffer is only freed when the ref drops to zero. I am not familiar with CPU hotplug, would it be simpler if we have a wrapper like get_acomp_ctx() that disables migration or calls cpus_read_lock() before grabbing the per-CPU acomp_ctx? A similar wrapper, put_acompt_ctx() will be used after we are done using the acomp_ctx. > > Based on Johannes' earlier comments, I don't think it makes sense for > me to submit a v2. > > Thanks, > Kanchana > > > > > Thanks.