View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000152 | file | General | public | 2020-03-14 06:25 | 2020-03-21 16:49 |
| Reporter | pabs | Assigned To | christos | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | reopened | ||
| Platform | Linux | OS | Debian | OS Version | 11 (bullseye) |
| Product Version | 5.38 | ||||
| Fixed in Version | 5.39 | ||||
| Summary | 0000152: JPEG header detection: name use count (30) exceeded | ||||
| Description | Some 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 Information | This 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 | ||||
| Tags | recursion | ||||
|
|
Bumped from 30 to 50 |
|
|
Bumping the default recursion level seems like a workaround, is there no way to fix this without doing that? |
|
|
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. |
|
|
This solution (bumping the recursion level) allows us to handle most regular files without risking a DoS attack. |
|
|
I see, thanks for the extra information. I guess the issue can be closed again. |
|
|
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 |
| 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 |
