From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Bindat can exhaust memory when unpacking to vector Date: Sat, 04 Nov 2023 04:21:25 -0400 Message-ID: References: <87pm16fnzv.fsf@iki.fi> <83zg09oa1v.fsf@gnu.org> <87a5s9m8ri.fsf@iki.fi> <83pm0q557b.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31330"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Petteri Hintsanen , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 04 09:22:29 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qzBvI-0007vG-5o for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Nov 2023 09:22:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qzBuT-0004KZ-3n; Sat, 04 Nov 2023 04:21:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qzBuP-0004KQ-Vk for emacs-devel@gnu.org; Sat, 04 Nov 2023 04:21:34 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qzBuO-0003R2-74; Sat, 04 Nov 2023 04:21:33 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D4074100068; Sat, 4 Nov 2023 04:21:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1699086085; bh=Iq5NShngZ6cQDCMVUegfvcbVom6vq4l4LqvZGHeaV/Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nIyuwORAx5dSWV9AWMHV6/w58yjYT46IPYwnZESrf76y/0WLEYhtsi/LJlT8ROU6x GGkW5rGN3xcrplHulaMox+jqF8YIAKXb+bONSjSGNijUwccrd+WSiTeEQoY1spm2TR 4SvBSg1ZUOhKfuvV6PyHmKaszwLyD+0HS3Dwfgu0ZkC9sT68ZhJfJDDHbT3oH/UZIM YtnmhdznShRWe0DE6lHfWj/SRahdyMBJry0A78Sc53wZxSCuCMz9J2NeeLdDtK7dcm r8lzvITYLPeNRmQUWwDRAGVBZ2Oewiv2CLfo/M6Qfwzn8CQufQ9iVuh4yzJs9xTqoB tRoAR+5z/zBtg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E35DE100043; Sat, 4 Nov 2023 04:21:25 -0400 (EDT) Original-Received: from pastel (unknown [45.72.195.71]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BA2151203C5; Sat, 4 Nov 2023 04:21:25 -0400 (EDT) In-Reply-To: <83pm0q557b.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 Nov 2023 09:48:56 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312192 Archived-At: >> But, again, users of Bindat can be expected to know that tainted data >> should be sanitized. And what is described above is an implementation >> detail. So it does not make much sense to mention this in the manual. > > Stefan, any comments? Hmm... I'm also tempted to say it's the programmer's fault, yet at the same time, it's BinDat which does the parsing so the programmer doesn't really have much opportunity to sanitize the data beforehand (short of doing a manual pre-parse which kind of defeats the purpose). With `bindat-type`, it's not too hard to insert ELisp code within the BinDat parsing, so it *can* be solved from there, but it's indeed not something that's been seriously considered so far. Kind of an embarrassing blind spot. BinDat should instead encourage the addition of sanity checks within the parsing code (including maybe add specific support for it). Stefan