Samsung Xclipse GPU Driver Android 16 File Reference Count Underflow

Samsung sgpu: File-level Reference Count Underflow via Gang Submit Logic Inversion in `amdgpu_job_free_cb`
https://project-zero.issues.chromium.org/issues/532525847

## Issue description
Samsung introduced a custom locking mechanism (`sgpu_swap_lock`) to protect the swapping process during command submission via the `AMDGPU_CS` ioctl. When command submission begins, the kernel explicitly increments the `struct file` reference count (`f_count++`). The matching `sgpu_swap_unlock` function drops this reference.

The matching `sgpu_swap_unlock` is executed asynchronously inside `amdgpu_job_free_cb` when the GPU jobs complete. However, there is a severe logic inversion when dealing with "Gang Submits" (command submissions targeting multiple GPU engines simultaneously).

In `amdgpu_job.c` at line `447` (within `amdgpu_job_free_cb`), the developer added the following logic:

```c
/* Call sgpu_swap_unlock() only for standalone jobs or gang submit leaders
* and skip the gang submit members. For standalone jobs job->gang_submit
* is NULL, for gang jobs amdgpu_job_set_gang_leader() sets it to leader's
* job->base.s_fence->scheduled. */
if (job->gang_submit != &job->base.s_fence->scheduled)
sgpu_swap_unlock(container_of(job->vm, struct amdgpu_fpriv, vm));
```

Despite the comment explicitly stating that member jobs should be skipped, the `!=` condition accomplishes the exact opposite.
- For the **Leader** job, the condition evaluates to `false`, and it *skips* the unlock.
- For the **Member** jobs, the condition evaluates to `true`, and they ALL call the unlock.

If an attacker submits a single Gang Submit targeting 3 GPU engines, the `AMDGPU_CS` ioctl grabs the lock once (`f_count++`). When the jobs finish, Member 1 unlocks (`f_count--`) and Member 2 unlocks (`f_count--`). This silently drops the VFS reference count below its expected value. An attacker can repeatedly submit this payload until the reference count hits 0, causing the VFS layer to free the `struct file` while the attacker's file descriptor remains open and usable in their FD table.

## Fixing it
The conditional check in `amdgpu_job_free_cb` (and any identical checks, such as the one on line `539`) must be updated to match the intended logic described in the comment.

A standalone job has `job->gang_submit == NULL`, and a leader has `job->gang_submit == &job->base.s_fence->scheduled`. Therefore, the unlock should only occur if the job is standalone OR the leader:

```c
if (job->gang_submit == NULL || job->gang_submit == &job->base.s_fence->scheduled)
sgpu_swap_unlock(container_of(job->vm, struct amdgpu_fpriv, vm));
```

## Affected versions
This vulnerability affects devices running the Samsung Xclipse GPU driver (`sgpu`), specifically observed and verified on the Samsung Galaxy A57 `SM-A576B` .

- Device Model: Samsung Galaxy A57 (a57xnaxx / a57x)
- Build Version: Android 16 (BP2A.250605.031.A3)
- Firmware: A576BXXS3AZF4
- Kernel Release: user/release-keys

## Impact
This bug provides a highly reliable, file-level Use-After-Free.

Because the underlying `struct file` is freed while the attacker still holds a valid file descriptor to it, the attacker can cause slab memory corruption. As demonstrated in the reproducer, by triggering a gang submit on the file descriptor to maliciously drop the reference count to 0, any subsequent legitimate kernel calls that attempt to increment the file's reference count (such as `dup2` which invokes `get_file()`) will trigger the kernel's explicit Use-After-Free protection mechanisms, raising the warning: `struct file::f_count incremented from zero; use-after-free condition present!`.

An attacker can spray the SLUB cache to hijack the struct file entirely, leading to Local Privilege Escalation from an unprivileged app context.

## Credit
Please credit "Dominique Bongard working with Google Project Zero".

## Disclosure deadline
This bug is subject to a 90-day disclosure deadline. If a fix for this