|
|
Message-ID: <20260123181143.GT1827@brightrain.aerifal.cx> Date: Fri, 23 Jan 2026 13:11:43 -0500 From: Rich Felker <dalias@...c.org> To: Richard Howe <rhowe425@...il.com> Cc: musl@...ts.openwall.com Subject: Re: denial-of-service issue in musl’s iconv implementation On Fri, Jan 23, 2026 at 10:17:51AM -0500, Richard Howe wrote: > Hello, > > I am reporting a denial-of-service issue in musl’s iconv implementation. > Summary > > A crafted input passed to iconv() can trigger an internal assertion failure > in gconv(): > > ../iconv/skeleton.c:745: gconv: Assertion `outbuf == outerr' failed > > This causes the process to abort, resulting in a denial of service. > Affected versions > > Tested on musl 1.2.5 (x86_64). > I have not tested earlier versions. > Impact > > This issue allows untrusted input to reliably crash processes using iconv(). > The failure occurs via an internal invariant violation and results in > abort(). > > When musl is rebuilt with assertions disabled (-DNDEBUG), the same input no > longer crashes and does not appear to cause memory corruption, indicating > this is a DoS issue rather than an RCE. > Reproduction > > The issue is reproducible using a simple harness that invokes iconv_open() > and iconv() on attacker‑controlled input. > > Steps: > > 1. > > Build musl normally (assertions enabled). > 2. > > Compile the attached harness against musl. > 3. > > Run the harness with the provided input file. > > The process aborts with the assertion above. > > I am happy to provide: > > - > > the minimal crashing input > - > > the reproduction harness > - > > additional debugging information if needed > > Thank you for your time. > > Best regards, > Richard Howe > > > [image: image.png] The attached png is clearly showing a backtrace of a glibc-linked program not a musl-linked one. Can you please clarify. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.