This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of fedora-all. For comments that are specific to the vulnerability please use bugs filed against the "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When submitting as an update, use the fedpkg template provided in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the fedpkg commit message. NOTE: this issue affects multiple supported versions of Fedora. While only one tracking bug has been filed, please correct all affected versions at the same time. If you need to fix the versions independent of each other, you may clone this bug as appropriate.
Use the following template to for the 'fedpkg update' request to submit an update for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. ===== # bugfix, security, enhancement, newpackage (required) type=security # low, medium, high, urgent (required) severity=medium # testing, stable request=testing # Bug numbers: 1234,9876 bugs=1968040,2019614 # Description of your update notes=Security fix for [PUT CVEs HERE] # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False ====== Additionally, you may opt to use the bodhi web interface to submit updates: https://bodhi.fedoraproject.org/updates/new
The foveon_load_camf doesn't seem to exist in LibRaw-0.20.2, that's currently shipping in RHEL 9. Neither in the upstream LibRaw-0.20.2 tarball, nor in the 0.20-stable Git branch. I am mentioning this because I am not sure exactly how the dcraw source code is used in LibRaw these days. https://github.com/LibRaw/LibRaw/blob/0.20-stable/Changelog.txt says: " == Camera Format support == ... ... Foveon X3F support changed: it is supported only if USE_X3FTOOLS defined at build (see below for 'Imported code policy changed') ... ... == Source code re-arranged == * dcraw.c is not used in the generation and build processes * dcraw_common.cpp and libraw_cxx.cpp are split into multiple code chunks placed in separate subfolders (decoders/ for raw data decoders, metadata/ for metadata parsers, etc) * dcraw_common.cpp and libraw_cxx.cpp remain to preserve existing build environments (these files are now just a bunch of #include directives). ... ... == Imported code policy disclaimer == We've changed the policy regarding 3rd party code imported into LibRaw. We (like other authors of open-source RAW parsers) gladly import support code for various RAW formats from other projects (if the license allows it). This is done to expand camera support. Unfortunately, not all imported code can tolerate truncated or otherwise damaged raw files, as well as arbitrary conditions or arbitrary data; not all authors handle rejecting unexpected input well. LibRaw is now widely used in various projects, including ImageMagick, which, in turn, is often used on web sites to process any input images, including arbitrary data from unknown users. This opens up wide possibilities for exploiting the various vulnerabilities present in the code borrowed from other projects into LibRaw. In order to avoid such security risks, - the borrowed code will no longer compile by default. We are not able to support it in general case, and the authors refuse to add code to reject unexpected input. Thus, if you use some kind of camera for which the support is disabled by default, you need to recompile LibRaw for your specific case. Formats currently affected: X3F (Foveon) file format. Code is imported from Kalpanika X3F tools: https://github.com/Kalpanika/x3f To turn the support on, define USE_X3FTOOLS ... ... " And, indeed, it looks like: (a) dcraw/dcraw.c was removed during the development of the 0.20.x series: https://github.com/LibRaw/LibRaw/commit/d1975cb0e055d2bfe58c9d845c9a3e57c346a2f9 (LibRaw has an odd development model where the main thrust of the development happens behind closed doors, and gets periodically force-pushed to the master branch, until the point-0 release of a new series comes out.) (b) I don't see USE_X3FTOOLS anywhere in the build logs. So, I am inclined to conclude that this CVE doesn't affect the LibRaw build that's in RHEL 9.
Email response from Alex Tutubalin <lexa> who is part of the upstream LibRaw team: "Dave Coffin's foveon-related code was moved to LibRaw-demosaic-pack-GPL2 in 2013. So, standard LibRaw versions (if built without this 'demosaic pack') are definitely not affected by this bug since 2013. Demosaic pack support was completely dropped in LibRaw 0.19, so versions 0.19, 0.20 and current public snapshot(s) are completely unaffected by foveon_load_camf() bugs regardless of build configuration used. LibRaw uses x3f-tools source code (https://github.com/Kalpanika/x3f ) to process foveon files. In LibRaw 0.20 (and later) this code is NOT compiled by default (so, there is no default-enabled support for Foveon files)"