[PR #2027] [CLOSED] Fix unsafe temporary Vec pointer usage in userdata.rs

## 📋 Pull Request Information **Original PR:** https://github.com/CCExtractor/ccextractor/pull/2027 **Author:** [@THE-Amrit-mahto-05](https://github.com/THE-Amrit-mahto-05) **Created:** 1/17/2026 **Status:** ❌ Closed **Base:** `master` ← **Head:** `fix/rust-ffi-uaf-userdata` --- ### 📝 Commits (1) - [`7863ba0`](https://github.com/CCExtractor/ccextractor/commit/7863ba05a1ba8f01b8f07ab31bb513f16521c03f) Fix Rust FFI use-after-free in userdata.rs ### 📊 Changes **1 file changed** (+5 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `src/rust/src/es/userdata.rs` (+5 -3) </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. --- ### Description While working on the Rust FFI code in userdata.rs, I noticed that a few calls were passing pointers created from temporary Vecs (to_vec().as_mut_ptr()) directly into C functions. This is unsafe because the temporary Vec is dropped immediately after the statement, which can leave the C side with a dangling pointer and result in undefined behavior. ### Fix - Keep copied Vecs alive for the duration of the corresponding FFI calls where needed - Reuse existing slice pointers when the C code immediately copies the data This change does not alter behavior and is limited to fixing lifetime safety at the FFI boundary. ### Proposed Changes - Store the Vec in a variable so it remains alive until after the dump() call completes - Since `cc_data` is already a slice returned from `read_bytes()`, use its pointer directly. The C function `store_hdcc()` copies the data using `memcpy()` (see `sequencing.c:70`), so the pointer only needs to be valid during the call - Store the Vec in a variable so it remains alive until after the decode_vbi() call completes --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

claunia commented

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

Owner

📋 Pull Request Information

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

Base: master ← Head: fix/rust-ffi-uaf-userdata

📝 Commits (1)

7863ba0 Fix Rust FFI use-after-free in userdata.rs

📊 Changes

1 file changed (+5 additions, -3 deletions)

View changed files

📝 src/rust/src/es/userdata.rs (+5 -3)

📄 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.

Description

While working on the Rust FFI code in userdata.rs, I noticed that a few calls were passing pointers created from temporary Vecs (to_vec().as_mut_ptr()) directly into C functions.

This is unsafe because the temporary Vec is dropped immediately after the statement, which can leave the C side with a dangling pointer and result in undefined behavior.

Fix

Keep copied Vecs alive for the duration of the corresponding FFI calls where needed
Reuse existing slice pointers when the C code immediately copies the data

This change does not alter behavior and is limited to fixing lifetime safety at the FFI boundary.

Proposed Changes

Store the Vec in a variable so it remains alive until after the dump() call completes
Since cc_data is already a slice returned from read_bytes(), use its pointer directly.
The C function store_hdcc() copies the data using memcpy() (see sequencing.c:70), so the pointer only needs to be valid during the call
Store the Vec in a variable so it remains alive until after the decode_vbi() call completes

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

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

claunia closed this issue

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

[PR #2027] [CLOSED] Fix unsafe temporary Vec pointer usage in userdata.rs #2834