buildroot.busybox.net archive mirror
 help / color / mirror / Atom feed
* [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default
@ 2023-06-20 17:23 Charles Hardin
  2023-06-26 11:17 ` Luca Ceresoli via buildroot
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Charles Hardin @ 2023-06-20 17:23 UTC (permalink / raw)
  To: buildroot; +Cc: Charles Hardin, Luca Ceresoli

Buildroot always enable largefile support in the toolchains, and
thus the associated definitions are always on. This leads to a
problem in the unzip that on a 32-bit arch with these flags being
passed in

   -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

But, the LARGE_FILE_SUPPORT not being defined will cause a size
mismatch on the comparison of the zipfiles.

    $ unzip test.zip
    Archive: test.zip
    error: invalid zip file with overlapped components (possible zip bomb)

Simple solution is just enable LARGE_FILE_SUPPORT in cmake to get
an expected extraction.

Signed-off-by: Charles Hardin <ckhardin@gmail.com>
---
 package/unzip/unzip.mk | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/package/unzip/unzip.mk b/package/unzip/unzip.mk
index 44cc2013fb..14ccedd48f 100644
--- a/package/unzip/unzip.mk
+++ b/package/unzip/unzip.mk
@@ -28,4 +28,18 @@ UNZIP_IGNORE_CVES = \
 	CVE-2022-0529 \
 	CVE-2022-0530
 
+# unzip already defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE when
+# necessary, redefining it on the command line causes some warnings.
+UNZIP_TARGET_CFLAGS = \
+	$(filter-out -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE,$(TARGET_CFLAGS))
+
+# unzip already defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE when
+# necessary, redefining it on the command line causes some warnings.
+UNZIP_TARGET_CXXFLAGS = \
+	$(filter-out -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE,$(TARGET_CXXFLAGS))
+
+UNZIP_CONF_OPTS += \
+	-DCMAKE_C_FLAGS="$(UNZIP_TARGET_CFLAGS) -DLARGE_FILE_SUPPORT" \
+	-DCMAKE_CXX_FLAGS="$(UNZIP_TARGET_CXXFLAGS) -DLARGE_FILE_SUPPORT"
+
 $(eval $(cmake-package))
-- 
2.39.2 (Apple Git-143)

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default
  2023-06-20 17:23 [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default Charles Hardin
@ 2023-06-26 11:17 ` Luca Ceresoli via buildroot
  2023-07-10 20:01   ` Thomas Petazzoni via buildroot
  2023-07-10 20:00 ` Thomas Petazzoni via buildroot
  2023-08-25 12:56 ` Peter Korsgaard
  2 siblings, 1 reply; 6+ messages in thread
From: Luca Ceresoli via buildroot @ 2023-06-26 11:17 UTC (permalink / raw)
  To: Charles Hardin; +Cc: buildroot

Hello Charles,

On Tue, 20 Jun 2023 10:23:05 -0700
Charles Hardin <ckhardin@gmail.com> wrote:

> Buildroot always enable largefile support in the toolchains, and
> thus the associated definitions are always on. This leads to a
> problem in the unzip that on a 32-bit arch with these flags being
> passed in
> 
>    -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> 
> But, the LARGE_FILE_SUPPORT not being defined will cause a size
> mismatch on the comparison of the zipfiles.
> 
>     $ unzip test.zip
>     Archive: test.zip
>     error: invalid zip file with overlapped components (possible zip bomb)
> 
> Simple solution is just enable LARGE_FILE_SUPPORT in cmake to get
> an expected extraction.
> 
> Signed-off-by: Charles Hardin <ckhardin@gmail.com>

I verified that the problem exists using qemu_arm_versatile_defconfig
and that extraction works after applying the patch.

Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

Thanks for the fix!

However I have a note, see below.

> ---
>  package/unzip/unzip.mk | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/package/unzip/unzip.mk b/package/unzip/unzip.mk
> index 44cc2013fb..14ccedd48f 100644
> --- a/package/unzip/unzip.mk
> +++ b/package/unzip/unzip.mk
> @@ -28,4 +28,18 @@ UNZIP_IGNORE_CVES = \
>  	CVE-2022-0529 \
>  	CVE-2022-0530
>  
> +# unzip already defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE when
> +# necessary, redefining it on the command line causes some warnings.

"causes some warnings" -> "causes extraction errors"?

> +UNZIP_TARGET_CFLAGS = \
> +	$(filter-out -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE,$(TARGET_CFLAGS))
> +
> +# unzip already defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE when
> +# necessary, redefining it on the command line causes some warnings.

As above.

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default
  2023-06-20 17:23 [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default Charles Hardin
  2023-06-26 11:17 ` Luca Ceresoli via buildroot
@ 2023-07-10 20:00 ` Thomas Petazzoni via buildroot
  2023-08-25 12:56 ` Peter Korsgaard
  2 siblings, 0 replies; 6+ messages in thread
From: Thomas Petazzoni via buildroot @ 2023-07-10 20:00 UTC (permalink / raw)
  To: Charles Hardin; +Cc: Luca Ceresoli, buildroot

On Tue, 20 Jun 2023 10:23:05 -0700
Charles Hardin <ckhardin@gmail.com> wrote:

> Buildroot always enable largefile support in the toolchains, and
> thus the associated definitions are always on. This leads to a
> problem in the unzip that on a 32-bit arch with these flags being
> passed in
> 
>    -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> 
> But, the LARGE_FILE_SUPPORT not being defined will cause a size
> mismatch on the comparison of the zipfiles.
> 
>     $ unzip test.zip
>     Archive: test.zip
>     error: invalid zip file with overlapped components (possible zip bomb)
> 
> Simple solution is just enable LARGE_FILE_SUPPORT in cmake to get
> an expected extraction.
> 
> Signed-off-by: Charles Hardin <ckhardin@gmail.com>
> ---
>  package/unzip/unzip.mk | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)

