Opened 9 years ago
Closed 9 years ago
#9460 closed enhancement (fixed)
libjpeg-turbo-1.5.2
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Milestone: | 8.1 |
| Component: | BOOK | Version: | SVN |
| Severity: | medium | Keywords: | |
| Cc: |
Description
New point version.
Change History (3)
comment:1 by , 9 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 9 years ago
Note:
See TracTickets
for help on using tickets.

1.5.2 =====
### Significant changes relative to 1.5.1:
-nowriteswitch was accidentally enabled by default.)jpeg_skip_scanlines()andjpeg_crop_scanlines()functions were not being included in jpeg7.dll when libjpeg-turbo was built with-DWITH_JPEG7=1and-DWITH_MEMSRCDST=1.-copy allmust be passed to jpegtran in order to transfer the EXIF tags from the source image to the destination image.-O1and higher but not with GCC 5.x or 6.x) and one of the underlying libjpeg API functions threw an error after a TurboJPEG API function allocated a local buffer.max_memory_to_usestructure member in jpeg\_memory\_mgr, which can be set to the maximum amount of memory (in bytes) that libjpeg-turbo should use during decompression or multi-pass (including progressive) compression. This limit can also be set using theJPEGMEMenvironment variable or using the-maxmemoryswitch in cjpeg/djpeg/jpegtran (refer to the respective man pages for more details.) This has been a documented feature of libjpeg since v5, but themalloc()/free()implementation of the memory manager (jmemnobs.c) never implemented the feature. Restricting libjpeg-turbo's memory usage is useful for two reasons: it allows testers to more easily work around the 2 GB limit in libFuzzer, and it allows developers of security-sensitive applications to more easily defend against one of the progressive JPEG exploits (LJT-01-004) identified in [this report](http://www.libjpeg-turbo.org/pmwiki/uploads/About /TwoIssueswiththeJPEGStandard.pdf).-warmupoption is now used to specify the amount of warmup time rather than the number of warmup iterations.short jump is out of range) that occurred when assembling the 32-bit x86 SIMD extensions with NASM versions prior to 2.04. This was a regression introduced by 1.5 beta1[12].