linux-hardening - On clang vs. gcc fortify warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <1f3f722c-657d-21ec-d6e2-7f79ce5462e3@yandex.ru>
Date:   Thu, 22 Jun 2023 13:42:16 +0300
From:   Dmitry Antipov <dmantipov@...dex.ru>
To:     Kees Cook <keescook@...omium.org>
Cc:     linux-hardening@...r.kernel.org
Subject: On clang vs. gcc fortify warnings

Recently I've observed a (not so?) subtle difference using CONFIG_FORTIFY_SOURCE=y
with clang vs. gcc. The problem may be illustrated by the following tiny module:

#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/fortify-string.h>

static const char example[][32] = {
	"abcd",
	"xyzt",
	"1234",
	"5678"
};

static int __init test_init(void) {
	char data0[128], data1[128];

	/* No warnings with both gcc 13.1.1 and clang 16.0.5 */
         memcpy(data0, example, sizeof(example));

	/* No warning with gcc 13.1.1 but warning with clang 16.0.5:

	   ./include/linux/fortify-string.h:529:4: warning: call to
	   '__read_overflow2_field' declared with 'warning' attribute:
	   detected read beyond size of field (2nd parameter); maybe
	   use struct_group()? [-Wattribute-warning]
                         __read_overflow2_field(q_size_field, size);
	*/

	memcpy(data1, *example, sizeof(example));
         return 0;
}

static void __exit test_exit(void) {
}

module_init(test_init);
module_exit(test_exit);

MODULE_LICENSE("GPL");

I suppose that clang wins here because 'memcpy(data1, *example, sizeof(example))'
may be interpreted as an attempt to copy 128 bytes from 32-byte source buffer.
So the question is why gcc don't diagnose this as well.

Thanks,
Dmitry