I slightly improved the commit log and applied. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default
  2023-06-26 11:17 ` Luca Ceresoli via buildroot
@ 2023-07-10 20:01   ` Thomas Petazzoni via buildroot
  2023-07-17  7:54     ` Luca Ceresoli via buildroot
  0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni via buildroot @ 2023-07-10 20:01 UTC (permalink / raw)
  To: Luca Ceresoli via buildroot; +Cc: Charles Hardin, Luca Ceresoli

Hello Luca,

On Mon, 26 Jun 2023 13:17:14 +0200
Luca Ceresoli via buildroot <buildroot@buildroot.org> wrote:

> > +# unzip already defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE when
> > +# necessary, redefining it on the command line causes some warnings.  
> 
> "causes some warnings" -> "causes extraction errors"?

Actually no, the comment was correct. What causes the extraction error
is the large of -DLARGE_FILE_SUPPORT (which is a unzip specific thing).

The thing is that when -DLARGE_FILE_SUPPORT is passed, the unzip build
system defines on its own _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE,
which causes a redefinition warning by gcc. So undefining
_LARGEFILE_SOURCE and _LARGEFILE64_SOURCE does not solve the extraction
error: it only avoids the redefinition warning from gcc.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default
  2023-07-10 20:01   ` Thomas Petazzoni via buildroot
@ 2023-07-17  7:54     ` Luca Ceresoli via buildroot
  0 siblings, 0 replies; 6+ messages in thread
From: Luca Ceresoli via buildroot @ 2023-07-17  7:54 UTC (permalink / raw)
  To: Thomas Petazzoni; +Cc: Charles Hardin, Luca Ceresoli via buildroot

Hello Thomas, Charles,

On Mon, 10 Jul 2023 22:01:54 +0200
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:

> Hello Luca,
> 
> On Mon, 26 Jun 2023 13:17:14 +0200
> Luca Ceresoli via buildroot <buildroot@buildroot.org> wrote:
> 
> > > +# unzip already defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE when
> > > +# necessary, redefining it on the command line causes some warnings.    
> > 
> > "causes some warnings" -> "causes extraction errors"?  
> 
> Actually no, the comment was correct. What causes the extraction error
> is the large of -DLARGE_FILE_SUPPORT (which is a unzip specific thing).
> 
> The thing is that when -DLARGE_FILE_SUPPORT is passed, the unzip build
> system defines on its own _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE,
> which causes a redefinition warning by gcc. So undefining
> _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE does not solve the extraction
> error: it only avoids the redefinition warning from gcc.

Indeed! Thanks for clarifying.

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default
  2023-06-20 17:23 [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default Charles Hardin
  2023-06-26 11:17 ` Luca Ceresoli via buildroot
  2023-07-10 20:00 ` Thomas Petazzoni via buildroot
@ 2023-08-25 12:56 ` Peter Korsgaard
  2 siblings, 0 replies; 6+ messages in thread
From: Peter Korsgaard @ 2023-08-25 12:56 UTC (permalink / raw)
  To: Charles Hardin; +Cc: Luca Ceresoli, buildroot

>>>>> "Charles" == Charles Hardin <ckhardin@gmail.com> writes:

 > Buildroot always enable largefile support in the toolchains, and
 > thus the associated definitions are always on. This leads to a
 > problem in the unzip that on a 32-bit arch with these flags being
 > passed in

 >    -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

 > But, the LARGE_FILE_SUPPORT not being defined will cause a size
 > mismatch on the comparison of the zipfiles.

 >     $ unzip test.zip
 >     Archive: test.zip
 >     error: invalid zip file with overlapped components (possible zip bomb)

 > Simple solution is just enable LARGE_FILE_SUPPORT in cmake to get
 > an expected extraction.

 > Signed-off-by: Charles Hardin <ckhardin@gmail.com>

Committed to 2023.02.x and 2023.05.x, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-08-25 12:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-20 17:23 [Buildroot] [PATCH 1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default Charles Hardin
2023-06-26 11:17 ` Luca Ceresoli via buildroot
2023-07-10 20:01   ` Thomas Petazzoni via buildroot
2023-07-17  7:54     ` Luca Ceresoli via buildroot
2023-07-10 20:00 ` Thomas Petazzoni via buildroot
2023-08-25 12:56 ` Peter Korsgaard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).