From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC autolearn=no autolearn_force=no version=3.4.1 Date: Fri, 9 Nov 2018 10:58:48 +0100 From: Andreas Henriksson To: s3v , 913252@bugs.debian.org Message-ID: <20181109095848.ftitkgulmatrcfhw@fatal.se> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Mailman-Approved-At: Fri, 09 Nov 2018 13:10:34 +0300 Cc: Alexey Gladkov , kbd@lists.altlinux.org Subject: Re: [kbd] [Pkg-kbd-devel] Bug#913252: loadkeys: segmentation fault with a very long file name X-BeenThere: kbd@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Linux console tools development discussion List-Id: Linux console tools development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 09:58:54 -0000 Archived-At: List-Archive: Control: tags -1 upstream Hello s3v, Thanks for your bug report. On Thu, Nov 08, 2018 at 07:06:36PM +0100, s3v wrote: > Package: kbd > Version: 2.0.4-4 > Severity: important Why important? This seems mostly cosmetical to me so why not minor? > > Dear maintainer, > > loadkeys segfaults with a very long file name and if the "-b" or "-m" option > was specified: > > $ foo="0"; for i in {1..6000}; do foo="$foo$i"; done; loadkeys -b $foo > segmentation fault > > $ loadkeys -b $foo > segmentation fault This is caused by calls like these in src/libkeymap/findfile.c : strcpy(fp->pathname, filename); fp->pathname is MAXPATHLEN size and filenames are assumed to fit. (The oversized filename apparently corrupts argv here which causes a crash soon after the lk_findfile calls when argv is dereferenced.) This is done in atleast two places. Even with that fixed (with strncpy and null-terminating the string) there are followup bugs, like checking filename/fname rather than operating on fp->pathname. Possibly prepending a simple condition like this should prevent the entire mess: if (strlen(filename) >= MAXPATHLEN) return ERR; Given the situation I'm to lazy to propose a patch. Leaving it up to whoever decides about which way to go. Regards, Andreas Henriksson