View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000672 | file | General | public | 2025-06-30 12:51 | 2025-06-30 17:19 |
| Reporter | jukuisma | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | x86_64 | OS | AlmaLinux | OS Version | 9.6 |
| Product Version | 5.46 | ||||
| Summary | 0000672: Too small FILE_NAME_MAX definition | ||||
| Description | Images with a lot of XMP metadata produce errors. | ||||
| Steps To Reproduce | ``` $ ./src/file ~/valid_1.01_121_APP2_segments.jpg /home/vagrant/valid_1.01_121_APP2_segments.jpg: ERROR: JPEG image data, JFIF standard 1.01, resolution (DPI), density 16x15, segment length 16 name use count (100) exceeded $ echo $? 1 ``` | ||||
| Additional Information | We ran into this with images generated by photoshop. APP<n> segments have max length of 0xffff bytes and photoshop will keep adding as many segments as it needs to. The original images that produced this error had max 126 APP1 segments. We're patching our file build to use FILE_NAME_MAX 150 and can drop that patch if that or a higher value can be used upstream as well. I've attached a working patch done on top of the latest master and a test image that can be used to reproduce the bug. The test image has been generated from this file: https://github.com/Digital-Preservation-Finland/file-scraper/blob/539ab9a2ef883ece8e10376112ee16c2fa2bcf80/tests/data/image_jpeg/valid_1.01_icc_sRGB_profile.jpg with these commands: ``` $ cp valid_1.01_icc_sRGB_profile.jpg valid_1.01_121_APP2_segments.jpg $ r2 -w valid_1.01_121_APP2_segments.jpg [0x00000000]> /x ffe2 0x00000014 hit0_0 ffe2 [0x00000000]> s hit0_0 [0x00000014]> 120wx+ ffe200370000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 [0x00001acc]> wx+ ffe20062 [0x00001ad0]> 96wx+ 00 [0x00001ad0]> q ``` See: https://en.wikipedia.org/wiki/JPEG#Syntax_and_structure. `/x ffe2` searches existing APP2 segments. `s hit0_0` seeks to the one offset that was found. `120wx+ <hex>` writes 120 new APP2 segments. `ffe2` for APP2 and `0037` for the payload size. Finally, we write one more segment to fill all remaining space used by the old APP2 segment. | ||||
| Tags | No tags attached. | ||||
|
|
0001-Increase-FILE_NAME_MAX-to-150.patch (1,268 bytes)
From 0c9f9bb41c01de15e181871f90c3974b5e02884c Mon Sep 17 00:00:00 2001
From: Juho Kuisma <juho.kuisma@csc.fi>
Date: Mon, 30 Jun 2025 15:19:34 +0300
Subject: [PATCH] Increase FILE_NAME_MAX to 150
---
doc/file.man | 2 +-
src/file.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/file.man b/doc/file.man
index 9d2a7b89..c16302f8 100644
--- a/doc/file.man
+++ b/doc/file.man
@@ -348,7 +348,7 @@ Set various parameter limits.
.It Li elf_shsize Ta 128MB Ta max ELF section size processed
.It Li encoding Ta 65K Ta max number of bytes to determine encoding
.It Li indir Ta 50 Ta recursion limit for indirect magic
-.It Li name Ta 100 Ta use count limit for name/use magic
+.It Li name Ta 150 Ta use count limit for name/use magic
.It Li regex Ta 8K Ta length limit for regex searches
.El
.It Fl r , Fl Fl raw
diff --git a/src/file.h b/src/file.h
index 4f23c9d7..5ecd46cd 100644
--- a/src/file.h
+++ b/src/file.h
@@ -517,7 +517,7 @@ struct magic_set {
#define FILE_ELF_SHNUM_MAX 32768
#define FILE_ELF_SHSIZE_MAX (128 * 1024 * 1024)
#define FILE_INDIR_MAX 50
-#define FILE_NAME_MAX 100
+#define FILE_NAME_MAX 150
#define FILE_REGEX_MAX 8192
#define FILE_ENCODING_MAX (64 * 1024)
#define FILE_MAGWARN_MAX 64
--
2.43.0
|
|
|
You didn't mention the "--parameter name=150" command-line option. Regardless of whether it helps, it should be part of the discussion. |
