GHSA-XG88-J2C7-G852
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-28 09:31In the Linux kernel, the following vulnerability has been resolved:
greybus: raw: fix use-after-free if write is called after disconnect
If a user writes to the chardev after disconnect has been called, the kernel panics with the following trace (with CONFIG_INIT_ON_FREE_DEFAULT_ON=y):
BUG: kernel NULL pointer dereference, address: 0000000000000218
...
Call Trace:
<TASK>
gb_operation_create_common+0x61/0x180
gb_operation_create_flags+0x28/0xa0
gb_operation_sync_timeout+0x6f/0x100
raw_write+0x7b/0xc7 [gb_raw]
vfs_write+0xcf/0x420
? task_mm_cid_work+0x136/0x220
ksys_write+0x63/0xe0
do_syscall_64+0xa4/0x290
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Disconnect calls gb_connection_destroy, which ends up freeing the connection object. When gb_operation_sync is called in the write file operations, its gets a freed connection as parameter and the kernel panics.
The gb_connection_destroy cannot be moved out of the disconnect function, as the Greybus subsystem expect all connections belonging to a bundle to be destroyed when disconnect returns.
To prevent this bug, use a rw lock to synchronize access between write and disconnect. This guarantees that the write function doesn't try to use a disconnected connection.
{
"affected": [],
"aliases": [
"CVE-2026-53024"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:13Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngreybus: raw: fix use-after-free if write is called after disconnect\n\nIf a user writes to the chardev after disconnect has been called, the\nkernel panics with the following trace (with\nCONFIG_INIT_ON_FREE_DEFAULT_ON=y):\n\n BUG: kernel NULL pointer dereference, address: 0000000000000218\n ...\n Call Trace:\n \u003cTASK\u003e\n gb_operation_create_common+0x61/0x180\n gb_operation_create_flags+0x28/0xa0\n gb_operation_sync_timeout+0x6f/0x100\n raw_write+0x7b/0xc7 [gb_raw]\n vfs_write+0xcf/0x420\n ? task_mm_cid_work+0x136/0x220\n ksys_write+0x63/0xe0\n do_syscall_64+0xa4/0x290\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nDisconnect calls gb_connection_destroy, which ends up freeing the\nconnection object. When gb_operation_sync is called in the write file\noperations, its gets a freed connection as parameter and the kernel\npanics.\n\nThe gb_connection_destroy cannot be moved out of the disconnect\nfunction, as the Greybus subsystem expect all connections belonging to a\nbundle to be destroyed when disconnect returns.\n\nTo prevent this bug, use a rw lock to synchronize access between write\nand disconnect. This guarantees that the write function doesn\u0027t try\nto use a disconnected connection.",
"id": "GHSA-xg88-j2c7-g852",
"modified": "2026-06-28T09:31:39Z",
"published": "2026-06-24T18:32:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53024"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48d6c32bc049abd114e8f0836c0e7d7cbfba7827"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/84265cbd96b97058ef67e3f8be3933667a000835"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.