There is a memory corruption issue when processing a malformed RTP video stream in FaceTime that leads to a kernel panic due to a corrupted heap cookie or data abort. This bug can be reached if a user accepts a call from a malicious caller. This issue only affects FaceTime on iOS, it does not crash on a Mac.

There are several calls to memcpy that can overflow the destination buffer in webrtc::UlpfecReceiverImpl::AddReceivedRedPacket. The method takes a parameter incoming_rtp_packet, which is an RTP packet with a mac length that is defined by the transport (2048 bytes for DTLS in Chrome). This packet is then copied to the received_packet in several locations in the method, depending on packet properties, using the lenth of the incoming_rtp_packet as the copy length. The received_packet is a ForwardErrorCorrection::ReceivedPacket, which has a max size of 1500. Therefore, the memcpy calls in this method can overflow this buffer.

When a WebAssembly binary is parsed in ModuleParser::parse, it is expected to contain certain sections in a certain order, but can also contain custom sections that can appear anywhere in the binary. The ordering check validateOrder() does not adequately check that sections are in the correct order when a binary contains custom sections.

There is a directory traversal issue in the Telegram client for Android. The method saveFile in MediaController.java saves a file to external memory based on an optional name that is not filtered. The name is provided by the remote peer when sending a document or music file.

There is a directory traversal issue in attachment downloads in Outlook for Android. There is no path sanitization on the attachment filename in the app. If the email account is a Hotmail account, this will be sanitized by the server, but for other accounts it will not be. This allows a file to be written anywhere on the filesystem that the Outlook app can access when an attached image is viewed in the Outlook app.

There is a directory traversal issue in attachment downloads in Gmail. For non-gmail accounts, there is no path sanitization on the attachment filename in the email, so when attachments are downloaded, a file with any name and any contents can be written to anywhere on the filesystem that the Gmail app can access.