From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 220697404E for ; Wed, 12 Aug 2026 19:46:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786563985; cv=none; b=KkuBMxW5ZUljkPvYqD5M90HtYIQxKizDJiZMo3yrM0KpOKWj2SShdGO4D3aY1khnd0RQi7IH3f3PTwOkQFTWIq1SHdMXQkhs7yRXgqwyqlaGQxU5BQ+vaQeXROCLIIx2GCzUQWf8zqJldbOMc1lIBfh2E5HMuPkDRqSwOsyddOA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786563985; c=relaxed/simple; bh=GtIsD9pilK0SNml3Q+EG+xXEnVtMBItrgeg4ymDh+9w=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=BIXwMdInSSAJGJ0Ik+QthEHDz9gvAFG90QYE90lWE1baVANqXhucjExKPS/ZyzXMIcVbyTsFynubdyJK2+w+Grlez54Or5bnjUKmNnoNmGjVcONOYxeflyzDgRjJvD3K4VbwATpLpBTQxwFdb5ph3zwB16pc2iILxuTprCejZVI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=KbZPemz+; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="KbZPemz+" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4994d67d260so1555e9.1 for ; Wed, 12 Aug 2026 12:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786563982; x=1787168782; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:content-type :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=lLauo+hnjrgG9ZJXjVO0Yx2ztAEOgVX1xLL/xvR8xq0=; b=KbZPemz+V/1UAEocQhZbYKCizgX1A4K64KSGayuqgf4G7IV2rEQXo3VuCeQEaWaBZa T8hNtiuJ6YeeB/YsoaBY3fMYt4RJqzpgkEF+LJIFf7XXhuxT6T5Su+grAodI6vNaZlrW OynTN8D+KohlTsEP21hp94mriAl5+o+us1ALQNI/OKjwdopY0OJ6uvo2WiDdFu+HPWmL rcG6GrT7HEz9qd3e23ObN5FR01zKx5f0NxDv3Q8/0iEJBrWSO8AYC5e5ksldF7yYa7BE 6OQyZnZtXBCmu+dOaYCwGezCforTJy8iw06YqtB6533huAbHHlw0u1wu8TLp7ySaTXM+ Y6UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786563982; x=1787168782; h=cc:to:message-id:content-transfer-encoding:content-type :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=lLauo+hnjrgG9ZJXjVO0Yx2ztAEOgVX1xLL/xvR8xq0=; b=YZFIaEkQ28+5GQ9U626gAHz8Ku9QmZf4YeEZx76KhSHX19o24HDHc3x2fjsG45pjLh nV8SBDFQ5CbbYaosXo65GAgAtUJR4LZP481IHGp6/G+KHYXCUS1ay+VpdUUoNS2UqNGB 1I5jDP3aSlAvuFnYICWRM3mw3GREtTl3JK/UdBGTgGhx4ctkYApItR+OCBjwXCZ1y9Ld AQvPY4wfeMTP5tAv64sGvsVhrFq8FGAosJ6Sx1zUlN0MtHl4mg8vOcB5paXbn7amQqQg Y+KgulG24XkozI+qTGYbZKuP02jrq+ro1ekadZ9q4MTJQ7ujZvmn+w5s0j6FZs3fE+Qm MhUQ== X-Forwarded-Encrypted: i=1; AHgh+RpohT/2wRGhEdGXicwD0UmSYHC4t9NKeEJ/digd8WWyLR5NS7jL54bzcJGNqH3q+FuflRXCpu+OjMqvCNs=@vger.kernel.org X-Gm-Message-State: AOJu0Yy0g81uWqI83ne42iL9rTDejK1Q+AfWIt2YHty4Tt8V3ChpkioQ cwgFQm8YD4UPlgSwApEs5BBpnjdVyAWXNHmXTkD4X7XO7hyJqK1zTo1thEVBoAy0jQ== X-Gm-Gg: AR+sD12YCJu0kIMQFPv/x64KJQ1qfoKoaC5FiU0wWAOMkLFjFwfZRx0YTNkhkAeiN9n CmW1GgVTE1f1+GgSY/7nDlDaagRBOg7joNtPM2B08No+i9UjKPRVtcg309Op6FNQ3zlN6Kn18+R blNjW4jrxjQLh6nIwEhTRfNHWqSSdcvUN/L2WV6PFxrC9gFGxlfwv3FSVEckDn7W5ucV7H6G2vL 5gArD9AAEe+5hyZbGqFUY1E7Ukzy5RjNKcYG28otTVqZP9rwJ+BcgC2E40h4/1Jz4cH8NR7Cylt 1mqMvTsTwd4YfXl+fYepWH+xtaI26ewDXo53ZScbwRj+tLUSkJbCTUkB/IkLB0cCJPbHqAlI6c1 Fcyz4oRogPWGkWGzeynJwM/bpeIK45Jk+lceiGMCwqBqyu5ARVlMUZJRMgi+4/QQ+cxCcCofBGk Gc4duAsJ+2ZEXa8EDOsR+wcBrXHfeX8aAa5+LyRJy0GyEy8pk3vA/oRK2l7KIk8V5ud2Vj5vWhA VzagcgyUMhjn6cSelwDl0I6STCz8pHEoJW2KSulrqYWtHUB X-Received: by 2002:a05:600c:42c5:b0:495:7a0b:3b4a with SMTP id 5b1f17b1804b1-49981f9c9d6mr97045e9.7.1786563981961; Wed, 12 Aug 2026 12:46:21 -0700 (PDT) Received: from localhost ([2a00:79e0:288a:8:d358:790c:76c6:1a58]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49981b62894sm9412265e9.13.2026.08.12.12.46.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 12:46:21 -0700 (PDT) From: Jann Horn Date: Wed, 12 Aug 2026 21:46:14 +0200 Subject: [PATCH] bug: remove __must_check requirement for CHECK_DATA_CORRUPTION() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260812-data-corruption-mustcheck-v1-1-5f59bd3bc2b8@google.com> X-B4-Tracking: v=1; b=H4sIAIXNfGoC/yXM0QrCMAyF4VcZuTawFqnDVxEvujRzUdxG0oow9 u7W7fKDc/4VjFXY4NqsoPwRk3mqcKcGaIzTg1FSNfjWh7ZzHlPMEWlWLUuuW3wXyzQyvZBc7IZ LSIH9Gep/UR7ku7dv98NW+idT/gdh237+ZdcnfQAAAA== X-Change-ID: 20260812-data-corruption-mustcheck-c1a8f76d6e24 To: Kees Cook Cc: "Gustavo A. R. Silva" , linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, Jann Horn X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1786563977; l=2545; i=jannh@google.com; s=20240730; h=from:subject:message-id; bh=GtIsD9pilK0SNml3Q+EG+xXEnVtMBItrgeg4ymDh+9w=; b=Y3NRtAopcLAoSsP9DIwxXYLyoNePSF1VwGoE+HK3lnL79OhBo67uNhsu2FK0Y8N6pgmX+lVO8 aKwU0DvvSM3CbeCbaKVPZ5NTbs85yL43sIcZaER0gxvRhfFDCbpg9Ux X-Developer-Key: i=jannh@google.com; a=ed25519; pk=AljNtGOzXeF6khBXDJVVvwSEkVDGnnZZYqfWhP1V+C8= There are codepaths that currently use something like WARN() where CHECK_DATA_CORRUPTION() would be more appropriate, but it is not possible to gracefully bail out when corruption has been detected. CHECK_DATA_CORRUPTION() is currently deliberately unusable in such cases. While it would be nice for users of CHECK_DATA_CORRUPTION() to bail out on corruption, that shouldn't be a hard requirement for CHECK_DATA_CORRUPTION(). So remove the __must_check requirement so that CHECK_DATA_CORRUPTION() can be used in codepaths where bailing out is infeasible. Signed-off-by: Jann Horn --- I think this should probably go through Kees' hardening tree? This patch is inspired by me looking at file_ref_inc() and thinking that that really should be using CHECK_DATA_CORRUPTION(). --- include/linux/bug.h | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/include/linux/bug.h b/include/linux/bug.h index 17a4933c611b..e8d1febd8ae4 100644 --- a/include/linux/bug.h +++ b/include/linux/bug.h @@ -89,22 +89,21 @@ static inline void mem_dump_obj(void *object) {} /* * Since detected data corruption should stop operation on the affected - * structures. Return value must be checked and sanely acted on by caller. + * structures. Return value should be checked and sanely acted on by caller if + * possible. */ -static inline __must_check bool check_data_corruption(bool v) { return v; } -#define CHECK_DATA_CORRUPTION(condition, addr, fmt, ...) \ - check_data_corruption(({ \ - bool corruption = unlikely(condition); \ - if (corruption) { \ - if (addr) \ - mem_dump_obj(addr); \ - if (IS_ENABLED(CONFIG_BUG_ON_DATA_CORRUPTION)) { \ - pr_err(fmt, ##__VA_ARGS__); \ - BUG(); \ - } else \ - WARN(1, fmt, ##__VA_ARGS__); \ - } \ - corruption; \ - })) +#define CHECK_DATA_CORRUPTION(condition, addr, fmt, ...) ({ \ + bool corruption = unlikely(condition); \ + if (corruption) { \ + if (addr) \ + mem_dump_obj(addr); \ + if (IS_ENABLED(CONFIG_BUG_ON_DATA_CORRUPTION)) { \ + pr_err(fmt, ##__VA_ARGS__); \ + BUG(); \ + } else \ + WARN(1, fmt, ##__VA_ARGS__); \ + } \ + corruption; \ +}) #endif /* _LINUX_BUG_H */ --- base-commit: 3d6d817622b0a9721e3cc404df3469171582be13 change-id: 20260812-data-corruption-mustcheck-c1a8f76d6e24 Best regards, -- Jann Horn