[PR #2028] [CLOSED] Fix GXF VBI out-of-bounds panic in userdata.rs #2832

New Issue

claunia · 2026-01-29T17:24:07Z

claunia commented

2026-01-29 17:24:07 +00:00

📋 Pull Request Information

Original PR: https://github.com/CCExtractor/ccextractor/pull/2028
Author: @THE-Amrit-mahto-05
Created: 1/17/2026
Status: ❌ Closed

Base: master ← Head: fix/rust-gxf-vbi-oob

📝 Commits (1)

2c77126 Fix GXF VBI out-of-bounds panic in userdata.rs

📊 Changes

1 file changed (+1 additions, -0 deletions)

View changed files

📝 src/rust/src/es/userdata.rs (+1 -0)

📄 Description

In raising this pull request, I confirm the following (please check boxes):

I have read and understood the contributors guide.
I have checked that another pull request for this purpose does not exist.
I have considered, and confirmed that this submission will be valuable to others.
I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
I give this submission freely, and claim no ownership to its content.
I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

I have never used CCExtractor.
I have used CCExtractor just a couple of times.
I absolutely love CCExtractor, but have not contributed previously.
I am an active contributor to CCExtractor.

Desciption

critical out-of-bounds panic when processing malformed GXF VBI data.

Previously, the code attempted to slice exactly 720 bytes from the stream, even if fewer bytes were available:

let vbi_data = &ustream.data[ustream.pos..ustream.pos + 720];

This caused the program to panic if the GXF packet was truncated, corrupted, or attacker-crafted. The check for udatalen < 720 only logged a message but did not prevent execution.

Fix

Return early (Ok(1)) when insufficient data (<720 bytes) is detected.
This prevents out-of-bounds panics and allows the decoder to continue processing subsequent packets.
Existing functionality for valid packets is unchanged.

We could consider returning a specific error variant instead of Ok(1) to indicate that the packet is malformed. This would allow higher level code to handle malformed packets explicitly (e.g., loging, skipping, or applying custom processing). The current approach is safe and ensures decoder stability.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/CCExtractor/ccextractor/pull/2028 **Author:** [@THE-Amrit-mahto-05](https://github.com/THE-Amrit-mahto-05) **Created:** 1/17/2026 **Status:** ❌ Closed **Base:** `master` ← **Head:** `fix/rust-gxf-vbi-oob` --- ### 📝 Commits (1) - [`2c77126`](https://github.com/CCExtractor/ccextractor/commit/2c7712604eebf768666c3cda30ff89980cb2690a) Fix GXF VBI out-of-bounds panic in userdata.rs ### 📊 Changes **1 file changed** (+1 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `src/rust/src/es/userdata.rs` (+1 -0) </details> ### 📄 Description  **In raising this pull request, I confirm the following (please check boxes):** - [x] I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md). - [x] I have checked that another pull request for this purpose does not exist. - [x] I have considered, and confirmed that this submission will be valuable to others. - [x] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [x] I give this submission freely, and claim no ownership to its content. - [x] **I have mentioned this change in the [changelog](https://github.com/CCExtractor/ccextractor/blob/master/docs/CHANGES.TXT).** **My familiarity with the project is as follows (check one):** - [ ] I have never used CCExtractor. - [ ] I have used CCExtractor just a couple of times. - [ ] I absolutely love CCExtractor, but have not contributed previously. - [x] I am an active contributor to CCExtractor. --- ### Desciption critical out-of-bounds panic when processing malformed GXF VBI data. Previously, the code attempted to slice exactly 720 bytes from the stream, even if fewer bytes were available: ```rust let vbi_data = &ustream.data[ustream.pos..ustream.pos + 720]; ``` This caused the program to panic if the GXF packet was truncated, corrupted, or attacker-crafted. The check for udatalen < 720 only logged a message but did not prevent execution. ### Fix - Return early (Ok(1)) when insufficient data (<720 bytes) is detected. - This prevents out-of-bounds panics and allows the decoder to continue processing subsequent packets. - Existing functionality for valid packets is unchanged. We could consider returning a specific error variant instead of Ok(1) to indicate that the packet is malformed. This would allow higher level code to handle malformed packets explicitly (e.g., loging, skipping, or applying custom processing). The current approach is safe and ensures decoder stability. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

claunia added the pull-request label 2026-01-29 17:24:07 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#2832