The image rendering component of Signal on IOS  (createGenericPreview)  fails to check for  unreasonably large images before manipulating received images. This allows for a large image sent to a user to exhaust all available memory when the image is displayed resulting in a forced restart of the device. 


When Signal receives an image and it is viewed, the image display function createGenericPreview is called which subsequently calls createHeroImageView on the image which adds shadows to the original image and downscales it. Because of this, any image sent to a client will be loaded into memory in full without checking if Signal or the device on which it is running have enough memory to hold said image. Given a sufficiently large image an attacker can cause memory exhaustion. In Signal, an attacker is able to send arbitrarily large images to a user so long as the image is below the file size limit Signal sets for images of several Mb.  Generally, an image large enough to trigger memory exhaustion in this way would be too large to send however many image formats have built-in image compression for nearby pixels of the same color. In images with little variety of color this sort of compression results in a massive delta (many orders of magnitude) between the size of an image on disk and
  the size of an image when loaded into memory. Thus, by sending a large single color image an attacker may remotely crash Signal and force a phone to restart.

Demo:
https://streamable.com/mxivw

References:
If you would like a premade file with which to test this check https://bomb.codes/

https://github.com/signalapp/Signal-iOS/blob/77711df27469970d938184c5f2cb9ca36aa6684b/SignalMessaging/ViewControllers/MediaMessageView.swift Line 256-313