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 971A6C28B30 for ; Thu, 20 Mar 2025 14:37:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 740DF280002; Thu, 20 Mar 2025 10:37:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F15F280001; Thu, 20 Mar 2025 10:37:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56B0C280002; Thu, 20 Mar 2025 10:37:38 -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 3223A280001 for ; Thu, 20 Mar 2025 10:37:38 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5B5C11A159C for ; Thu, 20 Mar 2025 14:37:38 +0000 (UTC) X-FDA: 83242182996.11.4712762 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf19.hostedemail.com (Postfix) with ESMTP id D36E01A0005 for ; Thu, 20 Mar 2025 14:37:35 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GgEPBbAO; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf19.hostedemail.com: domain of toke@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=toke@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742481456; a=rsa-sha256; cv=none; b=M/c7IXNfr5SYR4ukTr28j/z5+30yIKVtjytxeFB0uJGh+XBxfnuUewHjFylPwozmAu+qMG Pc/I1JA4x48+fE49Kpt2TyQCsOeqv7vvwewx3VfjPua8zqsSsZOO6Z6NN38QCkgIInbo/e zaOEW+au+n+MwwrvwpsJyEV7PNEgU7U= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GgEPBbAO; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf19.hostedemail.com: domain of toke@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=toke@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742481456; 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=q8jQTpgamRT98fNj7lmPmNzbNNmBivJr+9bIgtnjm7g=; b=u6MTCGoOjJd3L/e8Lj4d+1/o1OWwFnT4Un5EQWEp0BqA3yQnIqFd00N1Wrnn902Abv9G1M EUlEzRf+J7CZlOLZzTk1X2UTPnPdm8IPdpIeCw8Gbam8okVsNUzFetptmLS5bUkMTEBQ1Q 9Y8Vcx1hKMgn+5bOUjl6HaZCY0ErGmU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1742481455; h=from:from: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; bh=q8jQTpgamRT98fNj7lmPmNzbNNmBivJr+9bIgtnjm7g=; b=GgEPBbAO/LCyQByiDi827KZk/5N1ICxRiI6JbIVVpPS27s4FoaDJ/n9FsBl0uGYc16qy11 +tcNgVSWWzm809Thij+JgDwFrcNQPZ30Vk2EkDKAk8LtIE8ollaAmgHSLn4RcJc/urmS89 Kf8GXW0SXbJwiLBKyQEL4VNpCsCCR80= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-602-G2XjMC4XMUSgiI_BF2x4tA-1; Thu, 20 Mar 2025 10:37:33 -0400 X-MC-Unique: G2XjMC4XMUSgiI_BF2x4tA-1 X-Mimecast-MFC-AGG-ID: G2XjMC4XMUSgiI_BF2x4tA_1742481452 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-30bfaec88edso8989271fa.1 for ; Thu, 20 Mar 2025 07:37:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742481452; x=1743086252; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZLx6gnmmSWWfdNgPfLYTsxSrV+Ix7KpS1F+U6ftX2nU=; b=oCeYq4yxnRzkD6YcFxOkGNSpkOF+Dm9vGOSTWJFWQqSyg0km1lZZwpnL0P9uf4YsqW GrypubkjG3D0EZZJYPOkb5JFuD75hm2vbFT/r5FD+lACBGrCfQAO8jYYffBZzmdGOiZD QX8t/3rcRVc1HKi6tRS9Gpy9g+CLWzGWAHegRTAR1hM2wqaGE8KITcBPBoVlsyGDBWzH jt1IZdAbrmvNKP2w2k0E+quAHTSJDF3KJ+xR6Y9ZNoTTNONsANBfYcvGhBUrMvfB1slb vlGi2TLnR/ETkl5qpelFovWdJPhSN9E5Xh9YGtN1/siJTrX1NZ1lXZFCc4OuH0/8eMIa eD/g== X-Forwarded-Encrypted: i=1; AJvYcCX/UGKpy1OjqTFQx/YZJP6wxfbr3K17eWpxMasAVX4FMpnkaoXoyQhg2PZFmoOJOXB6tXYIM+4fwA==@kvack.org X-Gm-Message-State: AOJu0YzarVN2Smvgasc6QSkKdP0pwI0xtQNvNJxVxSmRzTU1vzjPM9ce n3mDKARscDjOEP+15BnReIWmk5/H8cuYCCvI0Cmr3YGO1nBT2XeF1/s1exbfwVH0VsfrhPM/V6X NZGx8mJq8KLU3p1oF0QBWK+7AvJINoz5FkFi+9kp9QW0b65cz X-Gm-Gg: ASbGncvL0+a1GtTKeCLt3GD4zkZnxLPumUbLcsBqYqjE72T3eKJuuhIdEXPm3Zpht/J 8g6DfgKX47+K8IEwv0F/DBlrqPbEHPPUNJ5apciTzT20j/Gk2ygC37rcdI+zsX9jzJbIUvjKqkI eN8+jLBFUbzc/dQOHB9+OrBWBdsWBrwKqaiEV7689pyzdvHO3Zt4XsaR4Qd7xqA/kCr1wdmlZCU jkckKJ6a9Qk4WEqPjBXiwDl7gqjJgr39mhkNkEJn8sOKkgP0UEGM4nPrmrdBuMjVDYJ36kACzyd ZQr/yAiiWJz0 X-Received: by 2002:a05:6512:3f18:b0:549:929c:e896 with SMTP id 2adb3069b0e04-54acfaa1b0emr1518836e87.11.1742481451805; Thu, 20 Mar 2025 07:37:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE5VpCfZOFBC54LR922wO7u7GK5UhK0NC/mhGGmpD3DQ8vCNlbhBNi5GGvL7dfWltRcMPHQyg== X-Received: by 2002:a05:6512:3f18:b0:549:929c:e896 with SMTP id 2adb3069b0e04-54acfaa1b0emr1518818e87.11.1742481451151; Thu, 20 Mar 2025 07:37:31 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-549ba7c1203sm2219442e87.90.2025.03.20.07.37.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Mar 2025 07:37:30 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 9D74918FC2E8; Thu, 20 Mar 2025 15:37:29 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Solar Designer , Yunsheng Lin Cc: Yunsheng Lin , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Andrew Lunn , Eric Dumazet , Paolo Abeni , Ilias Apalodimas , Simon Horman , Andrew Morton , Mina Almasry , Yonglong Liu , Pavel Begunkov , Matthew Wilcox , Robin Murphy , IOMMU , segoon@openwall.com, kernel-hardening@lists.openwall.com, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-rdma@vger.kernel.org, linux-mm@kvack.org, Qiuling Ren , Yuying Ma , sultan@kerneltoast.com Subject: Re: [PATCH net-next 3/3] page_pool: Track DMA-mapped pages and unmap them when destroying the pool In-Reply-To: <20250320023202.GA25514@openwall.com> References: <20250314-page-pool-track-dma-v1-0-c212e57a74c2@redhat.com> <20250314-page-pool-track-dma-v1-3-c212e57a74c2@redhat.com> <87jz8nhelh.fsf@toke.dk> <7a76908d-5be2-43f1-a8e2-03b104165a29@huawei.com> <87wmcmhxdz.fsf@toke.dk> <20250320023202.GA25514@openwall.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 20 Mar 2025 15:37:29 +0100 Message-ID: <87ldszix92.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: lnAIiTdUZ6SaTxnoKwxk0LKmD3DGH9u8wylPuqQyGGw_1742481452 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspam-User: X-Stat-Signature: u6jpf84hyknf946wbc1mj1jycwhxhwsm X-Rspamd-Queue-Id: D36E01A0005 X-HE-Tag: 1742481455-761958 X-HE-Meta: U2FsdGVkX18sA3ufR8oEVdONuzROTe0uF67r2xGiJJ77p/wLGJtpUoY2x5kmhxPF1cu6TvZYY2UfB9bkn54xkf5gh6tTAdMIcNPSrXbkzrtHsIatJZIZRe0CDaYiG2gkIehuw46rKiHYyXX//RRPfS6hMBRl7+TX2T8MWbqziPtyMLVRRYM3Y7swTDHEgjFxMg8suGRv7OjEptkcMkVBsTtvLq1hr9XjodezM2ORSFjPKPfNnMge1P8DsZqU4WwNdVmRTbw5sD21H3vUgJe4wWkRKDSZOgyDtr1R/mJTYbfh4MTuLit3nraUp1SvOYSIWZ9Pvdz4unKLpW1huZmKEzNDAlBC8HXaJv0G7opeT8MhV/Qj2WihbICFPn/E0Q65e9wFURvn3n4rgu8bnySkHesNO4FWzXm3qJgmZW6q3uSY0D38QsknMkAc3KdwWl2lydE3m+UjU5XtB9FC9wDOZFlsOwq/qhM6rt7HSLBQwhsUXbyNJ8MFhMwlHT55wxJVmZZSx9Tb9Nvi0pEBRGiJ5tmUUdTZ4UnK/zXwh28Lo4m+y4Amvzb1ymJrWpevXU4j1+9IqBVnCdDif7QqKMkWyjctqRdX67kYhpsp9Vniste4eKy8HsDsPvFm8+XA2gLSffd95y5RBYkjyhJWd+So4HsQbcB99DYro0rObXRPhsOSmaWHhi6idaw4PhSaaMqVkQUvJNmVMn6vMq0FwtRXK+xZTDwjEvtRpedh3nPxp0Am31SMpNu3DijjLmE2riUK370wz2EPX52o9RGKjd9dxVR1/Y/FYvsOhFv3ugzJaUv2FwW4vsSpK1UsSe95UdPv7paHR9/TAuvwkXGtSC/D93+kYNDXYoOj1Mv8BDCFUTnXdR54lMUP7aSFfnVoLbPYVPo6Bv9yGHZMfnqHD3p/l2gGe8zTiqnToQQcP3WU+FOyYAK4/nqLbs5hWLoO6veKV5ZA556C7Z7Kr6jFoH1 +0aYBBv6 mko+XSzLD1Kme+/AqKfqrm2odr6GbENurbHwa7w0REH/WRsjmNNEAWl/xC+Vx6OmiOuC4gEH7Ib+LY2DPAYI/nWdnjCXGd7Mw+exanhS06W9NNsoUdXqY4ANU7E4d88yh6qnwd1lV8gTFfxlqyNLI8nj6upQz2XAVc9oAPcUh08nJ9jr1qSHPLhYtjKdwkWtXaJAJDBK8B956PQkWU9K1PdhhJM0u0gJK16Xs9kf2JsMl4DtJ/4mxn8RxYWJgxFRl8rHMMhaLq559wfLij51+wDlhhhbANZIynrXRKDOL7Er+WL1dbhGhRMbeuxXX+RmKEaccVl4l9mep0KBgMD42ywUcVg4zW3lfFxZgi66aZ8PKy6TEjkvmcNOV2bbiD/3I1t1cULaKPOFDuqoxao3knB7leL8VR0cdd6aSqeEo2OeNVgmfKbDz//nyZzyCMQS0EuAs2tJLJbuV+fpB1XamzNf2rLJqsg/NcS1C2voB8REE0+wVy54LleQWc1S9kapMO9jP9betETs4QZmPxmoWMhrElW6zDdFaylrp7+pMEaGtSGNnStSjqjxBEwJnmasova2CAbxMEgZws0biLUP7FZ2teur/o6ZCAIR3M5BUGrKRQIkqI2qaP8//Sozl/9fXhuGIUf3D7kOAd8fboQ21hBSu+lduAxHhycfhJp2v14o3eNK/1BLsKhsL1sl9oDiLV1keQTpbtN+Tj8TBs0/G/CkOt6uDzg6RCkLY9Skz7W+27Xpk6WFM2ub4V9rdFN0Sg8Gnn08IWt3x105KLjFij1jGaDG8N7Mfp9jbo8YkejyE+W8n/vl8ENTP8uKdcYIsIXCzaMoYbRT5bx89Rw0AJy5ncRf8bx32XRAK6NGiQPrxyCwtlsenSWd5wC5hFNwSMMYD0CHfNjxLLWPLoIvHCZg/hk5g9t2DLHW+m9OBLd4Vao2vI7Rtv4baBA== 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: Solar Designer writes: > On Wed, Mar 19, 2025 at 07:06:57PM +0800, Yunsheng Lin wrote: >> On 2025/3/19 4:55, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> > Yunsheng Lin writes: >> >> On 2025/3/17 23:16, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >>> Yunsheng Lin writes: >> >>>> On 3/14/2025 6:10 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> >>>> >> >>>> ... >> >>>> >> >>>>> To avoid having to walk the entire xarray on unmap to find the pag= e >> >>>>> reference, we stash the ID assigned by xa_alloc() into the page >> >>>>> structure itself, using the upper bits of the pp_magic field. This >> >>>>> requires a couple of defines to avoid conflicting with the >> >>>>> POINTER_POISON_DELTA define, but this is all evaluated at compile-= time, >> >>>>> so does not affect run-time performance. The bitmap calculations i= n this >> >>>>> patch gives the following number of bits for different architectur= es: >> >>>>> >> >>>>> - 24 bits on 32-bit architectures >> >>>>> - 21 bits on PPC64 (because of the definition of ILLEGAL_POINTER_V= ALUE) >> >>>>> - 32 bits on other 64-bit architectures >> >>>> >> >>>> From commit c07aea3ef4d4 ("mm: add a signature in struct page"): >> >>>> "The page->signature field is aliased to page->lru.next and >> >>>> page->compound_head, but it can't be set by mistake because the >> >>>> signature value is a bad pointer, and can't trigger a false positiv= e >> >>>> in PageTail() because the last bit is 0." >> >>>> >> >>>> And commit 8a5e5e02fc83 ("include/linux/poison.h: fix LIST_POISON{1= ,2}=20 >> >>>> offset"): >> >>>> "Poison pointer values should be small enough to find a room in >> >>>> non-mmap'able/hardly-mmap'able space." >> >>>> >> >>>> So the question seems to be: >> >>>> 1. Is stashing the ID causing page->pp_magic to be in the mmap'able= / >> >>>> easier-mmap'able space? If yes, how can we make sure this will = not >> >>>> cause any security problem? >> >>>> 2. Is the masking the page->pp_magic causing a valid pionter for >> >>>> page->lru.next or page->compound_head to be treated as a vaild >> >>>> PP_SIGNATURE? which might cause page_pool to recycle a page not >> >>>> allocated via page_pool. >> >>> >> >>> Right, so my reasoning for why the defines in this patch works for t= his >> >>> is as follows: in both cases we need to make sure that the ID stashe= d in >> >>> that field never looks like a valid kernel pointer. For 64-bit arche= s >> >>> (where CONFIG_ILLEGAL_POINTER_VALUE), we make sure of this by never >> >>> writing to any bits that overlap with the illegal value (so that the >> >>> PP_SIGNATURE written to the field keeps it as an illegal pointer val= ue). >> >>> For 32-bit arches, we make sure of this by making sure the top-most = bit >> >>> is always 0 (the -1 in the define for _PP_DMA_INDEX_BITS) in the pat= ch, >> >>> which puts it outside the range used for kernel pointers (AFAICT). >> >> >> >> Is there any season you think only kernel pointer is relevant here? >> >=20 >> > Yes. Any pointer stored in the same space as pp_magic by other users o= f >> > the page will be kernel pointers (as they come from page->lru.next). T= he >> > goal of PP_SIGNATURE is to be able to distinguish pages allocated by >> > page_pool, so we don't accidentally recycle a page from somewhere else= . >> > That's the goal of the check in page_pool_page_is_pp(): >> >=20 >> > (page->pp_magic & PP_MAGIC_MASK) =3D=3D PP_SIGNATURE >> >=20 >> > To achieve this, we must ensure that the check above never returns tru= e >> > for any value another page user could have written into the same field >> > (i.e., into page->lru.next). For 64-bit arches, POISON_POINTER_DELTA >>=20 >> POISON_POINTER_DELTA is defined according to CONFIG_ILLEGAL_POINTER_VALU= E, >> if CONFIG_ILLEGAL_POINTER_VALUE is not defined yet, POISON_POINTER_DELTA >> is defined to zero. >>=20 >> It seems only the below 64-bit arches define CONFIG_ILLEGAL_POINTER_VALU= E >> through grepping: >> a29815a333c6 core, x86: make LIST_POISON less deadly >> 5c178472af24 riscv: define ILLEGAL_POINTER_VALUE for 64bit >> f6853eb561fb powerpc/64: Define ILLEGAL_POINTER_VALUE for 64-bit >> bf0c4e047324 arm64: kconfig: Move LIST_POISON to a safe value >>=20 >> The below 64-bit arches don't seems to define the above config yet: >> MIPS64, SPARC64, System z(S390X),loongarch >>=20 >> Does ID stashing cause problem for the above arches? >>=20 >> > serves this purpose. For 32-bit arches, we can leave the top-most bits >> > out of PP_MAGIC_MASK, to make sure that any valid pointer value will >> > fail the check above. >>=20 >> The above mainly explained how to ensure page_pool_page_is_pp() will >> not return false positive result from the page_pool perspective. >>=20 >> From MM/security perspective, most of the commits quoted above seem >> to suggest that poison pointer should be in the non-mmap'able or >> hardly-mmap'able space, otherwise userspace can arrange for those >> pointers to actually be dereferencable, potentially turning an oops >> to an expolit, more detailed example in the below paper, which explains >> how to exploit a vulnerability which hardened by the 8a5e5e02fc83 commit= : >> https://www.usenix.org/system/files/conference/woot15/woot15-paper-xu.pd= f >>=20 >> ID stashing seems to cause page->lru.next (aliased to page->pp_magic) to >> be in the mmap'able space for some arches. > > ... > >> To be honest, I am not that familiar with the pointer poison mechanism. >> But through some researching and analyzing, it makes sense to overstate >> it a little as it seems to be security-related. >> Cc'ed some security-related experts and ML to see if there is some >> clarifying from them. > > You're correct that the pointer poison values should be in areas not > mmap'able by userspace (at least with reasonable mmap_min_addr values). > > Looking at the union inside "struct page", I see pp_magic is aliased > against multiple pointers in the union'ed anonymous structs. > > I'm not familiar with the uses of page->pp_magic and how likely or not > we are to have a bug where its aliasing with pointers would be exposed > as an attack vector, but this does look like a serious security concern. > It looks like we would be seriously weakening the poisoning, except on > archs where the new values with ID stashing are still not mmap'able. > > I just discussed the matter with my colleague at CIQ, Sultan Alsawaf, > and he thinks the added risk is not that bad. He wrote: > >> Toke's response here is fair: >>=20 >> > Right, okay, I see what you mean. So the risk is basically the >> > following: >> >=20 >> > If some other part of the kernel ends up dereferencing the >> > page->lru.next pointer of a page that is owned by page_pool, and which >> > has an ID stashed into page->pp_magic, that dereference can end up bei= ng >> > to a valid userspace mapping, which can lead to Bad Things(tm), cf the >> > paper above. >> >=20 >> > This is mitigated by the fact that it can only happen on architectures >> > that don't set ILLEGAL_POINTER_VALUE (which includes 32-bit arches, an= d >> > the ones you listed above). In addition, this has to happen while the >> > page is owned by page_pool, and while it is DMA-mapped - we already >> > clear the pp_magic field when releasing the page from page_pool. >> >=20 >> > I am not sure to what extent the above is a risk we should take pains = to >> > avoid, TBH. It seems to me that for this to become a real problem, lot= s >> > of other things will already have gone wrong. But happy to defer to th= e >> > mm/security folks here. >>=20 >> For this to be a problem, there already needs to be a use-after-free on >> a page, which arguably creates many other vectors for attack. >>=20 >> The lru field of struct page is already used as a generic list pointer >> in several places in the kernel once ownership of the page is obtained. >> Any risk of dereferencing lru.next in a use-after-free scenario would >> technically apply to a bunch of other places in the kernel (grep for >> page->lru). > > We also tried searching for existing exploitation techniques for "struct > page" use-after-free. We couldn't find any. The closest (non-)match I > found is this fine research (the same project presented differently): > > https://i.blackhat.com/BH-US-24/Presentations/US24-Qian-PageJack-A-Powerf= ul-Exploit-Technique-With-Page-Level-UAF-Thursday.pdf page 33+ > https://arxiv.org/html/2401.17618v2#S4 > https://phrack.org/issues/71/13 > > The arxiv paper includes this sentence: "To create a page-level UAF, the > key is to cause a UAF of the struct page objects." However, we do not > see them actually do that, and this statement is not found in the slides > nor in the Phrack article. Confused. Thank you for weighing in! I will post an updated version of this patch with a reference to this discussion and try to summarise the above. > Thank you for CC'ing me and the kernel-hardening list. However, please > do not CC the oss-security list like that, where it's against content > guidelines. Only properly focused new postings/threads are acceptable > there (not CC'ing from/to other lists where only part of the content is > on-topic, and follow-ups might not be on-topic at all). See: > > https://oss-security.openwall.org/wiki/mailing-lists/oss-security#list-co= ntent-guidelines > > As a moderator for oss-security, I'm going to remove these messages from > the queue now. Please drop Cc: oss-security from any further replies. > > If desired, we may bring these topics to oss-security separately, with a > proper Subject line and clear description of what we're talking about. Noted, thanks! -Toke