GNU bug report logs - #75924
maint: fix s390 buffer flushes

Previous Next

Full log

View this message in rfc822 format

From: Eduard Stefes <Eduard.Stefes <at> ibm.com>
To: "eggert <at> cs.ucla.edu" <eggert <at> cs.ucla.edu>
Cc: "75924 <at> debbugs.gnu.org" <75924 <at> debbugs.gnu.org>, "iii <at> linux.ibm.com" <iii <at> linux.ibm.com>, "andreas.hasenack <at> canonical.com" <andreas.hasenack <at> canonical.com>
Subject: bug#75924: maint: fix s390 buffer flushes
Date: Wed, 5 Feb 2025 15:46:15 +0000

On Wed, 2025-01-29 at 19:50 +0000, Eduard Stefes via GNU gzip
discussion and bug reports. wrote:
> Hi,
> 
> On Wed, 2025-01-29 at 10:58 -0800, Paul Eggert wrote:
> > Thanks for the bug report. I installed the attached, a bit simpler
> > than 
> > the patch you suggested; can you please give it a try?
> changing the call fill_inbuff(1) to fill_inbuff(0) will not work.
> dfltcc works on the outbuf, and fill_inbuff will eventually call
> flush_window in case it hits EOF && 0. But it will NOT call
> flush_outbuf() which we need in this case.
> 
> 
> 
> > 
> > Also, is there a related bug near dfltcc.c line 375? That is, when 
> > (inptr == insize && fill_inbuf (1) == EOF && param->cf), won't
> > insize
> > then be zero, so that gzip will go into an infinite loop attempting
> > to 
> > read past EOF?
> I will think about this and try to come up with a test for it. To me
> it
> looks like inbuf is preallocated (gzip.c:135) so it might be ok to
> read
> past EOF and just compress zeros. The logic around it should prevent
> access past inbuf[MAX]. But better be save then sorry.  

So I thought about this and talked with Ilya. We think that the only
possibility for a problem here, is if faulty hardware updates param->cf
incorrect. 

> 
> In that matter, should I extract the failing gzip tests from rsyslog
> and add them to the gzip test suit?

question remains: should I extract the failing rsyslog test cases for
gzip? This tests test if partially written or truncated gz files can be
extracted as expected.

I read rfc1952 and there is no explicit statement saying that
incomplete gz files *are corrupt or invalid*. Point 2.3.1.2. of the rfc
does not require the CRC32 and ISIZE field to be checked by a
decompressor. And Point 4. recommends that systems using gz should
*provide some means of validating the integrity of the compressed
data*. 

This all lets me conclude that it is indeed ok and valid to have
truncated gz files. And that it would be good to test this cases.


> 
> -- 
> Eduard Stefes <Eduard.Stefes <at> ibm.com>

-- 
Eduard Stefes <Eduard.Stefes <at> ibm.com>

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.