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 5F186C36010 for ; Fri, 11 Apr 2025 16:59:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 976F32800DF; Fri, 11 Apr 2025 12:59:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 924CA2800C0; Fri, 11 Apr 2025 12:59:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77A452800DF; Fri, 11 Apr 2025 12:59:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 567C52800C0 for ; Fri, 11 Apr 2025 12:59:22 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 347E3B8E2F for ; Fri, 11 Apr 2025 16:59:23 +0000 (UTC) X-FDA: 83322373806.04.0708D48 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf26.hostedemail.com (Postfix) with ESMTP id 70FDC14000D for ; Fri, 11 Apr 2025 16:59:21 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2oxh2e1m; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744390761; a=rsa-sha256; cv=none; b=i2ET4nnRXPmjIvin+iPJnEWG1wctEXBTCUezvrGhp3l00449SGzNUXvp32iitRFyBBr5Gc XO1XZmVe8bNXNIbtLzup93Q18A1TQeMsZ8rt8U7FUdmyAR8/R5Jo1yCYVCudNvXcz1ar9E dgXmUT/SScN0JfchTDR8zbXKbZxDmFw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=2oxh2e1m; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744390761; 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=7JcWT8F950TD+QqQ0UqNeDHA12hwY89YTBPGXVQrv5I=; b=CAUINlZFsaxYjUcdxbuJB+dz+i/M5RgEXeaHtGhetwNuSNk//A+/sc9r0FeRAWjPqPJYel Imu5sU/I9TL2Dwj0sYfkBtsI9+iCKZELdLXCwMFJXtvjR89YMcOcfl+9L7hM3qkSJVdV9u SHqRhl1HSAhw5/9OXmuUXBTewR7GEL8= Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4769e30af66so7641cf.1 for ; Fri, 11 Apr 2025 09:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1744390760; x=1744995560; 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=7JcWT8F950TD+QqQ0UqNeDHA12hwY89YTBPGXVQrv5I=; b=2oxh2e1miecPWHZ/cJVzPEBxYzATQUdyoocLHYpB1q6pm9YZgYkJFv9ukxUVflF9Fl N9axRAfHsgyzavjcQym4QztxHxHoL7ZCNM+0Tmck7v+3kRch9OI58IlCLMG5q25xpAcm anTd0/3IpKkGfyCfFWSp5pvRIfsHzBYv0bpCvHcZ7zbeU508ouQmj1lSQFRldFMhbrWp xqAQqjK3m1UYf1OzdUAaOGpLaNJhJleh2mQhQ6Y1oockMXHCbcAIfR59m4fMHHK+H3Uz bbHbbZRbhX3VdwAPdLgGoCFsJKP6bjXT6ZnN48w1Mrp5FNpfMfFqBFLTcfyhcRNLFBc/ p0/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744390760; x=1744995560; 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=7JcWT8F950TD+QqQ0UqNeDHA12hwY89YTBPGXVQrv5I=; b=qoVqfGZIs12GmIKQ43QC721ZuvWAPQPUo2Apk235WX3pEcazg3/nnbB50aX2jkrKjk 52zrrgFmVam/ZLtW8/wNfn3ukAJsaB+LiYG1n/u1g8L8Toe0sYHvEibywNUcczWdmaqZ l43ofzrYVRd23JTmKpCK7pygfgOKR2bDMws9f+os4orXCDMerxOjRiYmj+iX9WdkkT0U Trt4mERklfU3sRLztKYAKAnYeuB1eXuZHfGVVX8zLIqVvv2t7ceLfaU4E4ApiArANYGb mhCa3vb7UYUlnnM9jjbiekdzTu6ANZDV96EPBOwSCvordR/DOoTp5Z92Evf+Tfu+DZ6A S2Sw== X-Forwarded-Encrypted: i=1; AJvYcCWo/fBZxc2mJ4jiaGkcefjye+ilm5I9wN5nuOd+PxBTjDhzgQ8WtzPp7s+lwaTxuR4kIBTRtsALdg==@kvack.org X-Gm-Message-State: AOJu0YwOclGxBEESHyFyl57QAI+l2UR7ap2B4Ag+/WOirbdhaoLgVS/a +feYWx45FsXg+SgRfFIxPqVZubJy+ZarPmffMFojUYqJzuGt0NdEEnLHzLHXnoQaGEJmvrAAd2g qaiRi047Hx8+UNS7+nTWC0esjWcWHoAcjkeCA X-Gm-Gg: ASbGncsg9RBaHX7pWGTEa1I+x5FgV4fyxz+B5gGYqwOiuz+OpNwCH2j+XgU7qUJ0azd VrutIgYVd4YUOQW6H+VpoO98gBnGIwaodhBqI6Wxqvs6eYKwkBiirBPJ1VyeXLCjvLhGQzovpH8 8iACghWGsKr+vrBpzrZexP X-Google-Smtp-Source: AGHT+IFNCkECOF/4RUVrmmZrtr5X6NNOxIvUa6cUDsx7jrRz0J7jFjLKNPLhhm6DC1O9UvkHzLKWiZ/u3eEUA7iSzBA= X-Received: by 2002:a05:622a:649:b0:472:915:a200 with SMTP id d75a77b69052e-479766a6b4cmr5960931cf.28.1744390760129; Fri, 11 Apr 2025 09:59:20 -0700 (PDT) MIME-Version: 1.0 References: <20250411155737.1360746-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 11 Apr 2025 09:59:08 -0700 X-Gm-Features: ATxdqUETX9K1wffK9PtEH3J3qFn8MD3LfPBIvEHH6O6tBTLAX7jyrRgfnIPMYHY Message-ID: Subject: Re: [PATCH 1/1] slab: ensure slab->obj_exts is clear in a newly allocated slab page To: Vlastimil Babka Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, roman.gushchin@linux.dev, cl@linux.com, rientjes@google.com, harry.yoo@oracle.com, souravpanda@google.com, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 70FDC14000D X-Stat-Signature: 4cnub6ob1su9qqtaxwkiynzryb317or3 X-HE-Tag: 1744390761-774455 X-HE-Meta: U2FsdGVkX1/f0blTaJOn0ePEGPzE9TK8pwvr9dNKi6w9TCZZ/Hkk/huVEYU13fgB6ZrhKEu9HeMLTE3/HxaUISBQTyqLAw1fglVwQvT3sjXbKVRTdsVKTrf3nODHmPEGnM9T8/QcU8E4sHTnvgEZ6zLkftQHdiALpUvf3kIrirzf6UaWY/W04yc+NEHmsYCL53ex7l96BmOytVYeO7jcTUFZFIFmkmp3Hpdhx6x+f59VqMgMjngY40ZA6W0Frhl5PlDqev34ZPWZfkIzhSdbsp7Yc/agYRm5lJHCQQ+aOEnVSp1T18oHcqN2Emg95jhcPiZi5/zMwbCLzVQITTC3Cmq/qFbZRL/i5n3Nyu0DGJAP9n6masbd6SZhOX3cwLbLsWRIGn0z/3y7X5SS7apS15fcF2VbGWpttSGWjl9Y5USYn1qUbQrpoOWgGmRbaycPWKp4ATLu+SHaSbJ5syYn6SW8Tp7ztV/3slXOnQACFt7UMSWRQS7XuAIXyCIMzMp99NxJEDhaqCBoy7aG0W5YnCORBB+m3/hbLLAryz5rfRa5gTRXwDzAYPvHOxy6BsZWfFuSuhqoUhxNWLbv8o+tN2Iha6oAdAkVcV5+zQjFwyTjr1mMCXA/pfbyEkYTjHkqjHVS6IEqVrSRLVsR8Dh0t41t4OpM0YFz7JjlXgrW1Nc/wbZ7tPuP0YU3AiloT7TLVvUsGGDa7Kb/uLRBWUDKbK1yvkKdj8BDjOu1qX6+T3a2lbgOXv/h8lSuRXQ5dFBK/Gn/OLftRfC6GrWT77gomvOZFXq1Z2b7d1G0/BqTmj60MROcpo0fp1fnL8UIjonMAdKT77sinQELxjjOdfqww8EF+3B29LF7T9QpM0WYojxcvu/KXv+80oM4UMb2XaANaH1QXG66dwlhRWr8FES7unjJJDg+oXjYWp05XcngJehUl9W2clqJC+m5+xc5OySUl/IyDmenZwU= 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, Apr 11, 2025 at 9:27=E2=80=AFAM Vlastimil Babka wr= ote: > > On 4/11/25 17:57, Suren Baghdasaryan wrote: > > ktest recently reported crashes while running several buffered io tests > > with __alloc_tagging_slab_alloc_hook() at the top of the crash call sta= ck. > > The signature indicates an invalid address dereference with low bits of > > slab->obj_exts being set. The bits were outside of the range used by > > page_memcg_data_flags and objext_flags and hence were not masked out > > by slab_obj_exts() when obtaining the pointer stored in slab->obj_exts. > > The typical crash log looks like this: > > > > 00510 Unable to handle kernel NULL pointer dereference at virtual addre= ss 0000000000000010 > > 00510 Mem abort info: > > 00510 ESR =3D 0x0000000096000045 > > 00510 EC =3D 0x25: DABT (current EL), IL =3D 32 bits > > 00510 SET =3D 0, FnV =3D 0 > > 00510 EA =3D 0, S1PTW =3D 0 > > 00510 FSC =3D 0x05: level 1 translation fault > > 00510 Data abort info: > > 00510 ISV =3D 0, ISS =3D 0x00000045, ISS2 =3D 0x00000000 > > 00510 CM =3D 0, WnR =3D 1, TnD =3D 0, TagAccess =3D 0 > > 00510 GCS =3D 0, Overlay =3D 0, DirtyBit =3D 0, Xs =3D 0 > > 00510 user pgtable: 4k pages, 39-bit VAs, pgdp=3D0000000104175000 > > 00510 [0000000000000010] pgd=3D0000000000000000, p4d=3D0000000000000000= , pud=3D0000000000000000 > > 00510 Internal error: Oops: 0000000096000045 [#1] SMP > > 00510 Modules linked in: > > 00510 CPU: 10 UID: 0 PID: 7692 Comm: cat Not tainted 6.15.0-rc1-ktest-g= 189e17946605 #19327 NONE > > 00510 Hardware name: linux,dummy-virt (DT) > > 00510 pstate: 20001005 (nzCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=3D--) > > 00510 pc : __alloc_tagging_slab_alloc_hook+0xe0/0x190 > > 00510 lr : __kmalloc_noprof+0x150/0x310 > > 00510 sp : ffffff80c87df6c0 > > 00510 x29: ffffff80c87df6c0 x28: 000000000013d1ff x27: 000000000013d200 > > 00510 x26: ffffff80c87df9e0 x25: 0000000000000000 x24: 0000000000000001 > > 00510 x23: ffffffc08041953c x22: 000000000000004c x21: ffffff80c0002180 > > 00510 x20: fffffffec3120840 x19: ffffff80c4821000 x18: 0000000000000000 > > 00510 x17: fffffffec3d02f00 x16: fffffffec3d02e00 x15: fffffffec3d00700 > > 00510 x14: fffffffec3d00600 x13: 0000000000000200 x12: 0000000000000006 > > 00510 x11: ffffffc080bb86c0 x10: 0000000000000000 x9 : ffffffc080201e58 > > 00510 x8 : ffffff80c4821060 x7 : 0000000000000000 x6 : 0000000055555556 > > 00510 x5 : 0000000000000001 x4 : 0000000000000010 x3 : 0000000000000060 > > 00510 x2 : 0000000000000000 x1 : ffffffc080f50cf8 x0 : ffffff80d801d000 > > 00510 Call trace: > > 00510 __alloc_tagging_slab_alloc_hook+0xe0/0x190 (P) > > 00510 __kmalloc_noprof+0x150/0x310 > > 00510 __bch2_folio_create+0x5c/0xf8 > > 00510 bch2_folio_create+0x2c/0x40 > > 00510 bch2_readahead+0xc0/0x460 > > 00510 read_pages+0x7c/0x230 > > 00510 page_cache_ra_order+0x244/0x3a8 > > 00510 page_cache_async_ra+0x124/0x170 > > 00510 filemap_readahead.isra.0+0x58/0xa0 > > 00510 filemap_get_pages+0x454/0x7b0 > > 00510 filemap_read+0xdc/0x418 > > 00510 bch2_read_iter+0x100/0x1b0 > > 00510 vfs_read+0x214/0x300 > > 00510 ksys_read+0x6c/0x108 > > 00510 __arm64_sys_read+0x20/0x30 > > 00510 invoke_syscall.constprop.0+0x54/0xe8 > > 00510 do_el0_svc+0x44/0xc8 > > 00510 el0_svc+0x18/0x58 > > 00510 el0t_64_sync_handler+0x104/0x130 > > 00510 el0t_64_sync+0x154/0x158 > > 00510 Code: d5384100 f9401c01 b9401aa3 b40002e1 (f8227881) > > 00510 ---[ end trace 0000000000000000 ]--- > > 00510 Kernel panic - not syncing: Oops: Fatal exception > > 00510 SMP: stopping secondary CPUs > > 00510 Kernel Offset: disabled > > 00510 CPU features: 0x0000,000000e0,00000410,8240500b > > 00510 Memory Limit: none > > > > Investigation indicates that these bits are already set when we allocat= e > > slab page and are not zeroed out after allocation. We are not yet sure > > why these crashes start happening only recently but regardless of the > > reason, not initializing a field that gets used later is wrong. Fix it > > by initializing slab->obj_exts during slab page allocation. > > slab->obj_exts overlays page->memcg_data and the checks on page alloc and > page free should catch any non-zero values, i.e. page_expected_state() > page_bad_reason() so if anyone is e.g. UAF-writing there or leaving garba= ge > there while freeing the page it's a bug. > > Perhaps CONFIG_MEMCG is disabled in the ktests and thus the checks are no= t > happening? We could extend them for CONFIG_SLAB_OBJ_EXT checking > _unused_slab_obj_exts perhaps. But it would be a short lived change, see = below. Correct, CONFIG_MEMCG was disabled during these tests. We added BUG_ON() in the slab allocation path to trigger on these low bits and it did trigger but the same assertion in the freeing path did not catch anything. We suspected 4996fc547f5b ("mm: let _folio_nr_pages overlay memcg_data in first tail page") to cause this but Kent's bisection did not confirm that. > > > Fixes: 21c690a349ba ("mm: introduce slabobj_ext to support slab object = extensions") > > Reported-by: Kent Overstreet > > Tested-by: Kent Overstreet > > Signed-off-by: Suren Baghdasaryan > > Acked-by: Kent Overstreet > > Cc: > > We'll need this anyway for the not so far future when struct slab is > separated from struct page so it's fine but it would still be great to fi= nd > the underlying buggy code which this is going to hide. Yeah, we will try to find the culprit. For now to prevent others from stepping on this mine I would like to get this in. Thanks! > > > --- > > mm/slub.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/mm/slub.c b/mm/slub.c > > index b46f87662e71..dc9e729e1d26 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -1973,6 +1973,11 @@ static inline void handle_failed_objexts_alloc(u= nsigned long obj_exts, > > #define OBJCGS_CLEAR_MASK (__GFP_DMA | __GFP_RECLAIMABLE | \ > > __GFP_ACCOUNT | __GFP_NOFAIL) > > > > +static inline void init_slab_obj_exts(struct slab *slab) > > +{ > > + slab->obj_exts =3D 0; > > +} > > + > > int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s, > > gfp_t gfp, bool new_slab) > > { > > @@ -2058,6 +2063,10 @@ static inline bool need_slab_obj_ext(void) > > > > #else /* CONFIG_SLAB_OBJ_EXT */ > > > > +static inline void init_slab_obj_exts(struct slab *slab) > > +{ > > +} > > + > > static int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s= , > > gfp_t gfp, bool new_slab) > > { > > @@ -2637,6 +2646,7 @@ static struct slab *allocate_slab(struct kmem_cac= he *s, gfp_t flags, int node) > > slab->objects =3D oo_objects(oo); > > slab->inuse =3D 0; > > slab->frozen =3D 0; > > + init_slab_obj_exts(slab); > > > > account_slab(slab, oo_order(oo), s, flags); > > > > > > base-commit: c496b37f9061db039b413c03ccd33506175fe6ec >