Bug 259761 - graphics/exiftran: -g broken. May involve graphics/jpeg-turbo
Summary: graphics/exiftran: -g broken. May involve graphics/jpeg-turbo
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ports-bugs (Nobody)
URL: https://github.com/libjpeg-turbo/libj...
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-10 19:10 UTC by dgilbert
Modified: 2022-11-24 10:16 UTC (History)
4 users (show)

See Also:
fernape: maintainer-feedback? (mm)

Attachments
test file that reproduces. (9.57 KB, image/jpeg)
2021-11-10 19:10 UTC, dgilbert 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description dgilbert 2021-11-10 19:10:36 UTC 
Created attachment 229413 [details]
test file that reproduces.

Testing graphics/exiftran :

To be canonical and repeatable, I created a pnm image, then I ran pnmtojpeg and then and I ran "exiftran -g -o foo1.jpg foo.jpg"

This coredumps 100%.  The core dump indicates that a function in libjpeg that belongs to graphics/turbo-jpeg is where the core triggered.

I further ingnored the pkg and compiled both jpeg-turbo and exiftran.  I managed to get debug symbols into libjpeg ... which identified the function as jsimd_rgb_ycc_convert_avx2.columnloop(), but I'm not sure I trust that.
Comment 1 dgilbert 2021-11-10 19:12:01 UTC 
Test machine is a threadripper that says:

FreeBSD <hostname> 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #22 releng/13.0-n244760-940681634ee-dirty: Tue Aug 24 19:32:31 EDT 2021     root@<hostname>:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
Comment 2 Antoine Brodin freebsd_committer freebsd_triage 2021-11-10 19:43:51 UTC 
Can you reproduce the issue on another OS with similar CPU?

Can you report the bug to https://github.com/libjpeg-turbo/libjpeg-turbo/issues ?
Comment 3 dgilbert 2021-11-10 21:12:23 UTC 
This appears to be a freebsd-only issue.  It doesn't occur on linux-for-windows in my threadripper desktop.
Comment 4 dgilbert 2021-11-10 21:14:09 UTC 
My L4W is a kali derivitive.

uname -a

Linux HITWIN 5.10.60.1-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64 GNU/Linux
Comment 5 Alexey Dokuchaev freebsd_committer freebsd_triage 2022-11-24 10:16:06 UTC 
(In reply to dgilbert from comment #0)
> identified the function as jsimd_rgb_ycc_convert_avx2.columnloop(),
> but I'm not sure I trust that.
jsimd_rgb_ycc_convert_avx2[columnloop] to be precise, but it can be overridden by passing specific JSIMD_FORCE{MMX,SSE,SSE2,etc.} environment variable.  Let's disable SIMD altogether and see how it goes:

$ env JSIMD_FORCENONE=1 gdb %wrkdir%/fbida-2.14/build/exiftran/exiftran
$ r -g -o foo1.jpg foo.jpg
Program received signal SIGBUS, Bus error.
Object-specific hardware error.
0x00000008010d24b7 in rgb_ycc_convert_internal (cinfo=0x7fffffffe148, input_buf=0x801ac18c8, output_buf=0x801a5b750, output_row=1, num_rows=0) at %wrkdir%/libjpeg-turbo-2.1.4/jccolext.c:51
51            r = inptr[RGB_RED];
(gdb) p inptr
$1 = (JSAMPROW) 0x3b3b3939392b2b2b <error: Cannot access memory at address 0x3b3b3939392b2b2b>
(gdb)

Note that similar bug report had been filed at their GitHub (linked) and immediately closed as libjpeg's API is admittedly not very user-friendly or user-proof, and specially crafted image can crash it.  I'm not sure if/how should we pursue this from the FreeBSD side.