View Issue Details

IDProjectCategoryView StatusLast Update
0000152file[All Projects] Generalpublic2020-03-21 16:49
ReporterpabsAssigned Tochristos 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionreopened 
PlatformLinuxOSDebianOS Version11 (bullseye)
Product Version5.38 
Target VersionFixed in Version5.39 
Summary0000152: JPEG header detection: name use count (30) exceeded
DescriptionSome JPEG files are successfully detected, including most headers but get an error "name use count (30) exceeded".

The workaround for this issue is to either increase the name parameter or decrease the bytes parameter.

In one test image, the extra info printed after the workaround is applied is "baseline, precision 8, 2335x1831, components 3".

The error appears to occur after the Exif data is printed.

As far as I can tell the error was caused by the change "use recursion to traverse the jpeg markers" to magic/Magdir/jpeg:

# $File: jpeg,v 1.20 2014/08/05 07:32:31 christos Exp $

Here is the commit in the git mirror of CVS:

https://github.com/file/file/commit/52400a1cf98e4cc252920239c291c66648c8fb3d

For some reason this problem was masked before HOWMANY/FILE_BYTES_MAX were set to 1024*1024 in this change to src/file.h:

+ * @(#)$File: file.h,v 1.166 2015/01/09 19:28:32 christos Exp $

Here is the commit in the git mirror of CVS:

https://github.com/file/file/commit/dd89d293fe62ca55542a5637e239b33404c58a8d
Steps To Reproduce$ wget -q https://bugs.launchpad.net/ubuntu/+source/file/+bug/1717991/+attachment/4952354/+files/test.jpg
$ file test.jpg
$ file --parameter name=40 test.jpg
$ file --parameter bytes=857393 test.jpg
Additional InformationThis issue has previously been reported to Debian, Ubuntu and Fedora:

https://bugs.debian.org/928009
https://bugzilla.redhat.com/show_bug.cgi?id=1201630
https://bugs.launchpad.net/ubuntu/+source/file/+bug/1717991
Tagsrecursion

Activities

christos

2020-03-20 16:06

manager   ~0003394

Bumped from 30 to 50

pabs

2020-03-21 00:41

reporter   ~0003400

Bumping the default recursion level seems like a workaround, is there no way to fix this without doing that?

christos

2020-03-21 02:30

manager   ~0003401

We could allow infinite recursion, but then one could construct malicious files that would either never terminate, or terminate after consuming a very large amount of resources.

christos

2020-03-21 02:31

manager   ~0003402

This solution (bumping the recursion level) allows us to handle most regular files without risking a DoS attack.

pabs

2020-03-21 02:36

reporter   ~0003403

I see, thanks for the extra information. I guess the issue can be closed again.

pabs

2020-03-21 02:56

reporter   ~0003404

FTR, this was fixed in this change:

 * @(#)$File: file.h,v 1.214 2020/03/19 20:41:11 christos Exp $

Here is the commit in the git mirror of CVS:

https://github.com/file/file/commit/df476c81d3e4171ec5d68fb259108ba875ae2caa

Issue History

Date Modified Username Field Change
2020-03-14 06:25 pabs New Issue
2020-03-14 06:25 pabs Tag Attached: recursion
2020-03-20 16:05 christos Assigned To => christos
2020-03-20 16:05 christos Status new => assigned
2020-03-20 16:06 christos Status assigned => resolved
2020-03-20 16:06 christos Resolution open => fixed
2020-03-20 16:06 christos Fixed in Version => 5.39
2020-03-20 16:06 christos Note Added: 0003394
2020-03-21 00:41 pabs Status resolved => feedback
2020-03-21 00:41 pabs Resolution fixed => reopened
2020-03-21 00:41 pabs Note Added: 0003400
2020-03-21 02:30 christos Note Added: 0003401
2020-03-21 02:31 christos Note Added: 0003402
2020-03-21 02:36 pabs Note Added: 0003403
2020-03-21 02:36 pabs Status feedback => assigned
2020-03-21 02:56 pabs Note Added: 0003404
2020-03-21 16:49 christos Status assigned => resolved