Fix function pointer signature mismatches - #30040
Contrib PR: https://github.com/opencv/opencv_contrib/pull/4224
Calling a function through a function pointer with a mismatched signature is undefined behavior in C/C++ and causes Clang Control Flow Integrity to trap with `SIGILL` (`ud1`) at indirect call sites.
This is a follow-up on https://github.com/opencv/opencv/pull/28939
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
imgcodecs: avoid copying PNG IDAT data during header parsing 🤖🤖🤖 - #29872
`PngDecoder::readHeader()` copies the first IDAT chunk into a temporary vector, discards it, then rewinds the input so libpng can read it again. A PNG stored in one large IDAT chunk therefore incurs an avoidable allocation and payload copy before decoding.
Skip materializing IDAT data during header discovery. For memory input, validate the remaining length and advance the cursor. For file input, seek to and read the final CRC byte to retain early rejection of truncated chunks. Keep buffered reads for small file chunks and when the seek offset cannot fit in `long`; libpng still validates IDAT CRC while decoding static PNGs. APNG frame decoding retains its existing chunk-reading path.
Validation against `52377dee533dbba170d6437a7cf6d42a749a3f8f`, with only this PNG patch applied:
- macOS 26.6.2 / Apple M5 Pro / Apple Clang 21: 579 image-codec cases, four default skips, zero failures; all four new perf smoke cases pass.
- Linux (Ubuntu 24.04.4) / Intel Core i7-6850K / GCC 13.3: the same 579 cases, four default skips, zero failures; all four new perf smoke cases pass.
- All 19 new regression cases also pass against the unchanged baseline libraries on both hosts.
- Matching Release settings within each host, bundled libpng 1.6.57 and zlib 1.3.2.
The revised, committed `PNGDecode` performance cases measure `imdecode(..., IMREAD_UNCHANGED)` on generated random, uncompressed RGB PNGs in memory. Seven alternating baseline/candidate pairs use 30 samples per case and one OpenCV thread; Linux runs are pinned to one CPU. The same revised performance executable is used with each library set, and actual loaded library paths are verified. These measurements are separate from the file-loading results below.
| Memory-decoding workload | Mac speedup | Linux speedup |
| --- | ---: | ---: |
| 512×512, ordinary chunks | 1.001× (0.999–1.003) | 0.999× (0.998–1.002) |
| 512×512, single IDAT | 1.024× (1.022–1.030) | 1.069× (1.067–1.070) |
| 3840×2160, ordinary chunks | 0.999× (0.995–1.011) | 1.001× (1.000–1.001) |
| 3840×2160, single IDAT | 1.022× (1.000–1.024) | 1.383× (1.356–1.419) |
Values are paired median speedups with descriptive bootstrap 95% intervals. Every process passed all four cases with exact pixel comparisons.
Separate C++ `imread(..., IMREAD_COLOR)` measurements use the earlier structured 3840×2160 RGB PNG fixtures, warm filesystem cache, one OpenCV thread, and seven alternating baseline/candidate pairs (minimum 0.15 seconds per batch). Linux runs are pinned to one CPU. Each host checks 100 image/mode cases; decoded dimensions, types, and pixel hashes match across every run and between hosts. The values below are paired median speedups, with bootstrap 95% intervals.
| Workload | Mac speedup | Linux speedup |
| --- | ---: | ---: |
| Uncompressed stream in one ~24.9 MB IDAT | 1.077× (1.046–1.110) | 1.171× (1.170–1.171) |
| Same uncompressed stream in ordinary IDAT chunks | 1.014× (0.945–1.025) | 1.000× (0.997–1.001) |
| Compressed stream in one IDAT | 1.014× (1.007–1.020) | 1.024× (1.021–1.025) |
The large-IDAT case has median latency 16.08→14.83 ms on the Mac and 37.23→31.90 ms on Linux. A separate 15-pair Mac check puts the ordinary chunked control at 1.002× (0.994–1.015). The gain depends on first-IDAT size and decoding cost; ordinary chunked PNGs are approximately neutral.
The new performance tests use the test framework’s `theRNG()` and time `imdecode(encoded, IMREAD_UNCHANGED)` entirely in memory. They generate identical uncompressed RGB images with ordinary 8 KiB IDAT chunks or a single full-image IDAT, at 512×512 and 3840×2160. Encoding and repacking happen outside the timed loop; the performance cases create no temporary files. Run the included cases with the following filters. For an A/B comparison, copy only the test/performance changes to the baseline tree:
```sh
opencv_test_imgcodecs --gtest_filter='*Png_ReadIDAT*'
opencv_perf_imgcodecs --gtest_filter='PNGDecode_idat_layout.idat_layout/*'
```
The regression tests exercise file and memory input, 8/16-bit grayscale/RGB/RGBA, single/multiple/empty-first IDAT layouts, incomplete headers/payloads/CRCs, and corrupt CRCs. They check `imread`, `imdecode`, and `imcount`. All fixtures are generated; no `opencv_extra` patch is needed. Windows was not tested locally.
### Pull Request Readiness Checklist
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on code under GPL or another license incompatible with OpenCV.
- [x] The PR is proposed to the proper branch (`5.x`, optimization).
- [x] Accuracy and performance tests are included; test data is generated.
- Original bug report: none; self-contained performance improvement.
- Documentation/sample changes: not applicable; no public API change.
feat: support boolean (CV_Bool) images in imwrite - #29407
## Summary
`imwrite` failed on `CV_Bool` (boolean) images because no encoder handles that depth. This normalizes a boolean image to `CV_8U` (mapping true to 255) before encoding, so boolean masks can be written directly instead of requiring a manual `convertTo` at every call site.
Adds round-trip tests covering boolean-image encoding.
Fixes#29365
AI was used for assistance.
The 16-bit icvCvt_* helpers in utils.cpp advance the row pointer with
step/sizeof(x[0]) - size.width*N at the end of each row. sizeof is size_t
(unsigned), so the whole subtraction is done in unsigned math and wraps to
a huge offset when the caller passes step == 0.
The TIFF tile decoder does exactly that: it walks rows itself and calls
these helpers with step = 0 and Size(width, 1), so decoding a 16-bit
4-channel TIFF forms an out of range pointer. UBSan reports it as an
unsigned offset overflow (issue #29615).
Cast sizeof(...) to int so the step math is signed. The result is the same
for valid multi-row calls and no longer overflows when step is 0.
Added Imgcodecs_Tiff.regression_29615_16UC4 which round-trips a CV_16UC4
TIFF in memory.
Replace "static inline" by "inline" in headers #29453
This fixes#29436
I also replaced CV_INLINE which can be removed in a later PR.
I can make a similar PR for 4.x if you want.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Follow-up to the recent "reject under-length raw exif profile" change.
The declared length in a PNG raw exif profile (tEXt/zTXt "Raw profile type
exif" chunk) is fully attacker controlled. The < 6 guard stops the underflow,
but a large positive value still passes it and reaches HexStringToBytes(),
which does raw_data.resize(expected_length) before reading anything. So a few
bytes in a text chunk can force a ~2GB allocation -> easy memory-amplification
DoS while decoding an otherwise small PNG.
The payload is hex encoded (two characters per byte), so a valid length can
never exceed the profile text carrying it. Reject any declared length greater
than profile_len. This bounds the allocation to the input size and doesn't
reject any valid profile; the valid decode path is unchanged.
imgcodecs(pam): fix out-of-bounds write when reading 2-channel PAM #29296
While poking at the PAM decoder I noticed basic_conversion() writes past the
end of the destination buffer when a GRAYSCALE_ALPHA (2 channel) image is read
with IMREAD_GRAYSCALE.
The 1-channel branch was written as if the destination had 3 channels:
for( ; s < end; d += 3, s += src_sampe_size )
d[0] = d[1] = d[2] = s[layout->graychan];
So for every source pixel it writes 3 bytes and advances d by 3, even though
the output row only has m_width bytes (1 channel). With m_channels == 2 that
ends up writing ~1.5 * m_width bytes per row, which runs off the row and, on
the last row, off the end of the Mat. m_width is taken straight from the file
header (up to 2^20), so the overflow size and contents are attacker controlled.
It's reachable with a plain imread(file, IMREAD_GRAYSCALE) on a crafted file.
While looking at it I also realised the loop bound was off for any multi
channel source: end was set to src + src_width, but the source has
src_width * channels samples, so it only ever processed m_width/channels pixels
instead of all of them. That's why GRAYSCALE_ALPHA / RGB_ALPHA come out only
partially filled.
Fix both at once:
- end now covers the whole row (src_width * src_sampe_size)
- the 1-channel branch writes one byte and advances d by 1
For the common grayscale->color case (channels == 1) the new end is identical
to the old one (m_width * 1 == m_width), so that path is byte for byte the same
and the existing PAM read_write test is unaffected. The only outputs that
change are the GRAYSCALE_ALPHA/RGB_ALPHA conversions, which were already broken.
Added a regression test (Imgcodecs_Pam.decode_graya_as_gray) that builds a small
2-channel PAM with an odd width, decodes it as grayscale and checks the result
matches the gray channel. It overflows/crashes on the old code and passes now.
imgcodecs: fix Apple conversions build without AVFoundation #29138Fixes#28553.
This PR fixes Apple imgcodecs conversion builds when AVFoundation is disabled or unavailable on older macOS SDKs.
Changes:
- Guard AVFoundation import with HAVE_AVFOUNDATION.
- Use older macOS-compatible framework imports when ImageIO is unavailable.
- Add __bridge compatibility for older Objective-C++ compilers.
- Use NSMakeSize for older macOS instead of passing CGSize to NSImage API.
Testing:
- Not tested locally: no macOS environment available.
- Patch follows the fix confirmed in #28555 discussion.
Casting the raw integer fields ras_type and maptype directly to their
respective enum types (SunRasType / SunRasMapType) without a prior range
check is undefined behavior under C++11 §7.2/8 when the stored value falls
outside the enum's valid range.
UBSan reports:
grfmt_sunras.cpp:72: runtime error: load of value 34077, which is not a
valid value for type 'SunRasMapType'
Fix: read both fields into plain ints first, validate them against the
declared enumerator bounds, and return false (reject the image) on any
out-of-range value before performing the enum cast. This is the cheapest
correct approach — two integer comparisons added to a path that was already
doing I/O — and ensures no downstream code ever sees an ill-formed enum
value.
Add test_sunraster.cpp with regression tests covering:
- The exact crash_001 payload (invalid maptype 34077 / 0x851d)
- Invalid ras_type values
- maptype = 2 and UINT_MAX (outside [0,1])
- Truncated header
- A valid 8-bpp grayscale image that must still decode correctly
Signed-off-by: FuzzAnything fuzzanything@gmail.com
Fix JPEG chroma configuration & Standardize component settings #28667
### Problem
Incorrectly treated Chroma as a single channel. In $YC_bC_r$, chroma must be set in both separate channels ($C_b$ and $C_r$).
### Fix
- Explicit Setup: Configured all three components ($Y$, $C_b$, $C_r$) individually.
- Standardization: Removed reliance on library defaults to prevent undefined behavior.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
imgcodecs(png): support cICP metadata for imreadWithMetadata() #28615
Close https://github.com/opencv/opencv/issues/28606
Related https://github.com/opencv/opencv/pull/27741 (support for imwriteWithMetadata)
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Allow TIFF compression schemes for 32F#28785
Related to [https://github.com/opencv/opencv/issues/28775](https://github.com/opencv/opencv/issues/28775)
Previously, only 32FC3+SGILOG could be specified for TIFF encoding. But when floats use quantization, compression schemes can be efficient even on 32F data. This PR will allow them.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [X] The PR is proposed to the proper branch
- [X] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [X] The feature is well documented and sample code can be built with the project CMake
I just don't know what kind of accuracy/performance tests should be added.
imgcodecs(webp): improve IMWRITE_WEBP_LOSSLESS_MODE to support exact lossless compression #28519Close#28503
Add IMWRITE_WEBP_LOSSLESS_MODE enum to control lossless strategy:
- IMWRITE_WEBP_LOSSLESS_OFF: Lossy compression.
- IMWRITE_WEBP_LOSSLESS_ON: Optimize/drop color in transparent pixels.
- IMWRITE_WEBP_LOSSLESS_PRESERVE_COLOR: Preserve color in transparent pixels.
Note: Currently limited to still images; animated WebP support is deferred per YAGNI.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
imgcodecs: fix integer overflow in BMP and SunRaster decoders #28379
### Pull Request Readiness Checklist
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Fixes#28350
### Description
This PR fixes integer overflow vulnerabilities in BMP and SunRaster image decoders that could cause heap buffer over-read when decoding malformed images.
### Root Cause
The `src_pitch` and `width3` calculations in `BmpDecoder::readData()` and `SunRasterDecoder::readData()` used `int` arithmetic:
```cpp
int src_pitch = ((m_width * m_bpp + 7) / 8 + 3) & -4;
int width3 = m_width * nch;
```
When `m_width` or `m_bpp` are large values from a crafted malicious file, the multiplication overflows, resulting in a small or negative value. This leads to insufficient buffer allocation, causing heap buffer over-read during subsequent decoding operations.
### Fix
1. **Use `size_t` arithmetic**: Cast operands to `size_t` before multiplication:
```cpp
const size_t bits_per_row = static_cast<size_t>(m_width) * static_cast<size_t>(m_bpp);
const size_t src_pitch_size = ((bits_per_row + 7) / 8 + 3) & ~static_cast<size_t>(3);
```
2. **Add size validation**: Added `CV_CheckLT` to reject images requiring buffers larger than 256MB:
```cpp
const size_t MAX_SRC_PITCH = static_cast<size_t>(1) << 28;
CV_CheckLT(src_pitch_size, MAX_SRC_PITCH, "BMP: src_pitch exceeds maximum allowed size");
```
3. **Safe conversion**: Use `validateToInt()` for safe conversion back to `int`.
### Files Changed
- `modules/imgcodecs/src/grfmt_bmp.cpp` - BmpDecoder::readData()
- `modules/imgcodecs/src/grfmt_sunras.cpp` - SunRasterDecoder::readData()
### Testing
- Code compiles without warnings
- Basic BMP and SunRaster encode/decode tests pass
- Overflow conditions are now properly rejected with CV_CheckLT
imgcodecs(avif): add safety checks for AVIF decoder and encoder #28200
Add defensive checks to prevent potential null dereference in AVIF decoder and encoder paths when handling malformed input or allocation failures.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Fixed issues identified by PVS Studio #28185
Partially fixes https://github.com/opencv/opencv/issues/28167
Paper: https://pvs-studio.com/en/blog/posts/cpp/1321/
Closed items: N2, N4, N5, N6, N7, N8, N10, N11, N13, N14.
To be continued...
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [ ] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
imgcodecs: Fix IMWRITE_AVIF_DEPTH typo and update AVIF details on imwrite() #28063
Close https://github.com/opencv/opencv/issues/28062
- Corrected the documentation for `IMWRITE_AVIF_DEPTH`.
- Added descriptions for the new AVIF encoder parameters in `imwrite()` documentation.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Fixes issue with libavif >= 1.3.0 where subsampling with identity matrix
coefficients is invalid. Aligns OpenCV AVIF writer with updated libavif
conformance rules.
core: add copyAt() for ROI operation #27318
Close https://github.com/opencv/opencv/issues/27320
Close https://github.com/opencv/opencv/issues/27298
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Fix alpha handling for blending in PNG format #27981
### Pull Request Readiness Checklist
closes#27974
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Fixed ptrdiff_t cast on windows 32-bit #27976
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Vincent Rabaud
Satya Mallick
Matt Van Horn
Sean McBride
Arnesh Banerjee
Alexander Smorkalov
anushkagupta200615-jpg
arshsmith
uwezkhan
Licardo_du
example
Jules
Kumataro
Pierre Chatelier
Murat Raimbekov
Alexander Smorkalov
Karnav Shah
Parth Parekh
Akash A
Suleyman TURKMEN