From: Andreas Henriksson <andreas@fatal.se> To: s3v <c0llapsed@yahoo.it>, 913252@bugs.debian.org Cc: Alexey Gladkov <gladkov.alexey@gmail.com>, kbd@lists.altlinux.org Subject: Re: [kbd] [Pkg-kbd-devel] Bug#913252: loadkeys: segmentation fault with a very long file name Date: Fri, 9 Nov 2018 10:58:48 +0100 Message-ID: <20181109095848.ftitkgulmatrcfhw@fatal.se> (raw) In-Reply-To: <ebae7312-f533-c181-4202-07d56640c35f@yahoo.it> 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
parent reply other threads:[~2018-11-09 9:58 UTC|newest] Thread overview: expand[flat|nested] mbox.gz Atom feed [parent not found: <ebae7312-f533-c181-4202-07d56640c35f@yahoo.it>]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181109095848.ftitkgulmatrcfhw@fatal.se \ --to=andreas@fatal.se \ --cc=913252@bugs.debian.org \ --cc=c0llapsed@yahoo.it \ --cc=gladkov.alexey@gmail.com \ --cc=kbd@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux console tools development discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/kbd/0 kbd/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 kbd kbd/ http://lore.altlinux.org/kbd \ kbd@lists.altlinux.org kbd@lists.altlinux.ru kbd@lists.altlinux.com public-inbox-index kbd Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.kbd AGPL code for this site: git clone https://public-inbox.org/public-inbox.git