Suggested advisory:
========================

The updated packages fix a security vulnerability:

A segment fault (SEGV) flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFReadRGBATileExt() API. This flaw allows a remote attacker to cause a heap-buffer overflow, leading to a denial of service. (CVE-2023-52356)

References:
https://lwn.net/Articles/965011/
========================

Updated packages in core/updates_testing:
========================
lib(64)tiff6-4.5.1-1.1.mga9
lib(64)tiff-devel-4.5.1-1.1.mga9
lib(64)tiff-static-devel-4.5.1-1.1.mga9
libtiff-progs-4.5.1-1.1.mga9

from SRPM:
libtiff-4.5.1-1.1.mga9.src.rpm

Assignee: nicolas.salguero => qa-bugs
Source RPM: libtiff-4.6.0-1.mga10.src.rpm => libtiff-4.5.1-1.mga9.src.rpm
Whiteboard: MGA9TOO => (none)
Status: NEW => ASSIGNED
Version: Cauldron => 9

mga9, x64
No path to a PoC from the link under references.

Updated all the packages.
Nothing to do but exercise the utilities as in previous bugs.

$ tiffgt Shiel.tif
to display an image.

No layered tiff image available but plain image was processed properly.
$ tiffsplit x.tiff p
$ ll pa*.tif
-rw-r--r-- 1 lcl lcl 128244 Mar 11 18:04 paaa.tif

$ tifftopnm einstein.tif > albert.pnm
tifftopnm: writing PGM file
$ display albert.pnm
Exact copy.

$ tiffcrop -E top -U px -m 120,120,120,120 SantaMaria.tif cropped.tif
_TIFFVGetField: cropped.tif: Invalid tag "BadFaxLines" (not supported by codec).
_TIFFVGetField: cropped.tif: Invalid tag "BadFaxLines" (not supported by codec).
Nevertheless the resulting image was displayed with a 120-pixel border missing.
$ file SantaMaria.tif 
SantaMaria.tif: TIFF image data, little-endian, direntries=21, height=1410, bps=5210, compression=LZW, PhotometricInterpretation=RGB, description=IDL TIFF file, orientation=upper-left, width=1638
$ file cropped.tif
cropped.tif: TIFF image data, little-endian, direntries=21, height=1170, bps=22414, compression=LZW, PhotometricInterpretation=RGB, description=IDL TIFF file, orientation=upper-left, width=1398

$ tiff2bw JessicaAlba.tif monochrome.tif
$ eom monochrome.tif
Greyscale rendering of colour image was displayed.

$ tiff2pdf SantaMaria.tif > crater.pdf
$ okular crater.pdf
That displayed the imagein a one-page PDF.

$ tiff2ps SantaMaria.tif > crater.ps
$ gs crater.ps
Ghostscript image of the original, displayed at a reduced size in the bottom left-hand corner of the page.

$ tiffdump SantaMaria.tif > dumpfile
$ less dumpfile
SantaMaria.tif:
Magic: 0x4949 <little-endian> Version: 0x2a <ClassicTIFF>
Directory 0: offset 1971016 (0x1e1348) next 0 (0)
ImageWidth (256) SHORT (3) 1<1638>
ImageLength (257) SHORT (3) 1<1410>
BitsPerSample (258) SHORT (3) 3<8 8 8>
Compression (259) SHORT (3) 1<5>
Photometric (262) SHORT (3) 1<2>
FillOrder (266) SHORT (3) 1<1>
[...]
PrimaryChromaticities (319) RATIONAL (5) 6<0.64 0.33 0.3 0.6 0.15 0.06>
BadFaxLines (326) LONG (4) 1<2707030018>

No regressions noted.  Advisory to follow.

CC: (none) => tarazed25
Whiteboard: (none) => MGA9-64-OK

(In reply to Len Lawrence from comment #2)
> No regressions noted.  Advisory to follow.
Sorry Len, I not see you already on t, is uploaded

Thanks katnatek, my fault; I should have checked.

Validating.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

Created attachment 14450 [details]
nomacs test with strace

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2024-0055.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Dan Fandrich
Today the adv file for this bug was marked as deleted from svn , is a mistake?

This change is the culprit:
------------------------------------------------------------------------
r15903 | tarazed | 2024-03-19 10:01:01 -0700 (Tue, 19 Mar 2024) | 1 line
Changed paths:
   A /32944.adv
   D /32959.adv

(In reply to Dan Fandrich from comment #9)
> This change is the culprit:
> ------------------------------------------------------------------------
> r15903 | tarazed | 2024-03-19 10:01:01 -0700 (Tue, 19 Mar 2024) | 1 line
> Changed paths:
>    A /32944.adv
>    D /32959.adv

Must I add again, or you can do it?

I'm pretty sure you can do it.

Done, I hope I do it right, I follow https://wiki.mageia.org/en/How_to_create_an_update_advisory#Adding_old_advisories

https://svnweb.mageia.org/advisories/32959.adv

Sorry katnatek.  I was adding an advisory for another bug and was told that that older advisory (remember we clashed) had to be removed.  I assumed (!) that meant the copy in my advisories directory, so I agreed to 'r'.  I am still confused about what to do in such cases.  I don't know what the correct response would have been.  The one at my end that I thought had been replaced by your version is actually the skeleton from the documentation and I do not know how that appeared because I use mga-advisor.

(In reply to Len Lawrence from comment #13)
> Sorry katnatek.  I was adding an advisory for another bug and was told that
> that older advisory (remember we clashed) had to be removed.  I assumed (!)
> that meant the copy in my advisories directory, so I agreed to 'r'.  I am
> still confused about what to do in such cases.  I don't know what the
> correct response would have been.  The one at my end that I thought had been
> replaced by your version is actually the skeleton from the documentation and
> I do not know how that appeared because I use mga-advisor.

When I did have this I prefer lost some of my work, from ~/mageia-advisories

I rm -rf advisories

svn co svn+ssh://svn.mageia.org/svn/advisories

cd advisories

And not is necessary but for be extra sure

svn up

Then redo my advisory and apply the steps to upload

I not make this kind of mistake recently but a few times when I start with this
I'm some rusted with svn, I remember is a way of undo this kind of situations, but I decide just re-upload , I have some fun in Mandriva times with this and once I did have to ask Romain D Alverny to come to rescue :/