| Message ID | 20230620172305.4176-1-ckhardin@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/1] package/unzip: configure with LARGE_FILE_SUPPORT by default | expand |
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
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
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
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
>>>>> "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.
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))
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(+)