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 2A8A5C36001 for ; Sat, 22 Mar 2025 01:50:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88BAD280002; Fri, 21 Mar 2025 21:50:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 83B93280001; Fri, 21 Mar 2025 21:50:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 702AC280002; Fri, 21 Mar 2025 21:50:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5147D280001 for ; Fri, 21 Mar 2025 21:50:55 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C7C8380B89 for ; Sat, 22 Mar 2025 01:50:55 +0000 (UTC) X-FDA: 83247508470.28.E7B9B72 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf20.hostedemail.com (Postfix) with ESMTP id C3F4B1C000D for ; Sat, 22 Mar 2025 01:50:53 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BDqnMDQg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of jannh@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742608253; 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=5bAMqt/kp5xNdpGpWqBm0DUWrT3oTcv1M70fkdyOEMI=; b=nUVuMy97Gmhdr31dxY1yb2dY7lUiy1a+zAqhaAqm7lKl8FHptk1d0BDOt3vkGWf+Enb6tZ O6GEQ9dqbPEFeEXPjM82DPyNAuuz3BnKqR6rz85ldK5b3ZYDSiZWe1I5MQuyIIh+t01IqL SvC8yaRrcI/oJXArPWHpfKbyaKDUUFs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742608253; a=rsa-sha256; cv=none; b=vWRtHZbpT+Scju7p38RcBiccU9iIcCtfH7B1kHdua7TRh8kRKXbmVySy4yezTH3cb06bN3 a0WP/KOzsAG+m30TBMu63yaSy45VfpZi1xBHe9HHgo20iDOyRpsckEeK854ndbezT5qI4Y vpGIPTg67VkQj0Q18bf4BVh01xQO7jc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BDqnMDQg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of jannh@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=jannh@google.com Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5e5cbd8b19bso2053a12.1 for ; Fri, 21 Mar 2025 18:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742608252; x=1743213052; 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=5bAMqt/kp5xNdpGpWqBm0DUWrT3oTcv1M70fkdyOEMI=; b=BDqnMDQgy7V9jwXljgoebufQ5yl4PR5gMuLLMHO8umDGI8pNCHoL3RygBaUuxCebn0 yghNU/Jkto0zMkAsIRV//I+xQLWV6rXAE6bbH/TjpKktxqMfJ+FOJytJejOAzrDSsjhJ RGQQhHueCoC0/I4oSazxhn5XhASbFaKCT8g5G6BM2uyM5ZgX3Nasa/cJduRtUzXk5oOs e0tnt2gWcZ0Fq2Rdw+p0N7XqhdWoAUE+ED9WTSWRo2gftmty6iydgO0Q/pIQJRDk8Tjh XXl4fgi1Nm5VAhJ39Mf0sSnDEYeoIjdz7QDj3oQ7Pb73mCmlkWrlZVa+Bg6aRqRoe0AS dQhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742608252; x=1743213052; 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=5bAMqt/kp5xNdpGpWqBm0DUWrT3oTcv1M70fkdyOEMI=; b=iI0VBgMV3mMzBtBnAeEwcHNiG6brxzz2tJrsbEOqrGlDAZoqVTRNpfbGzf594NNqYk XL4TlnSApkpF8balKBMJckh456iN1NrrWKDktKGsU/V52HkuPELjJIXWM5lKJNKQQ6ye /DerPrxZjRCdAqEeowSpaCJoz6g/qIruVrdYwiPRS7z7k6X1LiNJBxVrZg9XVsYNoIGf +5Igh8rTmBYvi8l8VeVs6Bt4GG66ULU8/ZlJH22BsqaiHxkk3IOzQTf0jf9lbqu0h8nI LDiLepe/hH5m/qMysRhzzXrb57ZffFJJDUlTyMm6wYvZgZbgLlM3u756NMwb1EVeStKX W45A== X-Forwarded-Encrypted: i=1; AJvYcCWW/HBlbSUdn5UXhfSQ/7iNzeu1/hwKU+15d0RTPgStxsMjqIyD5oHmv31DWihPSby2Eu2p+bLKVw==@kvack.org X-Gm-Message-State: AOJu0YysSfW5xvliTT9ztB5cBbt4c5Cs623brc7ltVGc5qdcUo+LHFPB vSvGnrDaVIhQnKv7gvLr+lhO7Od73Ahb3otW+hEYf+uDkbwxXkwa77KjYYDpvuTZSoaMTv9YIYj NFuJ86MwoREQY6XkfxlQwuobEvNBpG08D28Oi X-Gm-Gg: ASbGnctuLq/6CQR1Ea+XJnKaJOdQrjHYH2G5Q8R+xx+nawp+cNJcCp8ED96LqR0ryaB GHmNPcwiUhGOTo+01YErvCFutnOqrcK3Z21y5UJdvLh4VdbF72JYgxQy/Q9GptnwLPuqoelI22j DOS+14Omzmv2aDLHPzO7MJb/fWJ00Ts3Ms2rpYk22cmCyNks3FiGsx0EOx2aTB2Y1E X-Google-Smtp-Source: AGHT+IG7SqtDMOefUjHv5ne9WUK3g+yBu4XthxH3f4TMP/qf+N1EOd9SjiMcRqk87Yg1qrHnesdNGamPnVPjQCloWmQ= X-Received: by 2002:a50:9e46:0:b0:5e5:b44c:ec8f with SMTP id 4fb4d7f45d1cf-5ec20b2a1e6mr23783a12.3.1742608251799; Fri, 21 Mar 2025 18:50:51 -0700 (PDT) MIME-Version: 1.0 References: <20250321202620.work.175-kees@kernel.org> <20250321204105.1898507-4-kees@kernel.org> In-Reply-To: <20250321204105.1898507-4-kees@kernel.org> From: Jann Horn Date: Sat, 22 Mar 2025 02:50:15 +0100 X-Gm-Features: AQ5f1Jod17mZvChlstZSJR1ZRw7owBX6xbKHmuayoKFP5Ryp9maZ2Z5eVrzRgpc Message-ID: Subject: Re: [PATCH 4/5] slab: Set freed variables to NULL by default To: Kees Cook Cc: Vlastimil Babka , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, Miguel Ojeda , Nathan Chancellor , Marco Elver , Nick Desaulniers , Przemek Kitszel , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C3F4B1C000D X-Stat-Signature: goo69w6adwmbhgo88ym6518uwetyz1qw X-Rspam-User: X-HE-Tag: 1742608253-621955 X-HE-Meta: U2FsdGVkX1/95ETwnQCINOy+Jn0zygNJAUQGrG+1irlyt3Rt80SX/pV0KSfQc+dmBd8FXd6ZCiIG1/f5TEaoEG9liXrCXyx+sSTwG/q5D1WdTmE1Uv6CN7wN7rzVTBs6CdIWm7WMNm8Z+DP6tfYb0vo1+6QU5wYDK0PoIQgR0rSqoTEBTT2Fw4vUhIN+b47tYy1CfT0DRcU4Et1LsYIbk+7cdI2uopfajvHb2zEYT/EOX41J6bW6l5TKqGAt5eGTpAn3NaTAOcU0X9Ny06QSt+9Kn9LfH2BaOupRnO2oUB51nhdetg8TOl/XH3ZocViPIqiW1jsMIyYKQZMKAmgHpMp0S6TdbwMMp2Pa469DZqmcMY69Vybq9Bn5BYrVLh0BE469nMuy3+19l5braPCoO7VhV20+iDvi9o6JmDYZMskFqDWMm8BSOCsKvKY4iJ7QYC2XAdRJIy0JA5idJgcsUljhi45sanT3tnaci7DufwQcYLwzmro2H8l5w92MqIjGgFlklWuY6ZrrUtT9IkJUUv/Wz8EBDgMfwAV/zkJt/g1xtX1zOAXr6/v1/XR3W9d4LUAnCx3Z/7rI/ATBVxZV47OW+6T18KaWEKXBmMNXoCQeOvotAR4e+/Kpe46821nvaJNRnz645lG3BSGYarP8Yo7P9bKJTvJVpGNeEy+js8BYF3N9yz511bBJFRhzdPhNtI0CpL/jdby+Ga9Yu3Jp4X7omoPTnN8FFEcvAFDxAJ2YYH7ZrsuRGcSTHwRkSguWo5yftbaTDecUCUGXSp+6SovGzuzsWBlON5iV2uELXSfzTEKXN59KooAWtAstrLSjpdmvjYo8kpDeTx7dPtrR44bWr3yeH6QUHMAtT+hKClJ3+mT5vRzNATmVPQmqDmQvuln5OSeyn1e8Y5ibkFfDeOWd4zx+3iRkGpA8ZJQqvdFQIN3RFp5OAHoetkY0KmNZ1QJI4BM6pP9WJMpYhfm jGWZ76kf zYUvlsb7rg/NgpemtIsl5r4LtDa/AgSpmv3ggB4MRxR+aduN6G+gnuxiS2bSs359yVWgLaP54tggweUD6IpYHTVS+KHZzc0omAd8F7eODJz9SwSQE8KvHHxfPKYSnP76GyQ0Q89PpevZb5J1OmCKj1KxxDwqnCU2Qtg2orsal2s1QeuU/Fj2cMHLoaf8eFoT20jcae1sSMX4yEiwgP8Zm7K0XTHq7W4gMLXn2TlB0K+cSKEh6pp+DluVX/n1amdtMMalt5vf0b98zDy0uZszRaVd4hTx2DuVgJFin X-Bogosity: Ham, tests=bogofilter, spamicity=0.015994, 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, Mar 21, 2025 at 9:41=E2=80=AFPM Kees Cook wrote: > To defang a subset of "dangling pointer" use-after-free flaws[1], take th= e > address of any lvalues passed to kfree() and set them to NULL after > freeing. > > To do this manually, kfree_and_null() (and the "sensitive" variant) > are introduced. Unless callers of kfree() are allowed to rely on this behavior, we might want to have an option to use a poison value instead of NULL for this in debug builds. Hmm... in theory, we could have an object that points to its own type, like= so: struct foo { struct foo *ptr; }; And if that was initialized like so: struct foo *obj =3D kmalloc(sizeof(struct foo)); obj->ptr =3D obj; Then the following is currently fine, but would turn into UAF with this pat= ch: kfree(obj->ptr); That is a fairly contrived example; but maybe it would make sense to reorder the NULL assignment and the actual freeing to avoid this particular case? Another pattern that is theoretically currently fine but would be problematic after this would be if code continues to access a pointer after the pointed-to object has been freed, but just to check for NULL-ness to infer something about the state of the object containing the pointer, or to check pointer identity, or something like that. But I guess that's probably not very common? Something like: if (ptr) { mutex_lock(&some_lock); ... kfree(ptr); } ... if (ptr) { ... mutex_unlock(&some_lock); } But from scrolling through the kernel sources and glancing at a few hundred kfree() calls (not a lot compared to the ~40000 callsites we have), I haven't actually found any obvious instances like that. There is KMSAN test code that intentionally does a UAF, which might need to be adjusted to not hit a NULL deref instead. (And just an irrelevant sidenote: snd_gf1_dma_interrupt() has commented-out debugging code that would UAF the "block" variable if it was not commented out.)