Received: by 2002:a89:d88:0:b0:1fa:5c73:8e2d with SMTP id eb8csp65617lqb; Thu, 23 May 2024 10:53:23 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXtYUPfPQvXEIAz0hVUgo7/vOiKg2HAHLNFK+HSeSIUI0SR0HvFbhgfo6t2fnlgdql5jv5ynUpzA1Bwv9mfrRI4C1O1e9NdX65ZNdGMdw== X-Google-Smtp-Source: AGHT+IE/LXfApqmgq27f3BZ1ptlkJKYrm2oZCzxIdI/WoSoI5yFYYUpEHHOr+Lt1/hw3UnVN0U/f X-Received: by 2002:a17:907:3f97:b0:a59:9edf:14b6 with SMTP id a640c23a62f3a-a62642e0aaemr5323766b.45.1716486803704; Thu, 23 May 2024 10:53:23 -0700 (PDT) Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id a640c23a62f3a-a5a3fb5eea6si1459224866b.22.2024.05.23.10.53.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 May 2024 10:53:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-187848-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@efficios.com header.s=smtpout1 header.b=ARJFYZmC; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-187848-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-187848-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 70FDB1F21899 for ; Thu, 23 May 2024 17:53:23 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DD5907D086; Thu, 23 May 2024 17:53:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="ARJFYZmC" Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 15E982628D; Thu, 23 May 2024 17:53:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=167.114.26.122 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716486793; cv=none; b=QtmpQU1IE7XkfDi9PeAfEaWvjHoY044pn9MsE8wmiv1IIpaBnQq/yhv+5jtdRSNaLugfYmkuP2qjL7K1/chKKGBd45/zZmYe6s/u4lNuznJ26nKkbblkID2wVZbUgKszfJz94ekntX7/KZz+HXvVCAbRY4zE9TW/1GT6DdFdbGo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716486793; c=relaxed/simple; bh=eG8U1x4QQ6oumcc1cnDrsvXG+P8ChtqXaLkve5TzQPw=; h=Message-ID:Date:MIME-Version:From:To:Cc:Subject:Content-Type; b=i0aS7XXVOmz2Nc1kLEPqxNeUk4TR7w6MsWemoCEY7ZSzWtUGtnrLo6sn2Qh61Rdpq48z/aJn+LsuCkA1CqaPzB8EGcOErbAgqfRaWfUMT0Lcg/n7A2lCjIeNC6ZCcRP8QG3yiLZnmoFBoVOiApBZM0qHo8uQJQKsyrpha3p1B+k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=ARJFYZmC; arc=none smtp.client-ip=167.114.26.122 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1716486786; bh=eG8U1x4QQ6oumcc1cnDrsvXG+P8ChtqXaLkve5TzQPw=; h=Date:From:To:Cc:Subject:From; b=ARJFYZmCYbAkdCd3p5z/igjCc7ZkAZOOSs8k71Th+r0zrlLrf4DRoQpinm8YM6vwg 8QhNU0Pi00NDZj6vqTRVwSne3OYf62I8v7GNaHbSipEvxKwX59C8ZdrNXHEzErUl3+ oHVj42XQCDW8zud5eT7I3reyqfKoOy78zv5zuD+spLbToK5w+zQbZGEh1hYBoqq4kQ I94qF6TZADNmYhpn0hbOTpuuoGgHQSSGgQX30Q3Qb7mSttRLZ0JTDtE4+Ez1b/KS4D UWI8V4V9QrArEg4YgKEEC7n55DKvkI2M3FktTlBGkQXvgBSHO6kaZr1AwqTp+W9+C4 0YPOjOrYM+G2A== Received: from [172.16.0.134] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4VlbPG3fBRz116b; Thu, 23 May 2024 13:53:06 -0400 (EDT) Message-ID: <986294ee-8bb1-4bf4-9f23-2bc25dbad561@efficios.com> Date: Thu, 23 May 2024 13:53:42 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Mathieu Desnoyers To: Kent Overstreet , Brian Foster Cc: Kees Cook , linux-kernel , linux-bcachefs@vger.kernel.org Subject: Use of zero-length arrays in bcachefs structures inner fields Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, Looking around in the bcachefs code for possible causes of this KMSAN bug report: https://lore.kernel.org/lkml/000000000000fd5e7006191f78dc@google.com/ I notice the following pattern in the bcachefs structures: zero-length arrays members are inserted in structures (not always at the end), seemingly to achieve a result similar to what could be done with a union: fs/bcachefs/bcachefs_format.h: struct bkey_packed { __u64 _data[0]; /* Size of combined key and value, in u64s */ __u8 u64s; [...] }; likewise: struct bkey_i { __u64 _data[0]; struct bkey k; struct bch_val v; }; (and there are many more examples of this pattern in bcachefs) AFAIK, the C11 standard states that array declarator constant expression delimited by [ ] shall have a value greater than zero. Effectively, we can verify that this code triggers an undefined behavior with: #include struct z { int x[0]; int y; int z; } __attribute__((packed)); int main(void) { struct z a; a.y = 1; printf("%d\n", a.x[0]); } clang-15 -fsanitize=undefined -o a a.c /a a.c:14:17: runtime error: index 0 out of bounds for type 'int[0]' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior a.c:14:17 in 1 Also, gcc warns that ISO C forbids zero-size arrays when compiling with -pedantic: gcc -std=c11 -pedantic -o a a.c a.c:4:13: warning: ISO C forbids zero-size array ‘x’ [-Wpedantic] 4 | int x[0]; And clang states that this is only supported as an extension, even though accessing it seems to be classified as an undefined behavior by UBSAN. clang-15 -std=c11 -pedantic -o a a.c a.c:4:8: warning: zero size arrays are an extension [-Wzero-length-array] int x[0]; So I wonder if the issue reported by KMSAN could be caused by this pattern ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com