From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Petteri Hintsanen Newsgroups: gmane.emacs.devel Subject: Re: Bindat can exhaust memory when unpacking to vector Date: Tue, 19 Mar 2024 22:09:44 +0200 Message-ID: <87a5mukmpj.fsf@iki.fi> 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="26340"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 19 21:11:15 2024 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 1rmfnn-0006hh-As for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Mar 2024 21:11:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rmfmd-0004xf-4X; Tue, 19 Mar 2024 16:10:03 -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 1rmfmb-0004xV-KW for emacs-devel@gnu.org; Tue, 19 Mar 2024 16:10:01 -0400 Original-Received: from sypressi2.dnainternet.net ([83.102.40.154]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmfmX-0005hR-1j for emacs-devel@gnu.org; Tue, 19 Mar 2024 16:10:01 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by sypressi2.dnainternet.net (Postfix) with ESMTP id D224210DC4 for ; Tue, 19 Mar 2024 22:09:45 +0200 (EET) X-Virus-Scanned: DNA Internet at dnainternet.net Original-Received: from sypressi2.dnainternet.net ([83.102.40.154]) by localhost (sypressi2.dnainternet.net [127.0.0.1]) (DNA Internet, port 10041) with ESMTP id O4SiAYrjf5Dw for ; Tue, 19 Mar 2024 22:09:45 +0200 (EET) Original-Received: from luumupuu2.dnainternet.net (luumupuu2.dnainternet.net [83.102.40.55]) by sypressi2.dnainternet.net (Postfix) with ESMTP id 7567510465 for ; Tue, 19 Mar 2024 22:09:45 +0200 (EET) Original-Received: from julia (62-78-178-196.bb.dnainternet.fi [62.78.178.196]) by luumupuu2.dnainternet.net (Postfix) with ESMTP id 57F772C76 for ; Tue, 19 Mar 2024 22:09:44 +0200 (EET) Original-Received: from phintsan (uid 1000) (envelope-from petterih@iki.fi) id 179 by julia (DragonFly Mail Agent v0.13); Tue, 19 Mar 2024 22:09:44 +0200 In-Reply-To: (Stefan Monnier's message of "Sun, 10 Mar 2024 17:58:14 -0400") Received-SPF: neutral client-ip=83.102.40.154; envelope-from=petterih@iki.fi; helo=sypressi2.dnainternet.net X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001 autolearn=unavailable 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:317200 Archived-At: Stefan Monnier writes: >> (defconst foo-bindat-spec >> (bindat-type >> (length uint 32) >> (_ unit (when (> length 1234) (error "malicious input"))) >> (data vec length))) >> >> Which is somewhat messy, but it works. > > You should also be able to do > > (defconst foo-bindat-spec > (bindat-type > (length uint 32) > (data vec (if (< length 1234) length (error "malicious input"))))) > > as well. But it's still not very elegant. Ah sure, right. This is nice I think. > (defconst foo-bindat-spec > (bindat-type > (length uint 32) > (data vec (bounded 1 length 1234)))) > > so we signal an error if the length is less than 1 or larger than 1234. Sure. But I'm not sure which kind of helpers would be the most beneficial for general use. Like said, I don't have that many examples, and for my few validation cases I have found the "unit type" to be good enough. >> I also played around with the idea of patching bindat.el itself to do >> trivial checking against the input data size, like this: >> [...] > Actually, this is a nice solution, I think. > It seems hypothetical enough that I think we should go with your patch. Feel free to apply it in whatever form you want, if you think it is appropriate. >> Checking should be optional and somehow programmable, perhaps >> a separate "checked vec" type? (I don't have any good, concrete >> ideas, sorry.) > > I don't see the benefit of not-checking, to be honest. I probably thought about efficiency here. If bindat-unpack is hammered many many many times and the checking could be _safely_ ignored, then, perhaps, there might be a noticeable difference in performance. Or maybe not. Thanks, Petteri