From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 39581394FC39 for ; Thu, 17 Mar 2022 13:31:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 39581394FC39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x09.wildebeest.org [172.31.17.139]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id C4EC9302FB81; Thu, 17 Mar 2022 14:31:10 +0100 (CET) Received: by reform (Postfix, from userid 1000) id E54F52E81D4B; Thu, 17 Mar 2022 14:31:09 +0100 (CET) From: Mark Wielaard To: elfutils-devel@sourceware.org Cc: Evgeny Vereshchagin , david korczynski Subject: Some fuzzer workarounds Date: Thu, 17 Mar 2022 14:30:49 +0100 Message-Id: <20220317133051.100876-1-mark@klomp.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2022 13:31:15 -0000 Hi, I looked over the "ClusterFuzz-External via monorail" emails and found some "real" issues. But in general it is hard to determined what this cluster is complaining about. The emails are somewhat opaque and don't contain proper backtraces (with file and line numbers), nor do they contain any context on how the target was configured or with which flags or arguments any fuzzing testcases were run. The following fixes should fix reading of some broken ar archives and misaligned access of the section zero Shdr for mmaped ELF files where the start of the Elf image is at some offset from the start of the map. [PATCH 1/2] libelf: Take map offset into account for Shdr alignment [PATCH 2/2] libelf: Make sure ar_size starts with a digit before https://code.wildebeest.org/git/user/mjw/elfutils/log/?h=fuzz I haven't been able to replicate any other issues locally. I don't really trust the msan instrumentation, better use valgrind (although both might be too slow for fuzzing). There are also some other misaligned type access checks reported by ubsan, but I don't know if that is because of ALLOW_UNALIGNED is still defined or not (when configuring with --enable-analyze-undefined ALLOW_UNALIGNED is not defined, otherwise it is for some arches, including x86_64). I don't mind getting rid of ALLOW_UNALIGNED, but it is some work. Cheers, Mark